Hi, it seems digiKam cannot run complete "Exec" keyword line from Linux Desktop Entry [1] file anymore. [1] https://specifications.freedesktop.org/desktop-entry-spec/desktop-entry-spec-latest.html In particular, the example line could be: Exec=/usr/bin/xterm -hold -e /usr/local/bin/myscript.sh %f What digikam actually runs seems to be: /usr/bin/xterm %f This bug does not appear when the Exec is run from a file manager (Caja in MATE desktop), only from within digiKam. Reproducible: Always Steps to Reproduce: 1. Create a simple Desktop file in $HOME/.local/share/applications: [Desktop Entry] Exec=/usr/bin/xterm -hold -e /usr/local/bin/myscript.sh %f MimeType=image/jpeg;image/x-canon-cr2;image/x-canon-crw;image/x-panasonic-raw;image/x-panasonic-raw2;image/x-olympus-raw ;image/x-olympus-orf Name=Do Something Type=Application Terminal=No NoDisplay=Yes Icon=camera-photo-symbolic 2. Create the script in /usr/local/bin/myscript.sh and make it executable #!/bin/bash echo $@ exit 3. Run digiKam, right-click on a JPEG file and choose Open with... / Do Something Actual Results: 4. Nothing happens in GUI. 5. On CLI digiKam spits a message: xterm: No absolute path found for shell: /path/to/your/albums/somephoto.jpg Which means that xterm expects a path, not a file. This is the std error when no options (-parameters) are given to xterm command. Expected Results: 6. To test that otherwise things work, run from CLI the contents of the Exec line (with some path/to/image.jpg) or from your file manager (via right-click Open with...). A new window with xterm opens and shows the full path to the image name. It used to work in the past... (Probably still with the old version of digiKam 4.x.x.)
open with is delegate to KDE API... Gilles Caulier
Git commit d63328539b0b949031b42eb3046d54ff80bc26c9 by Maik Qualmann. Committed on 11/07/2016 at 20:30. Pushed by mqualmann into branch 'master'. fix string parsing from KService.exec() entry FIXED-IN: 5.1.0 M +41 -6 utilities/imageeditor/core/fileoperation.cpp M +2 -1 utilities/imageeditor/core/fileoperation.h http://commits.kde.org/digikam/d63328539b0b949031b42eb3046d54ff80bc26c9
This patch looks awful to me ;) (it duplicates what KRun does much better, it breaks on files with a double-quote in the name, and for non-local files, it breaks on any other special command from the desktop entry spec like %d since it will keep it instead of providing its value, etc.) Why not just use KRun::runService() or (since KF 5.24) KRun::runApplication() ? For the other overload (without a kservice), there's KRun::run().
Because KRun do not work on Windows. We need a multiplatform solution Because we want to reduce KDE dependencies to provide a pure Qt5 application Because we want to reduce the puzlle provided by KDE dependencies. Gilles Caulier
The (admitted quite new) KRun::runApplication does exactly what you want : it computes the process arguments and then passes them to QProcess. No runtime dependency on anything else. It should work just fine on Windows. I'm surprised that running desktop files with %f/%u/etc. in them is a required feature on Windows though ?
Git commit fc79b21fd529314eda2bc62328cddec380ae9196 by Maik Qualmann. Committed on 14/07/2016 at 19:17. Pushed by mqualmann into branch 'master'. optimization FileOperation::runFiles() M +36 -36 utilities/imageeditor/core/fileoperation.cpp http://commits.kde.org/digikam/fc79b21fd529314eda2bc62328cddec380ae9196
You could at least use KIO::DesktopExecParser which does the parsing and escaping correctly (unlike this QRegExp, when given a complex sh Exec line), and fully supports the desktop entry spec (you added %d, but not %k...). KIO::DesktopExecParser parser(service, QList <QUrl>() << QUrl::fromLocalFile(dest)); process.setArguments(parser.resultingArguments());