Re: Themes, Icons, Desktop Integration/Consistency, and The GNOME Architecture

[Bill Haneman <bill haneman sun com>]

On Fri, 2003-03-07 at 15:11, Owen Taylor wrote:
> ... 
> > Is this the same thing as the "gtk-icon-size" string in the RC file, or
> > different?  I think we should surely have only one icon-sizing API.
> 
> The icon size enumeration has both small-toolbar, and large-toolbar;
> it basically predates the use-configurable icon sizes, but there
> might be also some idea here that you might want to switch the
> relative size of your toolbar icons without changing your overall
> icon scale.

I guess the usual issues with multiple APIs/implementations apply here;
it would be an accessibility issue if some kinds of icony-things didn't
work with the "theme", and it seems broken for the theme to have to deal
with two kinds of icon-size specification.

In other words, it'd be an accessibility bug if the toolbar icons didn't
track the themed icon size.  It seems sorta daft anyway, given that our
RC-file icon size mechanism supports the addition of new icon-size
groups into the string.  Currently the panel deals with this by looking
for icon sizes that the default stock gtk+ icon mechanism doesn't
explicitly know anything about.  If you wanted to change your toolbar
icons only (without changing the other sizes) then it seems like it
should use this same mechanism.  Otherwise it'll just appear to break
our "Large" themes.

...
> > One upon I time I thought I heard that gtk-stock-icons should
> > integrate/interop with the desktop-icon-set "spec" (which I guess is
> > still kind of immature?)  I raised this a few weeks ago but nobody took
> > the bait.  It seems to me that, if feasible, this is the kind of thing
> > we should aim for in GTK+-2.6 if it can't be done in time for GTK+-2.4
> > (but surely we don't want to wait for GNOME 2.8 to fix this!)
> 
> It's listed on http://www.gtk.org/plan/2.4/; 

Cool; I hadn't seen the (recently logged) bugs about this yet.

THis would really be great.

> I'd certainly like
> to see it, partly because the current GTK+ system has some major 
> design flaws in it -- replacing it would be a good thing
> regardless of integration issues. (But integration issues also
> are important)
> 
> Regards,
>                                         Owen
-- 
Bill Haneman <bill haneman sun com>