Re: status icon API

[Owen Taylor <otaylor redhat com>]

 On Mon, 2003-04-14 at 10:49, Bill Haneman wrote:
> On Thu, 2003-04-10 at 15:38, Owen Taylor wrote:
>  
> > >From my perspective:
> >  
> >  * There must be a plain GdkPixbuf * based API, because if
> >    nothing else, people will want to be be able to draw
> >    icons on the fly. 
> >
> >  * I'm pretty positive named icon themes (What GnomeIconTheme wraps,
> >    not stock icons) will be in 2.4. Because I really need them
> >    for the file selector, and because we need a better way of 
> >    making GTK+ stock icons follow the icon theme.
> 
> OK.  In the meantime we have the gnome-2.4 headaches regarding
> applications and themes...

A GNOME app can use libgnomeui functions to look up themed
icons if it so desires, and stick them in EggTrayIcon. 
It's only a few lines of code.

> > While GTK+ is meant to be a accessiblity-friendly toolkit,
> > we won't remove useful API because it could possibly be used
> > in non-accessible ways.
> 
> Of course.  But I think 'new' API should always have slots for names,
> and be themeable, etc.  Even if an app draws icons on the fly, I think
> it's desirable to be able to add theme support without recoding.
> 
> And in cases where the existing api has only "foo_from_pixmap
> (filename), I'd like to see additional (preferred) API with
> "foo_named_from_pixmap (name, filename)"  or similar.

You can use themed icons now from GNOME apps. You'll be able
to use them next time we do a GTK+ with API additions. I don't
think transitional APIs are necessary.

> Using the old icon-on-the-fly API is inherently inaccessible as far as I
> can see (it results in nameless images), at least without adding lots of
> explicit ATK call goo.

Well, presumably we'll need to have the appropriate ATK glue to
set descriptions on the tray icons ... since the tray icons aren't
GtkWidget's (from the GTK+ application programmer's perspective)
it probably will take some extra handling.

Regards,
                                         Owen