Relative paths in .desktop files

[PCMan]

For example, maybe a script can have an embedded icon like this:

#/bin/sh
#xdg_icon=data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAAUA
AAAFCAYAAACNbyblAAAAHElEQVQI12P4//8/w38GIAXDIBKE0DHxgljNBAAO
9TXL0Y4OHwAAAABJRU5ErkJggg==

This is the data url scheme used by browsers.
Then a file manger can parse this, and show the file with the icon. If
the file manager doesn't support this, but supports a thumbnailer, a
thumbnailer can be easily created for it.

On Thu, Jun 23, 2011 at 9:18 PM, PCMan <pcman.tw at gmail.com> wrote:
> 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
>>
>