[Fwd: [kde-artists] branches/KDE/3.5/kdelibs/pics/hicolor]

[Kenneth Wimer]

Hi all,

I will end this discussion by quoting the spec itself and explaining  
how the misunderstanding in wording in the spec itself has lead to  
this problem.

Here is the first mention of the hicolor theme in the spec:

"In order to have a place for third party applications to install  
their icons there should always exist a theme called "hicolor" [1].  
The data for the hicolor theme is available for download at: http:// 
www.freedesktop.org/software/icon-theme/. Implementations are  
required to look in the "hicolor" theme if an icon was not found in  
the current theme."

The confusing part is this:

"The lookup inside a theme is done in three phases. First all the  
directories are scanned for an exact match, e.g. one where the  
allowed size of the icon files match what was looked up. Then all the  
directories are scanned for any icon that matches the name. If that  
fails we finally fall back on *unthemed* icons. If we fail to find  
any icon at all it is up to the application to pick a good fallback,  
as the correct choice depends on the context."

The "unthemed" part is confusing, as in artwork there is really no  
way to make an "unthemed" work. It might be neutral and fit with many  
themes but it still has its own characteristics.

Later this is clarified:

"It is recommended that the icons installed in the hicolor theme look  
neutral, since it is a fallback theme that will be used in  
combination with some very different looking themes. But if you don't  
have any neutral icon, please install whatever icon you have in the  
hicolor theme so that all applications get at least some icon in all  
themes."

Note that everything is clarified in this last phrase. Third party  
application that install icons into hicolor should stick to a style  
of theme which is neutral enough to fit with many other themes. The  
mention of "unthemed" should be corrected to improve continuity in  
the spec.

Bye,
Kenneth

On Apr 24, 2006, at 5:34 PM, James Richard Tyrer wrote:

