Icon parameters in *.desktop files
James Richard Tyrer
tyrerj at acm.org
Wed Jun 22 14:26:45 EEST 2005
I believe that I mentioned this before, but it was suggested to me that
I propose this as a change to the standard.
I originally suggested this as a solution to the issue of generic vs.
specific icons, but it might have other uses as well. Specifically, it
might be useful with icon themes.
My suggestion is that the "Icon" key be allowed to have a list of icons
rather than just one. For example:
Icon=kate,editor,text-editor
Icon=svg,vectorgfx,image
The icon loader would search for the icons in order, first in the user's
selected theme, then in any inherited themes, and finally in HiColor.
So, if a specific icon existed in that theme, it would be used. If not,
the icon loader would look for the listed more generic icons.
The first question I have is what happens if the user selects an icon
with a GUI dialog. Obviously, the whole line is going to be overwritten
and the information about the generic icons would be lost. This appears
to be satisfactory -- if the user selects an icon, it is going to be one
which exists and there is no need for alternatives.
But, if this is considered to be a problem, it would also be possible to
add an additional key. For example:
Icon=kate
GenericIcons=editor,text-editor
Icon=svg
GenericIcons=vectorgfx,image
then if the user changed the icon with a GUI dialog, the list of other
possible substitute icons wouldn't be lost. The icon loader would first
look for the icon specified by "Icon" and if not found would look for
the icons in the "GenericIcons" list. This might also be better for
backward compatibility.
Either way, this also has advantages when running an application on
another desktop. In the first example, if Kate (a KDE application) is
run on GNOME, then if there is no "kate" icon because GNOME doesn't use
the KDE default theme, it would use the GNOME HiColor icon "text-editor"
icon.
--
JRT
More information about the xdg
mailing list