Re: Relative paths in .desktop files
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, fa...@kde.org, http://www.davidfaure.fr Working on KDE, in particular KDE Frameworks 5 ___ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg
Re: Relative paths in .desktop files
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? Regards, Michael -- ORACLE Deutschland B.V. & Co. KG Michael Thayer Werkstrasse 24 VirtualBox engineering 71384 Weinstadt, Germany mailto:michael.tha...@oracle.com Hauptverwaltung: Riesstr. 25, D-80992 München Registergericht: Amtsgericht München, HRA 95603 Geschäftsführer: Jürgen Kunz Komplementärin: ORACLE Deutschland Verwaltung B.V. Hertogswetering 163/167, 3543 AS Utrecht, Niederlande Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697 Geschäftsführer: Alexander van der Ven, Astrid Kepper, Val Maher ___ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg
Re: Relative paths in .desktop files
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. Regards, Michael -- ORACLE Deutschland B.V. & Co. KG Michael Thayer Werkstrasse 24 VirtualBox engineering 71384 Weinstadt, Germany mailto:michael.tha...@oracle.com Hauptverwaltung: Riesstr. 25, D-80992 München Registergericht: Amtsgericht München, HRA 95603 Komplementärin: ORACLE Deutschland Verwaltung B.V. Hertogswetering 163/167, 3543 AS Utrecht, Niederlande Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697 Geschäftsführer: Jürgen Kunz, Marcel van de Molen, Alexander van der Ven ___ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg
Re: Relative paths in .desktop files
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? -- David Faure, fa...@kde.org, http://www.davidfaure.fr Sponsored by Nokia to work on KDE, incl. KDE Frameworks 5 ___ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg
Re: Relative paths in .desktop files
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. Regards, Michael -- ORACLE Deutschland B.V. & Co. KG Michael Thayer Werkstrasse 24 VirtualBox engineering 71384 Weinstadt, Germany mailto:michael.tha...@oracle.com Hauptverwaltung: Riesstr. 25, D-80992 München Registergericht: Amtsgericht München, HRA 95603 Komplementärin: ORACLE Deutschland Verwaltung B.V. Hertogswetering 163/167, 3543 AS Utrecht, Niederlande Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697 Geschäftsführer: Jürgen Kunz, Marcel van de Molen, Alexander van der Ven ___ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg
Re: Relative paths in .desktop files
On Thu, 2011-06-23 at 15:30 +0200, David Faure wrote: > On Thursday 23 June 2011, you wrote: > > If you just want to give the script an icon, you can embed > > the icon in the script, and write a thumbnailer for it. > > IMHO, having "run_me.sh" in the folder is enough. > > Having "run_me.sh", "run_me.desktop", and "run_me.png" in the folder > > won't increase usability. > > > > There are several ways to embed an icon in a script file. Just apend > > it to the end of file, or encode it with base64 or some others. Then > > having a thumbnailer decode such thing won't be too difficult. By > > adding a comment line containing specific strings in the script, > > during mime-type sniffing, it's easy to recognize this kind of file > > with mime-type magic rules. > > You know, not everyone is a developer. I am, but most people just want the > *simplest* way to create an "icon" shortcut which launches something. > > Think of the usability for the creator of the shortcut too, not only the > usability for the end user (who just clicks on something anyway). > > Writing a thumbnailer, or encoding an icon with base64, is nowhere as simple > as writing out with a text editor (or a standard properties dialog) > Exec=./foo.sh > Icon=some-standard-icon > > KISS :-) > > If some desktops want to also offer something at a higher-level that's fine, > but > not everything should need a GUI, in the Unix world. There's a strong use > case > for being able to do things from a command-line, in text mode, as well. I'm fine with relative paths. As long as you can't reference files in parent directories, only ever children nodes, then it's fine by me. ___ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg
Re: Relative paths in .desktop files
On Thursday 23 June 2011, you wrote: > If you just want to give the script an icon, you can embed > the icon in the script, and write a thumbnailer for it. > IMHO, having "run_me.sh" in the folder is enough. > Having "run_me.sh", "run_me.desktop", and "run_me.png" in the folder > won't increase usability. > > There are several ways to embed an icon in a script file. Just apend > it to the end of file, or encode it with base64 or some others. Then > having a thumbnailer decode such thing won't be too difficult. By > adding a comment line containing specific strings in the script, > during mime-type sniffing, it's easy to recognize this kind of file > with mime-type magic rules. You know, not everyone is a developer. I am, but most people just want the *simplest* way to create an "icon" shortcut which launches something. Think of the usability for the creator of the shortcut too, not only the usability for the end user (who just clicks on something anyway). Writing a thumbnailer, or encoding an icon with base64, is nowhere as simple as writing out with a text editor (or a standard properties dialog) Exec=./foo.sh Icon=some-standard-icon KISS :-) If some desktops want to also offer something at a higher-level that's fine, but not everything should need a GUI, in the Unix world. There's a strong use case for being able to do things from a command-line, in text mode, as well. -- David Faure, fa...@kde.org, http://www.davidfaure.fr Sponsored by Nokia to work on KDE, incl. Konqueror (http://www.konqueror.org). ___ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg
Re: Relative paths in .desktop files
For example, maybe a script can have an embedded icon like this: #/bin/sh #xdg_icon=data:image/png;base64,iVBORw0KGgoNSUhEUgUA AAAFCAYAAACNbyblHElEQVQI12P4//8/w38GIAXDIBKE0DHxgljNBAAO 9TXL0Y4OHwBJRU5ErkJggg== This is the data url scheme used by browsers. Then a file manger can parse this, and show the file with the icon. If the file manager doesn't support this, but supports a thumbnailer, a thumbnailer can be easily created for it. On Thu, Jun 23, 2011 at 9:18 PM, PCMan wrote: > On Thu, Jun 23, 2011 at 9:06 PM, David Faure wrote: >> On Thursday 23 June 2011, Marty Jack wrote: >>> 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. >> >> Well, this is just one use case. >> >> What about the use case where I write a script and a .desktop file for my >> wife, >> which she can put in any directory she wants? >> With a relative path I can now do that, and she can move the .desktop file >> and >> the script together and it will continue to work. >> Without support for relative paths, this would break, just because the >> .desktop file requires an absolute path. > > For this purpose, mechanisms like application bundle used by Mac OS X > and ROX desktop have much better usability. All pieces of the whole > application are bundled in one application folder. Putting a script > along with a desktop file doesn't make things easier than just open > the script. If you just want to give the script an icon, you can embed > the icon in the script, and write a thumbnailer for it. > IMHO, having "run_me.sh" in the folder is enough. > Having "run_me.sh", "run_me.desktop", and "run_me.png" in the folder > won't increase usability. > > There are several ways to embed an icon in a script file. Just apend > it to the end of file, or encode it with base64 or some others. Then > having a thumbnailer decode such thing won't be too difficult. By > adding a comment line containing specific strings in the script, > during mime-type sniffing, it's easy to recognize this kind of file > with mime-type magic rules. > >> I believe this has more uses than installation kits / autorun. >> >> -- >> David Faure, fa...@kde.org, http://www.davidfaure.fr >> Sponsored by Nokia to work on KDE, incl. Konqueror >> (http://www.konqueror.org). >> ___ >> xdg mailing list >> xdg@lists.freedesktop.org >> http://lists.freedesktop.org/mailman/listinfo/xdg >> > ___ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg
Re: Relative paths in .desktop files
On Thu, Jun 23, 2011 at 9:06 PM, David Faure wrote: > On Thursday 23 June 2011, Marty Jack wrote: >> 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. > > Well, this is just one use case. > > What about the use case where I write a script and a .desktop file for my > wife, > which she can put in any directory she wants? > With a relative path I can now do that, and she can move the .desktop file and > the script together and it will continue to work. > Without support for relative paths, this would break, just because the > .desktop file requires an absolute path. For this purpose, mechanisms like application bundle used by Mac OS X and ROX desktop have much better usability. All pieces of the whole application are bundled in one application folder. Putting a script along with a desktop file doesn't make things easier than just open the script. If you just want to give the script an icon, you can embed the icon in the script, and write a thumbnailer for it. IMHO, having "run_me.sh" in the folder is enough. Having "run_me.sh", "run_me.desktop", and "run_me.png" in the folder won't increase usability. There are several ways to embed an icon in a script file. Just apend it to the end of file, or encode it with base64 or some others. Then having a thumbnailer decode such thing won't be too difficult. By adding a comment line containing specific strings in the script, during mime-type sniffing, it's easy to recognize this kind of file with mime-type magic rules. > I believe this has more uses than installation kits / autorun. > > -- > David Faure, fa...@kde.org, http://www.davidfaure.fr > Sponsored by Nokia to work on KDE, incl. Konqueror (http://www.konqueror.org). > ___ > xdg mailing list > xdg@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/xdg > ___ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg
Re: Relative paths in .desktop files
On Thursday 23 June 2011, Marty Jack wrote: > 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. Well, this is just one use case. What about the use case where I write a script and a .desktop file for my wife, which she can put in any directory she wants? With a relative path I can now do that, and she can move the .desktop file and the script together and it will continue to work. Without support for relative paths, this would break, just because the .desktop file requires an absolute path. I believe this has more uses than installation kits / autorun. -- David Faure, fa...@kde.org, http://www.davidfaure.fr Sponsored by Nokia to work on KDE, incl. Konqueror (http://www.konqueror.org). ___ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg
Re: Relative paths in .desktop files
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 xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg
Re: Relative paths in .desktop files
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). -- David Faure, fa...@kde.org, http://www.davidfaure.fr Sponsored by Nokia to work on KDE, incl. Konqueror (http://www.konqueror.org). ___ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg
Re: Relative paths in .desktop files
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 does [ http://lists.freedesktop.org/archives/xdg/2011-April/011882.html ] look good to you? Regards, Michael -- ORACLE Deutschland B.V. & Co. KG Michael Thayer Werkstrasse 24 VirtualBox engineering 71384 Weinstadt, Germany mailto:michael.tha...@oracle.com Hauptverwaltung: Riesstr. 25, D-80992 München Registergericht: Amtsgericht München, HRA 95603 Komplementärin: ORACLE Deutschland Verwaltung B.V. Hertogswetering 163/167, 3543 AS Utrecht, Niederlande Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697 Geschäftsführer: Jürgen Kunz, Marcel van de Molen, Alexander van der Ven ___ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg
Re: Relative paths in .desktop files
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). -- David Faure, fa...@kde.org, http://www.davidfaure.fr Sponsored by Nokia to work on KDE, incl. Konqueror (http://www.konqueror.org). ___ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg
Re: Relative paths in .desktop files
I don't seem to be getting very far here. Is the problem that no one wants to take a decision about changing the spec, or that everyone is too polite to say that they don't really want any changes, or that everyone is waiting for some one else to take a decision? Or just that no one really objects, but no one has the free time to shepherd a patch through either? Regards, Michael On Wed, 2011-04-20 at 23:15 +0200, Michael Thayer wrote: > Sorry to be annoying here, but who would actually be able take a > decision as to whether my patch (subject to additional iterations of > course) can go into the spec or not? Naively I would expect that to be > the people handling those bits in the main desktop environments (Vincent > in GNOME, Marty in LXDE?) > > Regards, > > Michael > > On Mon, 2011-04-18 at 11:29 +0200, Michael Thayer wrote: > > Hello Vincent, > > > > Thanks for your comments. > > > > On Mon, 2011-04-18 at 10:56 +0200, Vincent Untz wrote: > > > Le lundi 11 avril 2011, à 18:06 +0200, Michael Thayer a écrit : > > > > Thanks for the answer. Please find a patch against > > > > desktop-entry-spec-1.1.xml below. I hope that that, together with my > > > > initial posting, makes my intentions slightly clearer. As I said, I > > > > would also interested in other approaches to achieve the same thing. > > > > > > [...] > > > > > > > --- desktop-entry-spec-1.1.xml 2011-04-11 17:50:02.350865289 +0200 > > > > +++ desktop-entry-spec-1.1.xml.new 2011-04-11 17:57:39.126810018 > > > > +0200 > > > > @@ -429,7 +429,10 @@ > > > > > > > >Icon to display in file manager, menus, etc. If the > > > >name is an absolute path, the given file will be > > > > - used. If the name is not an absolute path, the algorithm > > > > described > > > > + used. If it starts with "./" it will be treated as a path > > > > + relative to the directory containing the desktop file and > > > > + the given file will be used. Otherwise, the algorithm > > > > + described > > > > in the > > > > > > > url="http://freedesktop.org/wiki/Standards/icon-theme-spec";>Icon > > > > Theme Specification will be used to locate the icon. > > > > > > I must admit I don't really see which use case we're trying to cover > > > here. Can you give a concrete example of where you'd have a bundled > > > application like this? > > As mentioned at the start of the thread, my immediate use case is for > > the installer for the VirtualBox Guest Additions, which are delivered as > > a virtual CD image which "appears" in a virtual machine when the user > > selects "Install Guest Additions", and which is normally auto-mounted by > > the guest at a mount point which can't be cleanly predicted. I would > > simply like it to look prettier on X11/fd.o-type systems - in the > > current iteration the user can click on the icon of a shell script to do > > the installation, but it would be nicer to have a more recognisable icon > > and the other things that a .desktop file describes very nicely. > > > > > 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). > > Tricky one. On the whole I would say that the initial working directory > > and the directory where the application files are located don't need to > > be related, but I can't immediately see how a relocatable application > > could usefully specify an initial working directory. > > > > My initial googling when I was looking for solutions to this suggested > > that other people might also have uses for it. I don't have any links > > handy just now, though I could look for some if you like. > > > > > I think we'd also want to explicitly mention that ../ is > > > not supported. > > Of course, that raises the question as to whether supporting ../ might > > be useful for someone. But it would seem reasonable not to support it > > until there is a concrete use case. > > > > By the way, I assume you saw > > http://lists.freedesktop.org/archives/xdg/2011-April/011885.html too. > > > > Please let me know if this answer clarified things for you a bit. > > > > Regards, > > > > Michael > > -- > ORACLE Deutschland B.V. & Co. KG Michael Thayer > Werkstrasse 24 VirtualBox engineering > 71384 Weinstadt, Germany mailto:michael.tha...@oracle.com > > Hauptverwaltung: Riesstr. 25, D-80992 München > Registergericht: Amtsgericht München, HRA 95603 > > Komplementärin: ORACLE Deutschland Verwaltung B.V. > Hertogswetering 163/167, 3543 AS Utrecht, Niederlande > Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697 > Geschäftsführer: Jürgen Kunz, Marcel van de Molen, Alexander van der Ven > > ___ > xdg mailing list > xdg@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/xdg -- ORACLE Deut
Re: Relative paths in .desktop files
Sorry to be annoying here, but who would actually be able take a decision as to whether my patch (subject to additional iterations of course) can go into the spec or not? Naively I would expect that to be the people handling those bits in the main desktop environments (Vincent in GNOME, Marty in LXDE?) Regards, Michael On Mon, 2011-04-18 at 11:29 +0200, Michael Thayer wrote: > Hello Vincent, > > Thanks for your comments. > > On Mon, 2011-04-18 at 10:56 +0200, Vincent Untz wrote: > > Le lundi 11 avril 2011, à 18:06 +0200, Michael Thayer a écrit : > > > Thanks for the answer. Please find a patch against > > > desktop-entry-spec-1.1.xml below. I hope that that, together with my > > > initial posting, makes my intentions slightly clearer. As I said, I > > > would also interested in other approaches to achieve the same thing. > > > > [...] > > > > > --- desktop-entry-spec-1.1.xml2011-04-11 17:50:02.350865289 +0200 > > > +++ desktop-entry-spec-1.1.xml.new2011-04-11 17:57:39.126810018 > > > +0200 > > > @@ -429,7 +429,10 @@ > > > > > >Icon to display in file manager, menus, etc. If the > > >name is an absolute path, the given file will be > > > - used. If the name is not an absolute path, the algorithm > > > described > > > + used. If it starts with "./" it will be treated as a path > > > + relative to the directory containing the desktop file and > > > + the given file will be used. Otherwise, the algorithm > > > + described > > > in the > > url="http://freedesktop.org/wiki/Standards/icon-theme-spec";>Icon > > > Theme Specification will be used to locate the icon. > > > > I must admit I don't really see which use case we're trying to cover > > here. Can you give a concrete example of where you'd have a bundled > > application like this? > As mentioned at the start of the thread, my immediate use case is for > the installer for the VirtualBox Guest Additions, which are delivered as > a virtual CD image which "appears" in a virtual machine when the user > selects "Install Guest Additions", and which is normally auto-mounted by > the guest at a mount point which can't be cleanly predicted. I would > simply like it to look prettier on X11/fd.o-type systems - in the > current iteration the user can click on the icon of a shell script to do > the installation, but it would be nicer to have a more recognisable icon > and the other things that a .desktop file describes very nicely. > > > 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). > Tricky one. On the whole I would say that the initial working directory > and the directory where the application files are located don't need to > be related, but I can't immediately see how a relocatable application > could usefully specify an initial working directory. > > My initial googling when I was looking for solutions to this suggested > that other people might also have uses for it. I don't have any links > handy just now, though I could look for some if you like. > > > I think we'd also want to explicitly mention that ../ is > > not supported. > Of course, that raises the question as to whether supporting ../ might > be useful for someone. But it would seem reasonable not to support it > until there is a concrete use case. > > By the way, I assume you saw > http://lists.freedesktop.org/archives/xdg/2011-April/011885.html too. > > Please let me know if this answer clarified things for you a bit. > > Regards, > > Michael -- ORACLE Deutschland B.V. & Co. KG Michael Thayer Werkstrasse 24 VirtualBox engineering 71384 Weinstadt, Germany mailto:michael.tha...@oracle.com Hauptverwaltung: Riesstr. 25, D-80992 München Registergericht: Amtsgericht München, HRA 95603 Komplementärin: ORACLE Deutschland Verwaltung B.V. Hertogswetering 163/167, 3543 AS Utrecht, Niederlande Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697 Geschäftsführer: Jürgen Kunz, Marcel van de Molen, Alexander van der Ven ___ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg
Re: Relative paths in .desktop files
Hello Vincent, Thanks for your comments. On Mon, 2011-04-18 at 10:56 +0200, Vincent Untz wrote: > Le lundi 11 avril 2011, à 18:06 +0200, Michael Thayer a écrit : > > Thanks for the answer. Please find a patch against > > desktop-entry-spec-1.1.xml below. I hope that that, together with my > > initial posting, makes my intentions slightly clearer. As I said, I > > would also interested in other approaches to achieve the same thing. > > [...] > > > --- desktop-entry-spec-1.1.xml 2011-04-11 17:50:02.350865289 +0200 > > +++ desktop-entry-spec-1.1.xml.new 2011-04-11 17:57:39.126810018 +0200 > > @@ -429,7 +429,10 @@ > > > >Icon to display in file manager, menus, etc. If the > >name is an absolute path, the given file will be > > - used. If the name is not an absolute path, the algorithm > > described > > + used. If it starts with "./" it will be treated as a path > > + relative to the directory containing the desktop file and > > + the given file will be used. Otherwise, the algorithm > > + described > > in the > url="http://freedesktop.org/wiki/Standards/icon-theme-spec";>Icon > > Theme Specification will be used to locate the icon. > > I must admit I don't really see which use case we're trying to cover > here. Can you give a concrete example of where you'd have a bundled > application like this? As mentioned at the start of the thread, my immediate use case is for the installer for the VirtualBox Guest Additions, which are delivered as a virtual CD image which "appears" in a virtual machine when the user selects "Install Guest Additions", and which is normally auto-mounted by the guest at a mount point which can't be cleanly predicted. I would simply like it to look prettier on X11/fd.o-type systems - in the current iteration the user can click on the icon of a shell script to do the installation, but it would be nicer to have a more recognisable icon and the other things that a .desktop file describes very nicely. > 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). Tricky one. On the whole I would say that the initial working directory and the directory where the application files are located don't need to be related, but I can't immediately see how a relocatable application could usefully specify an initial working directory. My initial googling when I was looking for solutions to this suggested that other people might also have uses for it. I don't have any links handy just now, though I could look for some if you like. > I think we'd also want to explicitly mention that ../ is > not supported. Of course, that raises the question as to whether supporting ../ might be useful for someone. But it would seem reasonable not to support it until there is a concrete use case. By the way, I assume you saw http://lists.freedesktop.org/archives/xdg/2011-April/011885.html too. Please let me know if this answer clarified things for you a bit. Regards, Michael -- ORACLE Deutschland B.V. & Co. KG Michael Thayer Werkstrasse 24 VirtualBox engineering 71384 Weinstadt, Germany mailto:michael.tha...@oracle.com Hauptverwaltung: Riesstr. 25, D-80992 München Registergericht: Amtsgericht München, HRA 95603 Komplementärin: ORACLE Deutschland Verwaltung B.V. Hertogswetering 163/167, 3543 AS Utrecht, Niederlande Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697 Geschäftsführer: Jürgen Kunz, Marcel van de Molen, Alexander van der Ven ___ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg
Re: Relative paths in .desktop files
Hi, Le lundi 11 avril 2011, à 18:06 +0200, Michael Thayer a écrit : > Thanks for the answer. Please find a patch against > desktop-entry-spec-1.1.xml below. I hope that that, together with my > initial posting, makes my intentions slightly clearer. As I said, I > would also interested in other approaches to achieve the same thing. [...] > --- desktop-entry-spec-1.1.xml2011-04-11 17:50:02.350865289 +0200 > +++ desktop-entry-spec-1.1.xml.new2011-04-11 17:57:39.126810018 +0200 > @@ -429,7 +429,10 @@ > >Icon to display in file manager, menus, etc. If the >name is an absolute path, the given file will be > - used. If the name is not an absolute path, the algorithm described > + used. If it starts with "./" it will be treated as a path > + relative to the directory containing the desktop file and > + the given file will be used. Otherwise, the algorithm > + described > in the url="http://freedesktop.org/wiki/Standards/icon-theme-spec";>Icon > Theme Specification will be used to locate the icon. I must admit I don't really see which use case we're trying to cover here. Can you give a concrete example of where you'd have a bundled application like this? 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). I think we'd also want to explicitly mention that ../ is not supported. Cheers, Vincent -- Les gens heureux ne sont pas pressés. ___ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg
Re: Relative paths in .desktop files
On Mon, 2011-04-11 at 17:48 -0400, Marty Jack wrote: > On 04/11/2011 05:35 PM, Michael Thayer wrote: > > On Mon, 2011-04-11 at 22:42 +0200, Michael Thayer wrote: > >> Using a new Type as you suggested [...] > > Should I send a new patch on that basis? [...] > Personally, I would wait to see if there is more feedback from others > before changing anything. Doesn't seem to be a lot of feedback forthcoming - either no one is interested or everyone is happy. How can I move on from here? Is there some normal procedure for having a spec change applied? Who can approve or disapprove it? Regards, Michael -- ORACLE Deutschland B.V. & Co. KG Michael Thayer Werkstrasse 24 VirtualBox engineering 71384 Weinstadt, Germany mailto:michael.tha...@oracle.com Hauptverwaltung: Riesstr. 25, D-80992 München Registergericht: Amtsgericht München, HRA 95603 Komplementärin: ORACLE Deutschland Verwaltung B.V. Rijnzathe 6, 3454PV De Meern, Niederlande Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697 Geschäftsführer: Jürgen Kunz, Marcel van de Molen, Alexander van der Ven ___ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg
Re: Relative paths in .desktop files
On 04/11/2011 05:35 PM, Michael Thayer wrote: > On Mon, 2011-04-11 at 22:42 +0200, Michael Thayer wrote: >> Using a new Type as you suggested >> (Type=ApplicationRelative? Or is that too ugly?) might indeed be more >> sensible (and aesthetical) than the "./" prefix. Someone might even >> want to keep such a desktop file under /share/applications >> and have paths starting with "../.." ... > Should I send a new patch on that basis? > > Regards, > > Michael Personally, I would wait to see if there is more feedback from others before changing anything. ___ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg
Re: Relative paths in .desktop files
On Mon, 2011-04-11 at 22:42 +0200, Michael Thayer wrote: > Using a new Type as you suggested > (Type=ApplicationRelative? Or is that too ugly?) might indeed be more > sensible (and aesthetical) than the "./" prefix. Someone might even > want to keep such a desktop file under /share/applications > and have paths starting with "../.." ... Should I send a new patch on that basis? Regards, Michael -- ORACLE Deutschland B.V. & Co. KG Michael Thayer Werkstrasse 24 VirtualBox engineering 71384 Weinstadt, Germany mailto:michael.tha...@oracle.com Hauptverwaltung: Riesstr. 25, D-80992 München Registergericht: Amtsgericht München, HRA 95603 Komplementärin: ORACLE Deutschland Verwaltung B.V. Rijnzathe 6, 3454PV De Meern, Niederlande Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697 Geschäftsführer: Jürgen Kunz, Marcel van de Molen, Alexander van der Ven ___ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg
Re: Relative paths in .desktop files
On Mon, 2011-04-11 at 13:30 -0400, Marty Jack wrote: > On 04/11/2011 12:06 PM, Michael Thayer wrote: > > --- desktop-entry-spec-1.1.xml 2011-04-11 17:50:02.350865289 +0200 > > +++ desktop-entry-spec-1.1.xml.new 2011-04-11 17:57:39.126810018 +0200 > > @@ -429,7 +429,10 @@ > > > >Icon to display in file manager, menus, etc. If the > >name is an absolute path, the given file will be > > - used. If the name is not an absolute path, the algorithm > > described > > + used. If it starts with "./" it will be treated as a path > > + relative to the directory containing the desktop file and > > + the given file will be used. Otherwise, the algorithm > > + described [...] > Having thought about this just a moment more, I note that I forgot to > mention the other main existing usage, Autostart, where the same > considerations would apply. > > I wonder if there isn't an argument for a new Type= in order to > differentiate this case where you have everything lumped into the one > directory. It feels quite distinct. Actually to my mind the intent is the same (describing an application plus how to locate its essential files on disk - even if in this particular instance the application is an installer for another application) but the context is different (an application installed in the FHS/freedesktop.org layout relative to the filesystem root versus one installed in an unspecified layout relative to a flexible point in the filesystem hierarchy). Using a new Type as you suggested (Type=ApplicationRelative? Or is that too ugly?) might indeed be more sensible (and aesthetical) than the "./" prefix. Someone might even want to keep such a desktop file under /share/applications and have paths starting with "../.." ... > There's nothing GNOME specific about this, and it should work on any > DE. The code you referenced is in glib, which just happens to be > hosted on the GNOME site for historical reasons. I was assuming that people would be happier if I submitted at least one code patch as well, and GNOME is what most of our target users will be running. If other DEs are using the same code in glib, so much the better. I have no objections of course if this or something similar can be adopted in the specification and the current DE code maintainers quickly integrate it themselves! Regards, Michael -- ORACLE Deutschland B.V. & Co. KG Michael Thayer Werkstrasse 24 VirtualBox engineering 71384 Weinstadt, Germany mailto:michael.tha...@oracle.com Hauptverwaltung: Riesstr. 25, D-80992 München Registergericht: Amtsgericht München, HRA 95603 Komplementärin: ORACLE Deutschland Verwaltung B.V. Rijnzathe 6, 3454PV De Meern, Niederlande Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697 Geschäftsführer: Jürgen Kunz, Marcel van de Molen, Alexander van der Ven ___ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg
Re: Relative paths in .desktop files
On 04/11/2011 12:06 PM, Michael Thayer wrote: > Hello Marty, > > On Mon, 2011-04-11 at 11:11 -0400, Marty Jack wrote: > [...] > On Fri, Apr 8, 2011 at 6:28 PM, Michael Thayer > wrote: [...] > I immediately ran up against the >> problem that all paths in .desktop files have to be absolute, which >> obviously isn't an option here. > [...] >> I still have not seen a crisp definition of what you are proposing >> that a relative path specification mean. The question "relative to >> what" has not been answered. If you were to propose some specific >> text change that could be commented on, in sufficient detail that its >> implementation is unambiguous, that would help a lot. > Thanks for the answer. Please find a patch against > desktop-entry-spec-1.1.xml below. I hope that that, together with my > initial posting, makes my intentions slightly clearer. As I said, I > would also interested in other approaches to achieve the same thing. > > By the way, google has already answered my question about where in the > GNOME source code desktop files are handled > ([http://git.gnome.org/browse/glib/tree/gio/gdesktopappinfo.c]). I > would probably not want to attempt anything for other DEs just now. > > Regards, > > Michael > > --- desktop-entry-spec-1.1.xml2011-04-11 17:50:02.350865289 +0200 > +++ desktop-entry-spec-1.1.xml.new2011-04-11 17:57:39.126810018 +0200 > @@ -429,7 +429,10 @@ > >Icon to display in file manager, menus, etc. If the >name is an absolute path, the given file will be > - used. If the name is not an absolute path, the algorithm described > + used. If it starts with "./" it will be treated as a path > + relative to the directory containing the desktop file and > + the given file will be used. Otherwise, the algorithm > + described > in the url="http://freedesktop.org/wiki/Standards/icon-theme-spec";>Icon > Theme Specification will be used to locate the icon. > @@ -471,10 +474,12 @@ > TryExec > >Path to an executable file on disk used to determine if the program > - is actually installed. If the path is not an absolute path, the > file > - is looked up in the $PATH environment variable. If the file is not > - present or if it is not executable, the entry may be ignored (not > be > - used in menus, for example). > + is actually installed. If the path is not an absolute path and does > + not start with "./", the file is looked up in the $PATH > + environment variable. Paths starting with "./" are treated as being > + relative to the directory containing the desktop file. If the file > + is not present or if it is not executable, the entry may be > + ignored (not be used in menus, for example). > > string > NO > @@ -572,7 +577,9 @@ >The Exec key must contain a command line. >A command line consists of an executable program optionally followed >by one or more arguments. > - The executable program can either be specified with its full path or > + The executable program can either be specified with its full path, > + with a path starting with "./" which is treated as relative to the > + directory containing the desktop file, or >with the name of the executable only. If no full path is provided the >executable is looked up in the $PATH environment variable used by the >desktop environment. Having thought about this just a moment more, I note that I forgot to mention the other main existing usage, Autostart, where the same considerations would apply. I wonder if there isn't an argument for a new Type= in order to differentiate this case where you have everything lumped into the one directory. It feels quite distinct. There's nothing GNOME specific about this, and it should work on any DE. The code you referenced is in glib, which just happens to be hosted on the GNOME site for historical reasons. ___ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg
Re: Relative paths in .desktop files
On 04/11/2011 12:06 PM, Michael Thayer wrote: > Hello Marty, > > On Mon, 2011-04-11 at 11:11 -0400, Marty Jack wrote: > [...] > On Fri, Apr 8, 2011 at 6:28 PM, Michael Thayer > wrote: [...] > I immediately ran up against the >> problem that all paths in .desktop files have to be absolute, which >> obviously isn't an option here. > [...] >> I still have not seen a crisp definition of what you are proposing >> that a relative path specification mean. The question "relative to >> what" has not been answered. If you were to propose some specific >> text change that could be commented on, in sufficient detail that its >> implementation is unambiguous, that would help a lot. > Thanks for the answer. Please find a patch against > desktop-entry-spec-1.1.xml below. I hope that that, together with my > initial posting, makes my intentions slightly clearer. As I said, I > would also interested in other approaches to achieve the same thing. > > By the way, google has already answered my question about where in the > GNOME source code desktop files are handled > ([http://git.gnome.org/browse/glib/tree/gio/gdesktopappinfo.c]). I > would probably not want to attempt anything for other DEs just now. > > Regards, > > Michael > > --- desktop-entry-spec-1.1.xml2011-04-11 17:50:02.350865289 +0200 > +++ desktop-entry-spec-1.1.xml.new2011-04-11 17:57:39.126810018 +0200 > @@ -429,7 +429,10 @@ > >Icon to display in file manager, menus, etc. If the >name is an absolute path, the given file will be > - used. If the name is not an absolute path, the algorithm described > + used. If it starts with "./" it will be treated as a path > + relative to the directory containing the desktop file and > + the given file will be used. Otherwise, the algorithm > + described > in the url="http://freedesktop.org/wiki/Standards/icon-theme-spec";>Icon > Theme Specification will be used to locate the icon. > @@ -471,10 +474,12 @@ > TryExec > >Path to an executable file on disk used to determine if the program > - is actually installed. If the path is not an absolute path, the > file > - is looked up in the $PATH environment variable. If the file is not > - present or if it is not executable, the entry may be ignored (not > be > - used in menus, for example). > + is actually installed. If the path is not an absolute path and does > + not start with "./", the file is looked up in the $PATH > + environment variable. Paths starting with "./" are treated as being > + relative to the directory containing the desktop file. If the file > + is not present or if it is not executable, the entry may be > + ignored (not be used in menus, for example). > > string > NO > @@ -572,7 +577,9 @@ >The Exec key must contain a command line. >A command line consists of an executable program optionally followed >by one or more arguments. > - The executable program can either be specified with its full path or > + The executable program can either be specified with its full path, > + with a path starting with "./" which is treated as relative to the > + directory containing the desktop file, or >with the name of the executable only. If no full path is provided the >executable is looked up in the $PATH environment variable used by the >desktop environment. Now we have something to discuss. Your proposed change is crisp and unambiguous. My first observation is that this new definition is in no way useful for existing .desktop files as used in application menu processing or in the available sessions menu (/usr/share/xsessions). We should never expect to have executables in a /share directory because they are architecture specific and the desktop file is architecture independent. By convention icons are either somewhere under /share/icons or in /share/pixmaps and located via the Icon Theme specification. This is done this way so that themes can supersede the application supplied icon. That being said, I am not certain this belongs in the Desktop Entry specification. If this were added I think we need a statement in the Menu specification that this construction is not allowed in those .desktop files. Your intended usage sounds more along the lines of an Autorun file. Maybe you should call it autorun.inf and put whatever you like in it. ___ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg
Re: Relative paths in .desktop files
Hello Marty, On Mon, 2011-04-11 at 11:11 -0400, Marty Jack wrote: [...] > >>> On Fri, Apr 8, 2011 at 6:28 PM, Michael Thayer > >>> wrote: > >> [...] > >>> I immediately ran up against the > problem that all paths in .desktop files have to be absolute, which > obviously isn't an option here. [...] > I still have not seen a crisp definition of what you are proposing > that a relative path specification mean. The question "relative to > what" has not been answered. If you were to propose some specific > text change that could be commented on, in sufficient detail that its > implementation is unambiguous, that would help a lot. Thanks for the answer. Please find a patch against desktop-entry-spec-1.1.xml below. I hope that that, together with my initial posting, makes my intentions slightly clearer. As I said, I would also interested in other approaches to achieve the same thing. By the way, google has already answered my question about where in the GNOME source code desktop files are handled ([http://git.gnome.org/browse/glib/tree/gio/gdesktopappinfo.c]). I would probably not want to attempt anything for other DEs just now. Regards, Michael --- desktop-entry-spec-1.1.xml 2011-04-11 17:50:02.350865289 +0200 +++ desktop-entry-spec-1.1.xml.new 2011-04-11 17:57:39.126810018 +0200 @@ -429,7 +429,10 @@ Icon to display in file manager, menus, etc. If the name is an absolute path, the given file will be - used. If the name is not an absolute path, the algorithm described + used. If it starts with "./" it will be treated as a path + relative to the directory containing the desktop file and + the given file will be used. Otherwise, the algorithm + described in the http://freedesktop.org/wiki/Standards/icon-theme-spec";>Icon Theme Specification will be used to locate the icon. @@ -471,10 +474,12 @@ TryExec Path to an executable file on disk used to determine if the program - is actually installed. If the path is not an absolute path, the file - is looked up in the $PATH environment variable. If the file is not - present or if it is not executable, the entry may be ignored (not be - used in menus, for example). + is actually installed. If the path is not an absolute path and does + not start with "./", the file is looked up in the $PATH + environment variable. Paths starting with "./" are treated as being + relative to the directory containing the desktop file. If the file + is not present or if it is not executable, the entry may be + ignored (not be used in menus, for example). string NO @@ -572,7 +577,9 @@ The Exec key must contain a command line. A command line consists of an executable program optionally followed by one or more arguments. - The executable program can either be specified with its full path or + The executable program can either be specified with its full path, + with a path starting with "./" which is treated as relative to the + directory containing the desktop file, or with the name of the executable only. If no full path is provided the executable is looked up in the $PATH environment variable used by the desktop environment. -- ORACLE Deutschland B.V. & Co. KG Michael Thayer Werkstrasse 24 VirtualBox engineering 71384 Weinstadt, Germany mailto:michael.tha...@oracle.com Hauptverwaltung: Riesstr. 25, D-80992 München Registergericht: Amtsgericht München, HRA 95603 Komplementärin: ORACLE Deutschland Verwaltung B.V. Rijnzathe 6, 3454PV De Meern, Niederlande Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697 Geschäftsführer: Jürgen Kunz, Marcel van de Molen, Alexander van der Ven ___ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg
Re: Relative paths in .desktop files
On 04/11/2011 10:08 AM, PCMan wrote: > My fault! > Field code %k is the file path of the desktop entry file, not it's > parent directory. > So if you named the shell script after the desktop file, like > "installer.desktop.sh", I think an Exec key like this should work. > Exec=%k.sh > This is a little bit tricky, but I think it can solve your problem. > > On Mon, Apr 11, 2011 at 9:08 PM, Michael Thayer > wrote: >> On Sat, 2011-04-09 at 15:34 +0800, PCMan wrote: >>> An easy workaround might be like this: >> [...] >>> Exec=%k/installer.sh >>> >>> The field code %k will be expanded to the location of desktop entry file. >>> This can solve your problem, in a more or less dirty way. >> I tried this out (Nautilus 2.32.0 in Ubuntu 10.10) and unless I did >> something wrong it failed to work. Among the past threads I found >> discussing this, this posting by Waldo Bastian in 2006 - >> http://lists.freedesktop.org/archives/xdg/2006-August/006885.html - >> sounds like he was happy with the idea of relative paths for icons: >> [quote] >>> Prefix with ./ sounds good: >>> >>> * If it starts with "/" it's an absolute path >>> * If it starts with "./" is's a relative path >>> * Everything else is a themed icon name >> [end quote] >> How would other (particularly GNOME) people today see this (for >> executables too), and if favourably, where should I look for the code >> which Nautilus uses to process desktop files? I realise of course that >> what I have in mind isn't quite the way .desktop files are used, but it >> is sufficiently close that it seems to me silly to do something >> separate. >> >> Regards, >> >> Michael >> >> P.S. PCMan, I hope that you don't mind my CC-ing this back to the list. >> >>> On Fri, Apr 8, 2011 at 6:28 PM, Michael Thayer >>> wrote: >> [...] >>> I immediately ran up against the problem that all paths in .desktop files have to be absolute, which obviously isn't an option here. So of course, the question is what the prospects are of getting this changed (I'm also open to suggestions about better ways). And since we are drifting towards the old AppFolder thing here anyway (which I know has been raised every so often here in the past, but never seems to have gone anywhere), what about some convention which would let one put a .desktop file in a directory and have it be a "default" executable for that directory? Just to be clear, since this is not the most important problem we have to solve I won't be able to spend a lot of time on it, but if someone can give me good enough pointers I might find a bit of time to write a couple of patches on my own time out of personal interest. >> -- >> ORACLE Deutschland B.V. & Co. KG Michael Thayer >> Werkstrasse 24 VirtualBox engineering >> 71384 Weinstadt, Germany mailto:michael.tha...@oracle.com >> >> Hauptverwaltung: Riesstr. 25, D-80992 München >> Registergericht: Amtsgericht München, HRA 95603 >> >> Komplementärin: ORACLE Deutschland Verwaltung B.V. >> Rijnzathe 6, 3454PV De Meern, Niederlande >> Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697 >> Geschäftsführer: Jürgen Kunz, Marcel van de Molen, Alexander van der Ven >> >> > ___ > xdg mailing list > xdg@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/xdg > I still have not seen a crisp definition of what you are proposing that a relative path specification mean. The question "relative to what" has not been answered. If you were to propose some specific text change that could be commented on, in sufficient detail that its implementation is unambiguous, that would help a lot. ___ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg
Re: Relative paths in .desktop files
My fault! Field code %k is the file path of the desktop entry file, not it's parent directory. So if you named the shell script after the desktop file, like "installer.desktop.sh", I think an Exec key like this should work. Exec=%k.sh This is a little bit tricky, but I think it can solve your problem. On Mon, Apr 11, 2011 at 9:08 PM, Michael Thayer wrote: > On Sat, 2011-04-09 at 15:34 +0800, PCMan wrote: >> An easy workaround might be like this: > [...] >> Exec=%k/installer.sh >> >> The field code %k will be expanded to the location of desktop entry file. >> This can solve your problem, in a more or less dirty way. > I tried this out (Nautilus 2.32.0 in Ubuntu 10.10) and unless I did > something wrong it failed to work. Among the past threads I found > discussing this, this posting by Waldo Bastian in 2006 - > http://lists.freedesktop.org/archives/xdg/2006-August/006885.html - > sounds like he was happy with the idea of relative paths for icons: > [quote] >> Prefix with ./ sounds good: >> >> * If it starts with "/" it's an absolute path >> * If it starts with "./" is's a relative path >> * Everything else is a themed icon name > [end quote] > How would other (particularly GNOME) people today see this (for > executables too), and if favourably, where should I look for the code > which Nautilus uses to process desktop files? I realise of course that > what I have in mind isn't quite the way .desktop files are used, but it > is sufficiently close that it seems to me silly to do something > separate. > > Regards, > > Michael > > P.S. PCMan, I hope that you don't mind my CC-ing this back to the list. > >> On Fri, Apr 8, 2011 at 6:28 PM, Michael Thayer >> wrote: > [...] >> I immediately ran up against the >> > problem that all paths in .desktop files have to be absolute, which >> > obviously isn't an option here. >> > >> > So of course, the question is what the prospects are of getting this >> > changed (I'm also open to suggestions about better ways). And since we >> > are drifting towards the old AppFolder thing here anyway (which I know >> > has been raised every so often here in the past, but never seems to have >> > gone anywhere), what about some convention which would let one put >> > a .desktop file in a directory and have it be a "default" executable for >> > that directory? >> > >> > Just to be clear, since this is not the most important problem we have >> > to solve I won't be able to spend a lot of time on it, but if someone >> > can give me good enough pointers I might find a bit of time to write a >> > couple of patches on my own time out of personal interest. > -- > ORACLE Deutschland B.V. & Co. KG Michael Thayer > Werkstrasse 24 VirtualBox engineering > 71384 Weinstadt, Germany mailto:michael.tha...@oracle.com > > Hauptverwaltung: Riesstr. 25, D-80992 München > Registergericht: Amtsgericht München, HRA 95603 > > Komplementärin: ORACLE Deutschland Verwaltung B.V. > Rijnzathe 6, 3454PV De Meern, Niederlande > Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697 > Geschäftsführer: Jürgen Kunz, Marcel van de Molen, Alexander van der Ven > > ___ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg
Re: Relative paths in .desktop files
On Sat, 2011-04-09 at 15:34 +0800, PCMan wrote: > An easy workaround might be like this: [...] > Exec=%k/installer.sh > > The field code %k will be expanded to the location of desktop entry file. > This can solve your problem, in a more or less dirty way. I tried this out (Nautilus 2.32.0 in Ubuntu 10.10) and unless I did something wrong it failed to work. Among the past threads I found discussing this, this posting by Waldo Bastian in 2006 - http://lists.freedesktop.org/archives/xdg/2006-August/006885.html - sounds like he was happy with the idea of relative paths for icons: [quote] > Prefix with ./ sounds good: > > * If it starts with "/" it's an absolute path > * If it starts with "./" is's a relative path > * Everything else is a themed icon name [end quote] How would other (particularly GNOME) people today see this (for executables too), and if favourably, where should I look for the code which Nautilus uses to process desktop files? I realise of course that what I have in mind isn't quite the way .desktop files are used, but it is sufficiently close that it seems to me silly to do something separate. Regards, Michael P.S. PCMan, I hope that you don't mind my CC-ing this back to the list. > On Fri, Apr 8, 2011 at 6:28 PM, Michael Thayer > wrote: [...] > I immediately ran up against the > > problem that all paths in .desktop files have to be absolute, which > > obviously isn't an option here. > > > > So of course, the question is what the prospects are of getting this > > changed (I'm also open to suggestions about better ways). And since we > > are drifting towards the old AppFolder thing here anyway (which I know > > has been raised every so often here in the past, but never seems to have > > gone anywhere), what about some convention which would let one put > > a .desktop file in a directory and have it be a "default" executable for > > that directory? > > > > Just to be clear, since this is not the most important problem we have > > to solve I won't be able to spend a lot of time on it, but if someone > > can give me good enough pointers I might find a bit of time to write a > > couple of patches on my own time out of personal interest. -- ORACLE Deutschland B.V. & Co. KG Michael Thayer Werkstrasse 24 VirtualBox engineering 71384 Weinstadt, Germany mailto:michael.tha...@oracle.com Hauptverwaltung: Riesstr. 25, D-80992 München Registergericht: Amtsgericht München, HRA 95603 Komplementärin: ORACLE Deutschland Verwaltung B.V. Rijnzathe 6, 3454PV De Meern, Niederlande Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697 Geschäftsführer: Jürgen Kunz, Marcel van de Molen, Alexander van der Ven ___ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg
Relative paths in .desktop files
Hello, I maintain the Linux version of the VirtualBox Guest Additions (drivers for integration of hosts and guests) and recently tried to make the installation process a bit nicer for users. The Guest Additions are packaged in a shell script which is supplied on a virtual CD image which is mounted in the virtual machine on demand, and in current released versions the normal way of installing them is to open a terminal and run the script. I tried to set things up so that the user could just click on an icon to start the installation process; my first instinct was to create a .desktop file for this, but I immediately ran up against the problem that all paths in .desktop files have to be absolute, which obviously isn't an option here. So of course, the question is what the prospects are of getting this changed (I'm also open to suggestions about better ways). And since we are drifting towards the old AppFolder thing here anyway (which I know has been raised every so often here in the past, but never seems to have gone anywhere), what about some convention which would let one put a .desktop file in a directory and have it be a "default" executable for that directory? Just to be clear, since this is not the most important problem we have to solve I won't be able to spend a lot of time on it, but if someone can give me good enough pointers I might find a bit of time to write a couple of patches on my own time out of personal interest. Regards, Michael -- ORACLE Deutschland B.V. & Co. KG Michael Thayer Werkstrasse 24 VirtualBox engineering 71384 Weinstadt, Germany mailto:michael.tha...@oracle.com Hauptverwaltung: Riesstr. 25, D-80992 München Registergericht: Amtsgericht München, HRA 95603 Komplementärin: ORACLE Deutschland Verwaltung B.V. Rijnzathe 6, 3454PV De Meern, Niederlande Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697 Geschäftsführer: Jürgen Kunz, Marcel van de Molen, Alexander van der Ven ___ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg
