Huston, we have a problem (A.K.A. Threshold vs Fixed in hicolor-0.x theme)

[Luca Ferretti <elle uca libero it>]

Hy everyone, 

It seems there is another issue in hicolor icon theme. Due to this,
24x24 icon installed under hicolor directory are ignored.

This is not a GNOME 2.17/2.18 only issue, but affects also current
stable release, 'cause is related to the Icon Theme Spec itself and
definitions in index.theme file in hicolor. Maybe I should send it to
xdg list too, but I'm still not subscribed, I'll do it later.

== The Issue ==

The issue is very simple: 22x22 icons installed in hicolor are used when
24x24 icons are needed.

You can see this in icons for Alacarte and GnomePowerManager under
System->Preferences menu as well as in Application->Graphics->Evince
(hidden by default). Of course, now that GNOME applications are moving
themself icons in hicolor and are using Tango suggested sizes, more
applications will start to show this wrong behavior.

A note: icons on GtkToolbars (default size is 24x24), like the new stuff
in Epiphany, seems un-affected. Maybe GTK+ don't respect the icon theme
search algorithm.

== The Reason ==

As I announced in previous statement, this issue seems related to icon
theme search algorithm and icon theme default values.

The hicolor icon theme uses the "Threshold" value for Type key (== "the
type of icon sizes for the icons in a directory"; BTW threshold is the
default value for this key). Threshold means that "icons in this
directory can be used if the size differ at most this much from the
desired size. Defaults to 2 if not present."

It seems to me that 24x24 icons from hicolor theme are simply ignored
'cause the search order is 16->22->24->32->... and the value for Type
keys is Threshold.

If I'm right, searching for "nautilus" icon at 24 pixels: 
     1. nautilus icon available at 16 pixels 
     2. 16 pixels icons are good for 14~18 pixels too
     3. too small for 24, search again 
     4. nautilus icon available at 22 pixels 
     5. 22 pixels icons are good for 20~24 pixels too
     6. OK for 24, we have it, stop search

Note: stuff in GNOME icon theme are unaffected, 'cause in the
index.theme file for GNOME icon theme all Type keys are using the
"Fixed" value.

== The Solution ==

I'm sorry about it, I forgot the threshold behavior and I didn't see
anything strange on screen when I tested changes for 0.10 release of
hicolor-icon theme [1].

There are different solutions for this issue, but probably the best is
force "Threshold=1" for 22x22 and 24x24 directories. 

Let me explain the reasons of this choice.

     A. hicolor icon theme is the default icon theme, so it should
        follow default values from Icon Theme Spec. Of course we can say
        that default values are wrong (changing the default value for
        Type from Threshold to Fixed), but by now Threshold is the
        default.
     B. using "Fixed" only for 22 and 24 seems odd to me
     C. the 22 vs 24 pixels battle should be only a transitional phase.
        The 24 pixels icons is the legacy past, 22 pixels icons is the
        future. When the GNOME icon theme will be fully ported to Icon
        Naming Spec, we can move stuff (panel menus and toolbar) to new
        size
     D. of course we can't switch 22 and 24 order in hicolor just to fix
        a GNOME/GTK+ only,

The only way to fix the overlapping of _directly_ handled sizes in
hicolor (this is the real core of the issue) seems to me remove this
overlapping.

It seems to me the best solution. Any other idea? Comments? Caveats?

== Other sizes ==

The gap between other sizes is greater then default value for Threshold,
so only 22 and 24 are affected.

The non standard 34 pixels size could overlap too . Current hicolor
defines 32 and 36 pixels sizes, so if you have icons at 32 _and_ 36
pixels and you have to draw it at 34, the application will always use
the icon at 32 pixels scaled up to 34.

The same occurs at 23 pixels with the suggested change.

But 23 and 34 pixels are no-standard icon sizes, so I think that it's
not so important if you scale up the smaller size or you scale down the
bigger size.

== New Package ==

Alex proposed me to co-maintain hicolor package, but by now I haven't
yet asked permission on fd.o. We have to wait Alex for a new release.

Moreover tracking this issue and testing different configurations I
found another size related bug in GNOME for icon installed in hicolor.

To see it, select Applications->Accessories->Text Editor (gedit), right
click and choose Add to Desktop item in popup menu. The new launcher on
desktop is using icon at 48 pixel (using default GNOME preferences, of
course). Now do the same with System->Preferences->Menu Layout
(alacarte). The new launcher is using a tiny scaled down icon.

This should related to values for Size (128) and MinSize (1) keys for
scalable icons in hicolor. Icons in GNOME icon theme are unaffected,
'cause here Size is 48 and MinSize is 32.

I don't know what's the correct solution here, I prefer reread the Icon
Theme spec. In fact, setting Size=48 means that _any_ theme and
application will have to provide scalable icons at 48 pixels: this is
the GNOME and Tango icon themes behavior, but, if I'm right, in Oxygen
icon theme scalable icons are at 128x128 pixels (to respect the value in
hicolor or to have detailed icons? dunno).

Please also note that this could be a Nautilus only issue. If you add
launchers to panel using Add to Panel entry, then scale your panel to 48
pixels, icons for Alacarte is showed at 48 pixels as it should be.

== External Deps ==

Elijah, 'cause the fix for 22 vs 24 pixels icon seems a minor update,
should we update the hicolor-icon-theme version in ExternalDependencies
or not?

IMHO not: GNOME will work better with future hicolor-0.11, anyway the
current 0.10 is the minimum version required to find icons in any
context. 

====================

Cheers,
Luca


[1] moreover my fuc*ed CRT have started to show a blurred area in the
middle of the screen, and nobody will gift me a cool LDC for Xmas :-(