[Kde-accessibility] understanding the whole picture

[Bill Haneman]

On Wed, 2002-11-27 at 02:09, Pupeno wrote:

> This mails goes mainly to Bill.

Hi Pupeno:

Sorry I was off the air due to technical difficulties yesterday  (power
outage).

> We're here trying to understand the whole picture of ATK and at-spi and be 
> aware that we're not really familiar with the GTK and GNOME 
> api/classes/objects.
> I have a couple of questions:
> Are the gnome/gtk objects a group of structs and plain functions named like 
> the structs ? for example:
> struct      GtkObject;
> void        gtk_object_unref                (GtkObject *object);
> void        gtk_object_weakref              (GtkObject *object, 
> GtkDestroyNotify notify, gpointer data);

Well, no (and yes); they are GObjects, and to understand how they work
you need to understand the GObject model in glib.  But they are
implemented internally, in C, as structs - just as all objects in C++
are actually structs "under the covers".  So it's best not to think of
them as plain structs of plain functions, they are not "plain", though
they are of course "functions".

Every type of GObject has two kinds of associated structures, a Class
struct and an Instance struct.  There is one Class struct per object
type, containing a set of virtual function pointers, private data, and
(always, as the first part of the Class struct definition) an instance
of its parent Class struct.  Then each instance of an object has one
Instance struct associated with it.  The GObject functions always take a
pointer to the appropriate GObject instance as the first argument, and
use the virtual function pointers in the Class struct to find an
implementation of the method.  This is how an Object/Type system needs
to work in C, it's really the same thing C++ does after the compiler's
"mangling" phase, only a little prettier.
 
> Then, according to 
> http://developer.gnome.org/projects/gap/guide/gad/index.html when I have a 
> widget, a gtk widget that doesn't have any accessibility features I have to 
> do something like this:
> AtkObject *obj;
> obj = gtk_widget_get_accessible (button);
> atk_object_set_name(obj, _("Close"));
> atk_object_set_description (obj, _("Closes the window"));

This is not what the Guide says; you only have to do this if the
existing name or description are not suitable for your needs.  GTK+
provides built-in accessibility information for all its widgets via
gail, and widgets that derive from any existing GTK+ widget (which all
GTK+ widgets must do) inherit accessibility implementations from their
parent class.  So your application or toolkit don't need to call these
methods though it would be good to provide some way for application
writers to set appropriate accessibility properties if you don't already
have a suitable mechanism.

> so I imagine that what gail does it do that for all the widget that exists, 
> for example, do that for a button, so, people doesn't have to do it by 
> themselves.
> As it is said, it is load when is required and if not (no atk calls are 
> made|empty atk calls are made).

Right, GAIL is loaded only on-demand for performance reasons.  If it's
not loaded, you get mostly "empty" accessibility implementations.
 
> So, we should put that code somewhere (still don't know where) but my main 
> question is that we'll need a AtkObject *QWidget::getAccessible() function 
> (or AtkObject *QObject::getAccessible() function), right ?

If you look closely at the AtkImplementor interface you will see that
any GObject type/instance can implement accessibility; in such cases you
will need to create appropriate AtkObjectFactories for the type.

> That stats that QWidget or QObject should understand about AtkObject (as 
> GtkWidget does), right ? well, that's not going to happen :\

No, this is not a necessary conclusion.  What you need to do is subclass
AtkObject (create a KatObject or something that derives from AtkObject),
and then provide new implementations of all the virtual methods that
need to be changed for KDE, for instance those that assume that the
backing objects are GObjects).  Then you need to provide implementations
for some of the basic ATK utility methods (for instance as is done in
gailutil.c for GAIL-based accessibility) for getting the "root
accessible" of an application/process.  Your widgets don't need to know
anything about this, but they need to provide enough information for you
to implement all the appropriate Atk methods on their behalf.

Note that ATK has a number of queryable interfaces and UI
objects/instances should implement only those interfaces that make sense
for them; The ATK docs contain definitions of what the various
interfaces are intended to do.

> Should we then, get a QAccessibleObject object and make katk 'cast' it to an 
> AtkObject ?

No, that's not likely to work (at least not with anything like a true
'cast').  And it's not necessary for you to have a special
QAccessibleObject type at all.

best regards,


-Bill
 
> Thank you.
> - -- 
> Pupeno: pupeno@pupeno.com
> http://www.pupeno.com
> - ---
> Help the hungry children of Argentina, 
> please go to (and make it your homepage):
> http://www.porloschicos.com/servlet/PorLosChicos?comando=donar
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.0.7 (GNU/Linux)
> 
> iD8DBQE95ClYLr8z5XzmSDQRAoFcAJ9wOf7+kxgjnbgUPuz2o9vsS3RV5ACeMdsj
> t2Ku4MxcatyGatLjAIVYR1s=
> =qQth
> -----END PGP SIGNATURE-----
> 
> _______________________________________________
> kde-accessibility mailing list
> kde-accessibility@mail.kde.org
> http://mail.kde.org/mailman/listinfo/kde-accessibility