From kde-accessibility Thu Nov 28 11:16:18 2002 From: Bill Haneman Date: Thu, 28 Nov 2002 11:16:18 +0000 To: kde-accessibility Subject: Re: [Kde-accessibility] understanding the whole picture X-MARC-Message: https://marc.info/?l=kde-accessibility&m=103848252615791 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 _______________________________________________ kde-accessibility mailing list kde-accessibility@mail.kde.org http://mail.kde.org/mailman/listinfo/kde-accessibility