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...@gmail.com> wrote: > On Thu, Jun 23, 2011 at 9:06 PM, David Faure <fa...@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, fa...@kde.org, http://www.davidfaure.fr >> Sponsored by Nokia to work on KDE, incl. Konqueror >> (http://www.konqueror.org). >> _______________________________________________ >> xdg mailing list >> xdg@lists.freedesktop.org >> http://lists.freedesktop.org/mailman/listinfo/xdg >> > _______________________________________________ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg