Proposed improvement to the Desktop Entry Specification: Relative icon paths
magnus.bergmark at gmail.com
Tue Sep 23 01:01:32 PDT 2008
In the current Desktop Entry
it's possible to specify an icon for the directory (in case of a
.directoryfile) or the
.desktop file itself. Implementations are to follow this rule:
> Icon to display in file manager, menus, etc. If the name is an absolute
> path, the given file will be used. If the name is not an absolute path, the
> algorithm described in the Icon Theme Specification<http://freedesktop.org/wiki/Standards/icon-theme-spec>will be used to locate the icon.
The Icon Theme Specification<http://freedesktop.org/wiki/Standards/icon-theme-spec>specifies
that the icon should be seached for in a collection of paths
related to the current theme.
I propose that we allow the usage of relative paths in some way also.
1. I use a lot of .directory files to make directories containing a movie
have the movie poster as the icon. This behaviour could apply to any form of
media, like comic books, music (album art) and photos.
2. A vendor might want to bundle an icon to a piece of software they're
distributing to go with a .desktop file which are not to go in the
desktop menu and therefore are still located in the application directory.
1. I have a script looking for a specially named file (.folder.png) and
when it finds one, it will create or update the .directory file in the
same location as the icon file with the full path of it. Everytime I move a
directory, mount it on another computer or just have a soft link I browse
through, I have to rerun the script in the current path I'm using.
Applications like Amarok will explicitly create the .directory file with
the icon path set to the absolute path to the directory, plus the filename
of the album art.
2. In this case, the install script must update the .desktop file with
the full path to the icon, and hope that the user will never move this
directory. A install script is now required even if it wasn't before.
I propose that we allow the user to specify a relative path to a file to use
as an icon. How we do this is not really important, but I have these
separate suggestions (ordered by how it "should" work, IMHO):
- Icon paths starting with a dot will be relative from the directory
containing the Desktop Entry; the path ./folder_icon.png in
/home/user/Documents/BookProject/.directory will set the icon to
- When no absolute path is specified, first search the containing
directory before following the Icon Theme Specification. In the example
above, we would have entered folder_icon.png and this file would have
been found locally before searching for it and therefore set.
- Usage of some other prefix to denote a relative path, rules following
- Using a different setting, or a compliment to the setting (like
Icon=..., IconPath=Relative), rules following the others
I do not think the first few would be that hard to implement, altough my
knowledge in this area is a bit clouded. It is important to specify exactly
where the relative path will apply from when loading the icon, and when this
is done, it should be easy enough to do the rest. According to how I think
would be best is to have the relative path apply to the directory *
containing* the Desktop Entry. That is, if I use some form of file manager
that follows the specs and I have the following structure:
│ +─ .directory (Icon=./folder_icon.png)
│ +─ folder_icon.png
│ +─ (...)
+─ .directory (Icon=./.project.png)
+─ Generate Documentation.desktop (Icon=./gendocs.png)
- Visiting SoftwareProject would let me see a entry called Generate
Documentation and have the Projects/SoftwareProject/gendocs.png file as
- Visiting BookProject would let me see that the current directory have
Projects/BookProject/folder_icon.png as the icon (if whis is displayed at
- Visiting Projects will let me see two directories, BookProject and
SoftwareProject, both having their respective icons correctly as expected.
I would not be surprised if it's hard to do this in reality since the most
simple things are often the hardest to do in a large codebase. It would also
not surprise me if this is the reason it's not in the spec from the
beginning... Perhaps we could make this easier if we specify that a local
path going up a directory structure will be illegal and that the path must
be from the directory downwards.
Anyway... Let's discuss!
PS. I hope this is the correct list to mail this to. If not, please direct
me to where I should send this proposal. .DS
Magnus Bergmark - magnus DOT bergmark AT gmail DOT com
Fingerprint: 0E6F D2DB F0EF 534A 2184 52AF 7BE8 4794 DB6A A648
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the xdg