Relative paths in .desktop files
PCMan
pcman.tw at gmail.com
Thu Jun 23 06:18:08 PDT 2011
On Thu, Jun 23, 2011 at 9:06 PM, David Faure <faure at kde.org> wrote:
> On Thursday 23 June 2011, Marty Jack wrote:
>> I continue to oppose this. As I understand it, the intended use is for
>> installation kits similar to how Autorun works on Windows.
>>
>> I would also refer everyone to the Autostart spec
>> http://standards.freedesktop.org/autostart-spec/autostart-spec-latest.html
>> which, in section Autostart of Applications After Mount, already deals with
>> this after a fashion. I am not convinced that definition does not suffer
>> from the same problems I point out here.
>>
>> The current way this proposal is defined is of no use for the existing
>> applications of Desktop Entry, to wit the application menu
>> (/usr/share/applications) and the X sessions menu (/usr/share/xsessions).
>>
>> The current proposal breaks the separation between architecture independent
>> items like the icon and architecture dependent items like the executable.
>>
>> I would like someone to take me through how the multi-architecture scenario
>> would work. If Exec points to a relative path, how do we have an install
>> kit that has a binary for x86, a binary for s390, and a binary for arm,
>> all of which are currently important Linux architectures.
>
> Well, this is just one use case.
>
> What about the use case where I write a script and a .desktop file for my wife,
> which she can put in any directory she wants?
> With a relative path I can now do that, and she can move the .desktop file and
> the script together and it will continue to work.
> Without support for relative paths, this would break, just because the
> .desktop file requires an absolute path.
For this purpose, mechanisms like application bundle used by Mac OS X
and ROX desktop have much better usability. All pieces of the whole
application are bundled in one application folder. Putting a script
along with a desktop file doesn't make things easier than just open
the script. If you just want to give the script an icon, you can embed
the icon in the script, and write a thumbnailer for it.
IMHO, having "run_me.sh" in the folder is enough.
Having "run_me.sh", "run_me.desktop", and "run_me.png" in the folder
won't increase usability.
There are several ways to embed an icon in a script file. Just apend
it to the end of file, or encode it with base64 or some others. Then
having a thumbnailer decode such thing won't be too difficult. By
adding a comment line containing specific strings in the script,
during mime-type sniffing, it's easy to recognize this kind of file
with mime-type magic rules.
> I believe this has more uses than installation kits / autorun.
>
> --
> David Faure, faure at kde.org, http://www.davidfaure.fr
> Sponsored by Nokia to work on KDE, incl. Konqueror (http://www.konqueror.org).
> _______________________________________________
> xdg mailing list
> xdg at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/xdg
>
More information about the xdg
mailing list