Icon parameters in *.desktop files

[James Richard Tyrer]

Rodney Dawes wrote:
> On Thu, 2005-06-23 at 21:42 +0200, Josselin Mouette wrote:
> 
>> For better integration, icons from the icon theme should be used as
>>  much as possible. When you have a set of blue vector icons, 
>> getting a few bitmap icons that don't fit in the theme for 
>> applications isn't pleasing for the eye.
> 
> 
> It is highly implausible for any single icon theme to provide an icon
>  for every single application that may be installed on any one single
>  user's desktop. Having said that, apps will have to be dealt with by
>  the icon themes on an app by app basis. An application's icon is 
> part of that application's branding. I somehow doubt that users want
>  every single app on their computer that can play audio, or edit
> text, or browse the web, to use the same icon. However, this is
> quickly degenerating into a thread about Usability, and this mailing
> list is not about usability. It is about desktop integration. And it
> seems to me, that the best way to integrate desktops with regards to
>  fallbacks for application icons, is to give the control to theme 
> authors, and not application authors. The fallbacks are not only 
> useful for application icons. We need this functionality for mime 
> type icons as well. Also, the Icon Theme specification clearly states
>  that apps should provide their own app icons, and install them to 
> the hicolor theme, and that those icons should be in a 
> middle-of-the-road style, so as it will not look out of place with 
> the majority of themes.
> 
> 
>> For each application, you would have to search through all 
>> available icons to see which ones are suitable.
> 
> 
> No. With the Provides method, the implementation should just set up 
> aliases in memory and store that in the cache. The actual code for 
> parsing a comma separated list would be about the same whether it is 
> in the .desktop file parser, or in the icon theme parser. It would 
> probably actually be slower in the .desktop file side, since then it 
> would have to request every icon in the list, until it finds one, 
> while with the provides/aliases method, it can just make one request.
> 
> 
> 
You appear to have some valid points.  I am not committed to any
solution to this.  That is why I posted if for discussion.

Could you please provide a little more detail of exactly how your idea
would work.  Specifically, where is this: "text-editor.icon" file?  Is
this a new file?

I see two issues here:

1.	If the application is responsible for this, then the application
	must know the names of all available icons.

2.	If the icon theme is responsible for this, then the icon theme
	must know the names of all applications.

There problems either way.  I see less problems with #1, but although it
would work, you have correctly pointed out that it isn't an ideal
solution.  Using:
	
	Icon=<app_icon>
	IconList=<icon1>,icon2>

would make it possible for an application to specify alternatives but
the application developer would have to know the names of these icons.
So, this is still a good idea even though it does not solve the entire
problem.

The "IconList=" key would allow a comma separated list of icon names.

Standardized icon names would make #1 better, but wouldn't completely
solve the problem.

For a total cross platform solution where the application developer
isn't going to know the names of the available icons, we need something
more.

So, what we need to do is to think about this some more, and try to come
up with something that eliminates these problems.

If we use:
	
	Icon=<specific_icon>
	GenericIcon=<generic_type>

what can we do with this so that the icon theme would find an icon when
the specific icon doesn't exist in the user's selected icon theme?

The "GenericIcon=" key would allow only one argument which is a type,
NOT an icon name.  It also appears to me that we would need to have a
standard list of generic icon types.

This is not an either or question, both of these methods have merit and
we might want to use both: "IconList=" & "GenericIcon=" since they could
address different issues.  If both were used, after "Icon" which would
clearly be used first, I think that "IconList" should come next and then
"GenericIcon".

-- 
JRT