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 
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" 


More information about the kde-core-devel mailing list