Bug 374015

Summary: Make multiple executables accessible in kdenlive AppImage
Product: [Applications] kdenlive Reporter: Lutz Vieweg <kde3>
Component: Setup & InstallationAssignee: Jean-Baptiste Mardelle <jb>
Status: REPORTED ---    
Severity: wishlist CC: fritzibaby
Priority: NOR    
Version First Reported In: Appimage - Refactoring   
Target Milestone: ---   
Platform: Other   
OS: Linux   
Latest Commit: Version Fixed/Implemented In:
Sentry Crash Report:

Description Lutz Vieweg 2016-12-21 23:17:44 UTC 
The kdenlive AppImage contains multiple executables (besides the main kdenlive executable) that would be useful to be accessible to run on their own - most prominently "melt", but probably also "ffmpeg".

According to the AppImage documentation, this should be trivially possible by including more "*.desktop"-files than just the "kdenlive.desktop" file, so e.g. one additional for "melt" and one for "ffmpeg".

Rationale: kdenlive has always had the ability to create scripts for rendering videos independently of a running kdenlive instance/GUI. I for one need to use such scripts because the videos I render are long and complex enough to require ~10 GB RAM and many hours of rendering, and it's very inconvenient to keep the kdenlive GUI open at the same time. However, running "melt" on its own is currently not possible with the AppImage.
Comment 1 Julius Künzel 2024-08-08 07:28:47 UTC 
Thanks for your report!

To my knowledge AppImage is not designed for such a use case. However since you mentioned documentation about that, could you provide a link?

Note that recently the Kdenlive executable itself gained support for headless rendering.
Comment 2 Lutz Vieweg 2024-08-08 20:30:49 UTC 
The executables are already in the AppImage, all it takes is a small script used to branch off into them at start. Like a bash script as the entry point for the AppImage that looks at the executable name in $0 to decide what to run. By soft-linking the AppImage under different names, one could reach those executables, while unknown names could continue to just cause the main kdenlive executable to be started.