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. -- dobey _______________________________________________ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg
