Re: Bitmap, Pixmap, Image and Pixbuf madness

["Bill.Haneman" <Bill Haneman ireland sun com>]

> "Bill.Haneman" <Bill Haneman ireland sun com> writes: 
<snip>

> > So it would be really helpful if a "label" property (in addition
> > to the longer descriptive ToolTip which I think is already 
> > possible to attach to a GtkImage ?) were available in GtkImage.
> > Then a couple of instantiation macros to make it easy on the
> > developer would complete the picture (pardon the pun)
> > 
> 
> Is this GtkImage-specific, or would you maybe want labels on other
> widgets as well?
> 
> Havoc

Well, we don't want to impose undue burden on developers or
unnecessary redundancy.  We *do* need a means of obtaining labels 
for all widgets that have a "visible acive identity" (e.g. not 
GtkHBox but buttons, menuitems, labels, icons).  But in many cases
there is a property that maps nicely to that concept already.

Ideally an app should have the option of setting such
a property explicitly on *any* widget, in support of accessibility.
In that setting, one can set (and subsequently get) the
"accessible-label" property.

The idea is that the concept of an "accessible label" is a generic
one shared by most/all widgets.  However one wants to leverage the
existing information in the widget, in effect funnelling the
different widget properties and models into a common set of
abstractions.  You are right, since there will need to be 
a common set of abstracted "accessible" properties, these may
be explicitly set by the application directly rather than
by adding new widget properties which are then correlated with
the accessible properties.

However there is a case to be made that a text label would be
useful for images in many contexts anyway.  Deciding whether to
provide only an "accessibility API" for setting such a property,
or whether it is something that logically belongs as an explicit
property of the widget, which is leveraged in the "accessibility"
environment, is a judgement call.  I think that in the case of
GtkImage one could make a case for inclusion on the grounds that
it would be generally useful.  For other widgets it may be that
only in environments where "alternate access" is required does
a "label" property make sense.

For those readers who find this discussion totally opaque, 
I/we hope to post a proposal for an overall API enabling
GTK accessibility to this list in the next few days...
thanks for your patience.  

In the meantime if anyone is interested,
the Java Accessibility API, 

http://java.sun.com/j2se/1.3/docs/api/javax/accessibility/package-summary.html

though perhaps not a perfect model for
the GTK environment, should give a good overview of the
requirements and characteristics of an application/toolkit-level 
accessibility API.  We hope to field a proposal that both has
minimal direct impact on GTK+-2.0 and meets the requirements
for comprehensive access to GTK widgets by disabled people,
with the use of software and hardware "assistive technologies".

Best regards,

Bill