Icon parameters in *.desktop files

[James Richard Tyrer]

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