Proposed improvement to the Desktop Entry Specification: Relative icon paths

[Magnus Bergmark]

> I don't think your proposal is the best way to solve your use cases. For
> one, having .directory files in each directory is deprecated.


I did not know that. Is there any place for me to find out how it's supposed
to be? I had actually just "reversed engineered" how .desktop files were
used before reading the specs on the Free Desktop website a couple of weeks
ago just to find out how to use relative paths.


> Secondly,
> a lot of multimedia software already has methods for setting album art
> for music and movies. It would probably be better to specify some
> standard method for multimedia players to use, and then have file
> managers also support that method. Using a .directory file seems
> redundant, and adds a lot of disk access requirements that are not
> really necessary to have.


I agree wholeheartedly here. Opening one of the directories I'm talking
about takes long time in Konqueror since there is so many icons to display,
for example. I realize that this is one of the worst solutions to do this,
but it's also the only possible one right now AFAIK. I'd love to have some
form of Amarok-like project for movies, and it would be very nice if file
managers could also display these directories like they should when browsing
there (perhaps with some KPart in the case of KDE)! Do you know if there are
any project underway doing this? I'd probably join that project if you do.

An idea just hit me, and that is that the folder icon perhaps could be
stored on some form of metadata, like extended arguments of the directory
inodes (I do not know what can be stored here) or in NEPOMUK in the case of
KDE4. This could work between apps that support it and be totally
transparent in the apps which do not.

For your second use case, I'm not sure what you mean. A .desktop file
> that is not intended to go into a standard applications directory is
> almost entirely useless.


I have created desktop files as elaborate "shortcuts" to be run in a display
manager. I have, for example, on my work computer a directory full of
.desktop files named SERVER1.desktop, SERVER2.desktop and so on (with
"SERVERn" switched with an actual server name, of course). These shortcuts
will, when opened, open a new terminal with a ssh session on that particular
server, with compression and X-forwarding on, plus some other options if I
ever need them. Could this be solved without .shortcut files? Yes, of
course. It's very nice to use, tough. It's not that useless, IMO.

No, I do not use custom icons here, just some standard icon for a terminal,
but if I ever would want to have one, I'd rather place that icon in the same
folder as all those .desktop files since the icon then would be both theme
and environment agnostic -- it's just my own icon, and I'd rather not place
it among icons in another person's theme and copy it around to all the other
themes or place it in the fallback theme. Again, in this case there would
not be a real problem, since I can set an absolute path to the icon easy --
I don't move them around anyway.


> Perhaps you should look at some of the
> software bundle proposals and implementations, and work with using
> those, instead. Another option is the xdg utils scripts, to install
> the .desktop file and icons in the appropriate places. I can only
> presume that your uninstalled application also intends to not follow
> the Icon Theme and Icon Naming specifications either.
>

Oh, I just tried to come up with another use case where it would make sense.
It was entierly theoretical and not related to me.
Seems like you had a much better solution than my proposal, so I guess this
use-case is pretty invalid now!


> And I don't see
> setting the directory's icon as useful really.
>

I do see directory icons as useful, but that may be because my primary DE
(KDE) does not support custom badges on the icons, colorization of the
folder name or any other real method to make some directories stand out.
In GNOME, I could set a badge, in Mac OSX, I can set a color and in Windows,
a file called "folder.jpg" will be displayed as the parent's folder icon.
KDE provides no real way to do this (or does it?).

I navigate large directory structures often (I have much of my life stored
on my HDDs; much more than one 1TB of data sorted several levels deep) and
it helps me a lot the see the most common directories faster when doing so.
This, of course, is still another case of "not needing relative paths", but
this proposal is all about making this easier to do, not that I really
*need* it. :-)


> Setting an icon for the
> actual executable would be much more useful, though elf binaries do
> not have resources like win32 binaries do.


Yes, this would be nice, altough I think the solution used by Free Desktop
is better on many ways. The best solution, IMHO, would be to support
embedded icons, but the use of them would be throwned upon and that .desktop
files easily could override them. Proprietary distributors could embed their
"official icon" and it would be used everywhere when a "free" icon wouldn't
exist. OSS distributors could still go with official icons following themes
and icon styles, etc. like normal.

-- 
Magnus Bergmark - magnus DOT bergmark AT gmail DOT com
GPG/PGP: 0x7BE84794DB6AA648
Fingerprint: 0E6F D2DB F0EF 534A 2184 52AF 7BE8 4794 DB6A A648
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.freedesktop.org/archives/xdg/attachments/20080927/e998c854/attachment.html