Relative paths in .desktop files

[David Faure]

On Friday 25 May 2012 06:45:58 Michael Thayer wrote:
> On 05/20/2012 10:27 PM, Michael Thayer wrote:
> > On 05/19/2012 01:20 PM, David Faure wrote:
> >> On Friday 24 June 2011 13:21:50 Michael Thayer wrote:
> >>> On Thu, 2011-06-23 at 12:47 +0200, David Faure wrote:
> >>>> On Thursday 23 June 2011, Michael Thayer wrote:
> >>>>> does [
> >>>>> http://lists.freedesktop.org/archives/xdg/2011-April/011882.html
> >>>>> ] look good to you?
> >>>> 
> >>>> It says that "./" is relative to the location of the .desktop file.
> >>>> I can
> >>>> see the idea behind it, but then what happens when Path is set?
> >>>> 
> >>>> From an implementation point of view it's easier to chdir(Path) and
> >>>> then
> >>>> execute ./foo, but I can see how from a user point of view the idea is
> >>>> maybe more to say "resolve to a full path from the directory containing
> >>>> the .desktop file, then chdir(Path), then run the executable with a
> >>>> full
> >>>> path"?
> >>>> 
> >>>> I'm talking about a case like /home/dfaure/foo.desktop saying:
> >>>> Exec=./foo
> >>>> Path=/tmp
> >>>> 
> >>>> Should this do (cd /tmp ; ./foo) or (cd /tmp ; /home/dfaure/foo) ?
> >>>> 
> >>>> I'm guessing the latter is more useful, but maybe less expected.
> >>>> 
> >>>> (More useful because the first one can be done with Exec=/tmp/foo,
> >>>> since
> >>>> in
> >>>> that case we know about /tmp as an absolute path anyway).
> >>> 
> >>> I agree with what you said about the second variant being more useful.
> >>> In fact it seems more intuitive to me to specify all paths as absolute
> >>> (that is Exec too) if you really know that you are wanting to
> >>> run /tmp/foo.
> >> 
> >> Agreed.
> >> 
> >> Did anything come out of this? Should the suggested patch for the spec be
> >> amended to clarify the issue above?
> >> 
> >> Any objections from main implementors to supporting "./" in Exec and Icon
> >> fields?
> > 
> > I had actually given up on this as no one with commit rights seemed to
> > be inclined to make the change, and at least Marty Jack and PCMan didn't
> > seem very keen on it. I would certainly still be interested in seeing it
> > though.
> 
> Actually I can quickly summarise the objections (and my answers):
> * Marty thought that this overlapped with the Autostart spec; I would
> say that they are orthogonal, as this describes an application and
> Autostart says what is to be started.
> * Marty thought that this didn't help existing users of .desktop files;
> I agree, though I would point out that Nautilus (didn't check other file
> managers) can use .desktop files in random locations, but requires that
> they refer to an application with absolute paths.  I think that in that
> particular case this would improve usability.
> * Marty objected that this didn't support multi-architecture.  I agree,
> but would say that that is a separate issue which can be addressed
> separately if needed (an expander in a relative path?), and can be
> hacked now easily using scripts.
> * PCMan thought that AppFolders would solve the problem better.  Again,
> I agree, but there is no freedesktop AppFolder specification that I am
> aware of.  In fact a relative .desktop file in a directory containing an
> application seems to me like a good way of implementing them!
> * PCMan suggested embedding icons into scripts.  Unfortunately I don't
> think that there is a universally accepted way of doing this, and
> requiring a (complex) installation procedure for it to work rather
> defeats the purpose.
> 
> Is there anything else I can do or address to make this move?

Ryan, this is the thread I told you about, about
Exec=./binary
Icon=./icon.png

i.e. "./" meaning relative path.

Any objections about this getting into the desktop entry standard?

-- 
David Faure, faure at kde.org, http://www.davidfaure.fr
Working on KDE, in particular KDE Frameworks 5