Icon parameters in *.desktop files
James Richard Tyrer
tyrerj at acm.org
Wed Jun 22 12:26:45 BST 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:
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:
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
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"
More information about the kde-core-devel