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