On 06/23/2011 06:47 AM, David Faure wrote: > On Thursday 23 June 2011, Michael Thayer wrote: >> On Thu, 2011-06-23 at 11:58 +0200, David Faure wrote: >>> On Monday 18 April 2011, Vincent Untz wrote: >>>> FWIW, I'd consider ./ to be relative to the path defined in the Path >>>> key (which could be ./ to tell that it's the base directory of the >>>> .desktop file). >>> >>> From a KDE point of view: I support these additions to the desktop entry >>> spec and I volunteer to implement them in KDE. >>> >>> (In fact I just implemented support for Exec=./foo here, but that's >>> useless by itself if it requires on a Path that has to be absolute, so >>> the next step is to implement Path=. if we all agree on that syntax). >> >> Great. Would you like me to post an updated patch against the spec, as >> in e.g. >> [ http://lists.freedesktop.org/archives/xdg/2011-April/011887.html ], or > > Ah I seem to have missed some emails in this thread, thanks for the pointers. > > I am definitely NOT in favour of Type=ApplicationRelative, this would require > many more adaptations to the code in many places, and it moves a rather > special case to a very proeminent place -- should we have > Type=ApplicationWithPath when Path is set, and Type=ApplicationWithTerminal > when a terminal should show up? Sorry for the reasoning by the absurd or > whatever that's called -- my point is that there's a combinatorial issue in > putting too much information into Type. This discussion is about a small > change in the file describing an application, let's keep Type=Application. > >> 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 continue to oppose this. As I understand it, the intended use is for installation kits similar to how Autorun works on Windows. I would also refer everyone to the Autostart spec http://standards.freedesktop.org/autostart-spec/autostart-spec-latest.html which, in section Autostart of Applications After Mount, already deals with this after a fashion. I am not convinced that definition does not suffer from the same problems I point out here. The current way this proposal is defined is of no use for the existing applications of Desktop Entry, to wit the application menu (/usr/share/applications) and the X sessions menu (/usr/share/xsessions). The current proposal breaks the separation between architecture independent items like the icon and architecture dependent items like the executable. I would like someone to take me through how the multi-architecture scenario would work. If Exec points to a relative path, how do we have an install kit that has a binary for x86, a binary for s390, and a binary for arm, all of which are currently important Linux architectures. _______________________________________________ xdg mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/xdg
