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, [email protected], http://www.davidfaure.fr Working on KDE, in particular KDE Frameworks 5 _______________________________________________ xdg mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/xdg
