Icon parameters in *.desktop files

[Rodney Dawes]

I think this would be better off in the Icon Theme spec itself, rather
than adding stuff to the desktop files. Something like:

Provides=kate,gedit

in the text-editor.icon file for example.

This would give more control to the icon theme authors over what icons
get shown where, rather than putting all the control for the app icons
inside the desktop files.

I will have a patch to the Icon Theme spec soon to propose this more
formally.

-- dobey


On Wed, 2005-06-22 at 04:26 -0700, James Richard Tyrer wrote:
> 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.
>