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

[Luca Ferretti <elle uca libero it>]

Il giorno gio, 21/12/2006 alle 10.42 -0500, Rodney Dawes ha scritto: 
> On Thu, 2006-12-21 at 13:38 +0100, Luca Ferretti wrote:
> > 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.
> 
> If the index.theme is actively specifying the Type, then it is not using
> the default, it is overriding the default with a specific type.
> Threshold is basically a hack to work around the lack of using standard
> sizes, in various apps, such as the panel. I think the best solution is
> to make any directory where PNG is used for the icons, to be Type=Fixed.

Rodney, I checked the Icon Lookup definition in Icon Theme Spec and its
implementation in gtk (gtk/gtkicontheme.c).

IMHO there is a bug in Icon Lookup definition and current values (icons
at 22 _and_ 24 pixels, default Threshold to 2) are showing us this bug.

In Icon Lookup section (icon theme spec) we have something like:

        LookupIcon (iconname, size, theme) {
          for directory in $(all directories) {
            if DirectoryMatchesSize(subdir, size) {
              search icon here and return if available
            }
          }
          {search again returning the closest}
        }
        
the function to check if a directory matches the desired size is defined
as follow:

        DirectoryMatchesSize(subdir, iconsize) {
          read Type and size data from subdir
          if Type is Fixed
            return Size == iconsize
          if Type is Scaled
            return MinSize <= iconsize <= MaxSize
          if Type is Threshold
            return Size - Threshold <= iconsize <= Size + Threshold
        }
        
GTK+ seems to implement this in a proper way, so while searching for
icons at 24 pixels we have:

        1 current subdir: 22/apps
        2 check if 22/apps match
        3 type is threshold, use (<= iconsize <=)
        4 22 - 2 <= 24 <= 22 + 2 --> TRUE
        5 OK, 22/app is good
        6 OK the icon is here
        7 return 22/apps/iconname and stop seach
        
So, due to chosen values, GTK+ simply breaks the icon lookup at 22
pixels.

IMHO the Icon Lookup mechanism (and the toolkit/applications
implementing it) should be updated to perform something like:

        ...
        5  OK, 22 is good
        6  OK the icon is here
        7  real_distance is != 0 --> continue search
        8  found another matching subdir 24/app
        9  OK, 24/app is good
        10 OK the icon is here
        11 real_distance is 0 --> use this
        
IMHO the issue is in the Icon Lookup mechanism currently defined in Icon
Theme Spec: you want an icon at XX pixels, the icon is available at XX
pixel, but you get the icon at smaller size 'cause it's good enough for
the lookup mechanism.

So I think that proposed changes to index.theme from you and myself,
setting hicolor-icon-theme to Fixed or decreasing the Threshold value
for 22 and 24, are just hacks to avoid this odd condition; if the
desired icon is available, you have to use it even icons, no matter
about icons at other sizes or values for Threshold and Type keys in
index.theme.

Alex? (BTW Alex is away for Xmas, he'll be back by January
8th)

> > 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).
> 
> The solution is to specify Size=48 in the index.theme for the scalable
> directory. This won't break 128x128 icons, as the icons will get scaled
> down to the canvas size. The problem with 48x48 icons with Size=128 is
> that the icons are merely placed on the center of a 128x128 canvas, and
> then scaled down, rather than simply keeping their 48x48 canvas size.
> The simplest solution is therefore to use Size=48, as this means that
> all icons above 48x48 will still work properly. This is in fact, the
> fix that we ship in SLED and OpenSUSE.

Dunno. The icon theme spec doesn't say too much about scalable subdirs. 

But SVG icons are allowed in any subdir (I think now we are using PNG at
16, 22, and 32 pixels only to skip the rendering) while of course their
usage are defined by value of Type key.

So, following Icon Theme Spec, SVG icons at 48 pixels could installed
under 48x48/$(context). The toolkit should be able to scale them if Type
isn't Scalable.

The current role of scalable/$(prefix) in hicolor seems unclear to me.
Maybe the Icon Theme Spec should declare a nominal/default size (48
pixel) when Type=Scalable. Then we could update hicolor-icon-theme as
you suggested.