Re: status icon API

[Bill Haneman <bill haneman sun com>]

Hi Mark:
I will reply when I get back Monday.

But we can't wait until gnome-2.6 or 2.8 to get this right, in the sense
that we need to make sure icons in the meantime can be made to theme
properly *and* have names.  Just saying 'create an anonymous icon from
this pixmap file' is not a tractable API for accessibility, it requires
app developers to make additional and seemingly-unrelated API calls in
order to do what should really be automatic to icon creation.

and yes, themes should override pixmap contents, that's how it works
with the gtk+ builtin icons :-)

-Bill

On Fri, 2003-04-11 at 00:19, Mark McLoughlin wrote:
> Hi Bill,
> 
> On Thu, 2003-04-10 at 20:12, Bill Haneman wrote:
> > > I'd guess that the right API has:
> > > 
> > >  - A way of setting the icon from a pixbuf (and in the future,
> > >    once we have named themed icon support from an named
> > >    theme icon)
> > 
> > Yes, I was concerned about this.  In fact I would strongly prefer that
> > any 'icon' APIs that we use (certainly new ones!) be designed so that
> > icons have names (preferably unique) that a theming mechanism can hook
> > into after the fact, even if the original application or tool wasn't
> > thinking "themeable".  IOW there should always be a way to add new
> > themed icons to iconsets, even for application-specific icons, so that
> > the current set's icon is substituted for the "default" one provided.  A
> > foo_create_from_file (foo.png) API without associated naming or key
> > strings is bad for accessibility:
> > 
> > 1) it doesn't provide a hook for icon-sets to plug a replacement into;
> > 2) it doesn't provide a string for the icon that can be used as a 'name'
> >    for the icon, other than the filename.
> > 
> > If we build this stuff into the API then application writers won't have
> > to do 'extra' stuff or avoid the use of certain APIs in order to ensure
> > theme compliance; the business of providing themed icons in icon-sets
> > then becomes more like localization/translation, in that icon-set
> > maintainers can keep on the lookout for new named icons to 'theme'.
> 
> 	Hmm, I'm pretty confused as to what you are suggesting ... Are you
> suggesting:
> 
> 	* That we add a named icon[1] API that does nothing for now?
> 
> 	* With every new non-named API we allow a name to be passed in which
> will override the other icon data as soon as we have icon themeing? e.g.
> 
> void gtk_status_icon_set_from_pixbuf (GtkStatusIcon *status_icon,
>                                       const char    *icon_name,
>                                       GdkPixbuf     *pixbuf);
> 
> 	so that when icon themeing is added to gtk+ that the pixbuf arg would
> be ignored ?
> 
> 	Maybe you're suggesting something else, but I don't think either of
> these are preferable to just adding the named icon API once there is
> icon themeing in gtk+.
> 
> Good Luck,
> Mark.
> 
> [1] - btw, when we see "named icon" we mean an icon name that you would
> use to look up an icon according to the icon theme spec, right? Just to
> be clear ...
>