Relative paths in .desktop files

[Michael Thayer]

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 @@
> > >  	    <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
> > >  	  in the <ulink
> > >  	  url="http://freedesktop.org/wiki/Standards/icon-theme-spec">Icon
> > >  	  Theme Specification</ulink> 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.thayer at 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