Relative paths in .desktop files

[Michael Thayer]

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 @@
> > > >  	    <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
> 
> _______________________________________________
> xdg mailing list
> xdg at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/xdg

-- 
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