Relative paths in .desktop files

[Michael Thayer]

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.thayer at 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