> NOTE to KDE-Core-Devel: Since there is disagreement among the  
> artists, and, again, my supposed job as the HiColor maintainer is  
> being questioned, this has become a Core issue.  Perhaps a question  
> that the TWG needs to consider.  Also would someone in authority  
> please determine if KW was correct when he gave me the job of  
> HiColor maintainer. Perhaps this could be made more official.
>
> IAC, what is the function of the HiColor icons theme in KDE.  GNOME  
> uses it as an icon theme.  FreeDesktop.org says that it is an icon  
> theme. But JR seems to have made it a crusade to keep KDE from  
> conforming to other desktop's usage and the standards organization.
>
> HiColor is a theme and was moved to KDEArtwork at the request of  
> other developers.  However, it is necessary to install the  
> "index.theme" with KDELibs to confirm to the FD.o standard.
>
>> -------- Original Message --------
>> Subject: [kde-artists] branches/KDE/3.5/kdelibs/pics/hicolor
>> Date: Tue, 11 Apr 2006 15:43:14 +0000
>> From: Jonathan Riddell <jr at jriddell.org>
>> To: kde-commits at kde.org
>> CC: kde-artists at kde.org, cniehaus at gmx.de
>> SVN commit 528691 by jriddell:
>> Revert previous two commits.  For the second time.
>> hicolour is not a theme, it is a namespace for third party icons.
> To be blunt, you are not the final arbiter of facts.  Stating the  
> same thing over and over (without any supporting facts) does not  
> make it true.  As stated in previous commit comments, GNOME uses  
> HiColor as a theme, therefore KDE also needs to use it as a theme.
>>  M  +1 -2      index.theme  --- branches/KDE/3.5/kdelibs/pics/ 
>> hicolor/index.theme #528690:528691
>> @@ -100,7 +100,6 @@
>>  Comment[uk]=Основна тема піктограм
>>  Comment[zh_CN]=默认图标主题
>>  Comment[zh_HK]=後備高彩圖示主題
>> -Inherits=kdeclassic,crystalsvg
>
> Unfortunately, our HiColor theme is not complete like GNOME's, and  
> most of our HiColor icons are in the KDEClassic theme which is not  
> complete either (because it is not maintained).  Therefore this  
> "Inherits" is needed so that when the icon loader looks for a  
> HiColor icon and doesn't find it (which would be what usually  
> happens in KDE) it will use a KDEClassic icon if available or if  
> none is available, will use a CrystalSVG icon.  Until we have a  
> complete HiColor theme, like GNOME does, this is needed.
>
> IIUC, this has absolutely nothing to do with the claim that HiColor  
> is not a theme.  If it is only a "namespace", it is still used as a  
> fall back theme and since it is not complete in KDE, it also needs  
> fall backs.
>
> Perhaps you have not considered what happens if a user selects a  
> theme other than CrystalSVG.  If it is your intention to support  
> ONLY CrystalSVG then the other themes should be removed from  
> KDEArtWork and there should be no way to select the icon theme in  
> the KCM!
>
>>  DisplayDepth=32
>>  Example=exec
>>  LinkOverlay=link
>> @@ -116,7 +115,7 @@
>>  SmallSizes=16
>>  PanelDefault=32
>>  PanelSizes=16,22,32,48
>> -Hidden=false
>> +Hidden=true
>
> Since GNOME uses HiColor as a theme, this is necessary.  Otherwise,  
> the theme would be hidden in GNOME if KDE was installed after  
> GNOME. Perhaps you have not considered the fact that a user might  
> install BOTH KDE and GNOME.
>
>>  Directories=192x192/apps,128x128/actions,128x128/apps,128x128/ 
>> devices,128x128/filesystems,128x128/mimetypes,96x96/actions,96x96/ 
>> apps,96x96/devices,96x96/filesystems,96x96/mimetypes,72x72/apps, 
>> 64x64/actions,64x64/apps,64x64/devices,64x64/filesystems,64x64/ 
>> mimetypes,48x48/actions,48x48/apps,48x48/devices,48x48/filesystems, 
>> 48x48/mimetypes,36x36/apps,32x32/actions,32x32/apps,32x32/devices, 
>> 32x32/filesystems,32x32/mimetypes,24x24/apps,22x22/actions,22x22/ 
>> apps,22x22/devices,22x22/filesystems,22x22/mimetypes,16x16/actions, 
>> 16x16/apps,16x16/devices,16x16/filesystems,16x16/ 
>> mimetypes,scalable/actions,scalable/apps,scalable/devices,scalable/ 
>> filesystems,scalable/mimetypes,16x16/stock/chart,16x16/stock/code, 
>> 16x16/stock/data,16x16/stock/document,16x16/stock/form,16x16/stock/ 
>> generic,16x16/stock/image,16x16/stock/io,16x16/stock/media,16x16/ 
>> stock/navigation,16x16/stock/net,16x16/stock/object,16x16/stock/ 
>> table,16x16/stock/text,24x24/stock/chart,24x24/stock/code,24x24/ 
>> stock/data,24x24/stock/do
> cu
>>  ment,24x24/stock/form,24x24/stock/generic,24x24/stock/image,24x24/ 
>> stock/io,24x24/stock/media,24x24/stock/navigation,24x24/stock/net, 
>> 24x24/stock/object,24x24/stock/table,24x24/stock/text,32x32/stock/ 
>> chart,32x32/stock/code,32x32/stock/data,32x32/stock/document,32x32/ 
>> stock/form,32x32/stock/generic,32x32/stock/image,32x32/stock/io, 
>> 32x32/stock/media,32x32/stock/navigation,32x32/stock/net,32x32/ 
>> stock/object,32x32/stock/table,32x32/stock/text,36x36/stock/chart, 
>> 36x36/stock/code,36x36/stock/data,36x36/stock/document,36x36/stock/ 
>> form,36x36/stock/generic,36x36/stock/image,36x36/stock/io,36x36/ 
>> stock/media,36x36/stock/navigation,36x36/stock/net,36x36/stock/ 
>> object,36x36/stock/table,36x36/stock/text,48x48/stock/chart,48x48/ 
>> stock/code,48x48/stock/data,48x48/stock/document,48x48/stock/form, 
>> 48x48/stock/generic,48x48/stock/image,48x48/stock/io,48x48/stock/ 
>> media,48x48/stock/navigation,48x48/stock/net,48x48/stock/object, 
>> 48x48/stock/table,48x48/stock/text
>>   [16x16/actions]
>
> Please discuss the issue on the lists if you disagree rather than  
> playing tit for tat in the SVN repository.
>
> -- 
> JRT, supposed HiColor theme maintainer.