Re: Bitmap, Pixmap, Image and Pixbuf madness

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

Hi lupus:

Thanks for your input; you make some excellent points.
I'm sure much of this has become apparent to you in your
gspeech work.  I hope you can help us identify the remaining
feature gaps in the "default" widget properties and behavior.

I hope you don't mind that I've snipped out a bit of your 
original message , and changed the order of a couple of paragraphs.

> My take is that cues for accessibility should be always "available"
> in the toolkit if possible: it's a lost battle requiring all the
> application programmers to understand the needs of disabled people.
> And they should be enabled to use the existing applications as much
> as possible for many reasons (I understand some people will need
> special applications, but blind people for example only need them for
> some special domain like web browsing).
> That said, there is the need for a standard _additional_ API to enable
> the advanced use of some applications. If that should look like the
> Java Accessibility API is up for debate and I'll wait for your
> proposal for more comments.

I agree entirely, that's part of the "make it painless" approach
we're trying to adopt.  But what's least painful/most effective
for promoting the use of accessibility properties may not be the
same as the simplest approach from the point of view of the 
widget implementation and code maintainers.  That's why we agree
with your next point, that there is a strong need for an additional
API exposed at the toolkit level, for applications.  Just
adding some GObject properties is probably too opaque - too easily
ignored.

Also, it implies a lot of redundant properties if we have both
"accessibilty" properties and correlated "ordinary" properties on
widgets.

In some cases an application writer will need to provide
explicit accessibility hints that override the normal
values of widget properties, so defining separate access properties
is still a good idea.  But relying on them as-is, via only
the standard g_object_get/set_property methods, is subject to
several problems:

   1. lack of a separate API means that application developer must
      make a special effort to be aware of accessibility properties;

   2. without lots of program branching, accessibility properties
      will not have useful values if not explicitly set

   3. even if you create a mechanism for computing defaults (#2)
      you have redundancy and/or updating issues. 


> 
> What we need here is a standardization of the names of the properties
> that are useful for accessibility. A basic set could be:
> 
> "object-label"          Short name
> "object-description"    Longer description (like in tooltips)
> 
> There is no real need for a different API for this, g_object_set_data()
> works fine. Once the names are standardized, a screen reader can
> easily make use of them in an automatic way. These properties
> are not needed for all the widgets, though it should be possible
> to set them on all of them. It's a must to have them in GtkImage, 
> for example.

The API we are drafting addresses the standardization issues by
creating a set of interfaces and standard property names,
and an externally-loadable implementation can compute the values and
handle property change notifications for the majority of
cases (see below).  But we think this will work much better
with a new API - we give some of the reasons below.

> The other important point is that the toolkit should automatically
> set these properties (they can be overridden later by the programmer, 
> anyway) for things like stock icons where the toolkit knows the
> meaning of the icons. This is very important, because programmers are 
> lazy and usually don't understand accessibility anyway, so the toolkit
> should help them getting things right without too much hassles.


Absolutely right, so it's important that reasonable values can be
extracted/converted from existing widget properties - so the application
maintainer will only have to explicitly use the "set" methods on the
accessibility properties, through a small and consistent accessibility API,
when  the defaults are unsatisfactory (such as unlabelled icon buttons).

Programmers are, well, if not really lazy, usually plenty busy :-)
so they don't need lots of new stuff to worry about.  So we want
to make sure the API is simple, highly visible, and requires
no special extra downloads or linking against special
libraries in order to be used.  Programmers also don't like
excess baggage, so for good acceptance the footprint should
be very small when the functionality is not needed.  Thus the
idea that headers are visible in GTK+, and the set methods are
always available, but the implementation is dynamically loaded
only when needed.  In this scenario, if an app is running in
an "ordinary" environment where special assistive technologies are 
not needed, the runtime library is not preloaded, and the
"set" method wrappers, though defined and present in GTK+, 
will do nothing.  When the runtime implementation library is loaded
(in other words, when it is needed) then the wrappers will
point into the runtime library implementations.

As you point out, not all properties are appropriate to all
widgets - we address this by defining various accessibility
subinterfaces (Gtype G_TYPE_INTERFACE) that are implemented
on the appropriate widgets' "accessible" interface instances.

> As an example, currently in gspeech there is a way to traverse
> the interface and describe it to the user. For each widget type
> there is something like this in a configuration file:
> 
> description "GtkWindow" {
>         "A window titled: "; arg "title";
> }
> 
> A GtkImage could easily be described with:
> 
> description "GtkImage" {
>         "A "; arg "object-label"; " icon";
> }
> 
> This way a "Cancel" icon in a button can provide the info to
> the blind user even if there isn't a "visible" label in it.
> This works very well, because it doesn't require custom code
> to access the widget internals: all the info is obtained with
> the standard GtkObject interface and is easily customizable without
> recompiling the module. Also, it doesn't require the module to "know"
> a widget type in advance. An application that uses a custom widget
> can install a special gspeechrc file that describes it and provides
> audible cues for it.

Right, you don't want to require recompilation.  That's why the
lightweight accessibility API should be built into GTK+ or 
an object file it depends on.  But the implementation can and
probably should live in an outside module that is linked at runtime
only when needed (perhaps via GTK_MODULES).  Likewise it needs
to work reasonably with custom widgets "as is", and provide
simple ways for custom widget writers to extend its cues.

OK, back to brushing up header files so we can discuss
something concrete rather than abstract ;-)

regards,

Bill

> lupus
> 
> -- 
> -----------------------------------------------------------------
> lupus debian org                                     debian/rules
> lupus ximian com                             Monkeys do it better
> 
> _______________________________________________
> gtk-devel-list mailing list
> gtk-devel-list gnome org
> http://mail.gnome.org/mailman/listinfo/gtk-devel-list