On Sun, Apr 26, 2020 at 1:36 PM David Faure <fa...@kde.org> wrote: > > During the review of https://phabricator.kde.org/D29170 the following > question surfaced again: should it be possible for a desktop file to refer to > an executable that is in the "current directory", for some definition of that > term. At least, outside of $PATH. > > In my opinion, in a GUI program started graphically, the notion of "current > dir" (QDir::currentPath()) has no meaning. The user can't see it and can't > change it. When starting the program from the command line it does serve a > purpose for command line arguments, but IMHO not after that (e.g. if you > navigate to another dir in dolphin, QDir::currentPath() still points to the > directory you started dolphin from). > > There is however another "current directory" that might make more sense when > starting a desktop file: the directory of the desktop file itself. > > There are actual use cases for that, see this very old request on the XDG > mailing-list: > https://lists.freedesktop.org/archives/xdg/2011-April/011883.html > > AFAICS this discussion has 3 possible outcomes: > > * We do not support starting executables that are not in $PATH, end of story. > That was actually what I had in mind when writing the code initially, any use > of API that also looked in the current directory (like QFileInfo::exists) was > accidental. Unless I'm mistaken, this is how it's been until now. It's also > what the XDG spec [1] says. > > * We support launching executables relative to the desktop file, > transparently. In the same directory, put a copy of dolphin called dolphin2, > and a copy of org.kde.dolphin.desktop modified to say Exec=dolphin2, and > clicking on the desktop file starts dolphin2. That's what my current revision > of D29170 does. > I'm wondering if this is the right thing to do though. > After all, on the command line "foo" doesn't start a local executable called > foo, only ./foo does that. Except for people who add "." to $PATH, but that's > generally not recommended (security, accidental use of wrong binary). > > * We could also adopt the above proposal from the xdg list, which is that > Exec=foo only looks in $PATH, while Exec=./foo only looks in the directory of > the desktop file. > > (I'm purposefully excluding the 4th option, resolving relative to > QDir::currentPath() which as explained at the top, would be nonsense IMHO) > > Thoughts?
One thing to note, which is probably easy to support: at the moment in kwin we're relying on certain apps to be defined in absolute paths for some security measures. Just supporting $PATH makes most sense to me, there's increasingly other ways to distribute software that abstract XDG out (e.g. snap, appimage and flatpak). Weird custom uses should become increasingly more rare over time. Aleix
