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 @@ > > <entry> > > 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 <something>/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:[email protected] 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 [email protected] http://lists.freedesktop.org/mailman/listinfo/xdg
