pkill9 wrote 6 years ago
(name . bug-guix)(address . bug-guix@gnu.org)
E1gjpV4-0007V1-RA@rmmprod07.runbox
There are a few issues with Kdenlive I've found, mostly relating to finding paths for things:
It doesn't know where to look for mlt profiles by default, so it asks the user in a popup where to look for them - the default suggestion in the popup is incorrect (constructed like '<guix-profile>/bin/share/mlt/profiles). The correct path is found with `$(guix build mlt)/share/mlt/profiles`.
It stores this path in the '[env]' section of ~/.config/kdenliverc, which it autogenerates. If it doesn't find the mlt profiles in this stored path when run, it asks the user to specify the path in the popup again.
It also stores other paths it needs that it finds, like the path to ffmpeg (to the relative guix profiles they're in, e.g. /run/current-system/profile and ~/.guix-profile. I don't know if this is an issue, I think it will just try to find these other paths again if they're invalid when starting kdenlive.
One way to fix the mlt path not being found is by wrapping the kdenlive executable with an additional CLI flag `--mlt-path <path-to-mlt>/share/mlt/profiles`. It would maybe better to use an environment variable (which could either be wrapped, or if propagated could allow additional mlt profiles to be added to the guix profile) but I couldn't find one for specifying the path to the mlt profiles.
-----
Another issue is that it heavily uses the icons from the breeze-icons package (which it gives a warning if not found), and these need to be installed to the user's profile (not tested with system profile) as kdenlive doesn't find them when running `guix environment --ad-hoc kdenlive breeze-icons -- kdenlive`
It also gives the warning
```
No LADSPA plugins were found!
Check your LADSPA_PATH environment variable.
```
which is gotten rid of by running kdenlive with `LADSPA_PATH=$(guix build ladspa)/lib/ladspa kdenlive`. This environment variable could also be added to the kdenlive wrapper, and/or added as a search path.