[Kde-accessibility] my crazy thoughts

Bill Haneman bill.haneman@sun.com
28 Nov 2002 12:21:13 +0000


> I'll do a diagram on fixted font, so, please, switch to fixed font to 
> understand it.
> [KDE App]--[QAccessible]--[QAPlugin]-----\
>                                          |
> [KDE App]--[QAccessible]--[QAPlugin]---[KATK]------\
>                                          |         |
> [KDE App]--[QAccessible]--[QAPlugin]-----/         |
>                                               [KATK-ATK-BRIDGE]
> [Gnome App]--[GAIL]--[ATK]------\                  |  
>                                 |                [ATK]
> [Gnome App]--[GAIL]--[ATK]-->[AT-SPI]--------------/
>                                 |
> [Gnome App]--[GAIL]--[ATK]------/
> 
> Explaining:
> KDE App are kde applications (simple KDE applications or screen 
> readers/on-screen keaboards/anything). Gnome App is the same as KDE App but 
> for Gnome.
> QAccessible is the api that will describe all the aplication structure, 
> automatically (without needing to do anything by the developer), same thing 
> GAIL does except that GAIL is only loaded if needed.
> QAPlugin would be the QAccessible plug in that makes sharing the QAccessible 
> object into dcop/mcop or something (In Windows/mac would be diferent).

I don't think KATK should be a singleton instance.  If the bridging code
to ATK is a shared library which is loaded on a per-application basis
(which is how this works in GTK+, GNOME, Mozilla, etc.), then QAPlugin
is not needed, and the KDE-to-ATK bridge can use private and internal
KDE/Qt API to get all the information it needs.  This reduces the burden
of extending Qt, reduces the requirements on DCOP/MCOP issues, and means
that information doesn't have to be 'remarshalled' through multiple
interprocess-communication channels.  Since the bridge code would
presumably be a shared library, it wouldn't take any more memory space
that a single KATK 'daemon' would and would probably give better
performance.

> KATK would be in charge of all the comunication, etc, etc.

As was already pointed out, this is a problem because it introduces
multiple accessibility IPC communications protocols.

> > BTW: Why exactly is the ATK-API based on GObject? Is it possible to modify
> I don't know, but you could see it here: 
> http://developer.gnome.org/doc/API/2.0/atk/atkobject.html

You wouldn't want to modify that. GObject is part of glib, and it
enables the complex type/interface/object capabilities of ATK.
 
> > ATK to be able to use some toolkit-independend classes (which then could be
> > instanciated through multiple inheritance from either GObject or QObject?)?
> No, that's not posible that would require a lot of work inside Gnome and I 
> don't think they will do it or let us do it, but more important thant that 
> remember that they're working on C. It is not really object oriented like 
> C++. 

This is inaccurate.  ATK is indeed toolkit-independent, it can use
toolkit-independent classes however you like.  AtkObjects are instances
of GObject but that's not a toolkit=dependency, it's simply a
characteristic of the ATK API.  AtkObjects can be associated internally
with any kinds of objects, the API is designed to work with any kind of
UI toolkit or even different languages like Python, etc.

GObject is a complete object-oriented system written in C (it has C++
bindngs, by the way).  That's why it's used.  It is part of glib; I
always said ATK depends on glib.

> I don't even understand how heritance works yet as clases seems a group 
> of global functions, structs and defines and I don't think it supports 
> multiple inheritance (I remember seeing a tree of inheritance and it was a 
> simple tree, always opening), and if it was posible, our classes are totally 
> diferent to them and if we make the class enough versatile for both it may 
> end up being bad for both, look at the diagram I made.
> A cross solution would be plain C with no object orientation (or not a real 
> one at least) and I think we can do better than that inside KDE.

I don't believe you can do a reasonable accessibility API without object
orientation and/or inheritance.

> > In that case we would only to do four things:
> > 1) Ask Trolltech to base their extended QAccessible objects on those
> > toolkit-independent classes

QAccessible was based on the Microsoft Active Accessibility API, which
unfortunately is not sufficient for accessibility support without
additional APIs such as the MFC APIs, etc.  Thus outside of a MS-win
environment it isn't broad enough. 

> If the toolkit-independt classes are cross-platform, Unix, Windows, MacOS, 
> then, Qt may consider it. As this doesn't seem the case, I bet the plug in 
> based aproach is better, we'll make the plug in. It will work similart to 
> styles, you use Keramik on KDE, Qt applications also use Keramik because the 
> plug in work for both and Qt configuration is overwritten by KDE if I'm not 
> wrong.

I believe you are still under some misunderstandings about how the
existing ATK and AT-SPI architecture works, and how it could be
implemented cleanly by KDE. 
 
> > 2) extend the KDE classes
> > 3) modify ATK to use the toolkit-independent classes in the API

This is totally unnecessary, ATK is toolkit-independent already.

> > 4) Start KDE-applications, load the ATK-library and feel happy.
> >
> > It would not matter if the ATK<->AT-SPI bridge would internally still use
> > Gnome libraries.
> Well I think this questions are answered by the previous questions :P
> Maybe we should held another meeting (absolutly informal) for the people 
> intrested specifically in this, anyway, the answer for Qt is a key part of 
> this development.
> - -- 
> 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
> 
> PS: to see what I think about the GObjects, take a look at my post: 
> "Understanding the whole picture". Yes, I've read what you Gunnar and Olaf 
> where talking on irc but I think it is not worth it save all of it.
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.0.7 (GNU/Linux)
> 
> iD8DBQE95NFWLr8z5XzmSDQRApdFAKCS3+G5gmvb5g/GkkuzBL9Eu9POmQCZAfJn
> jQnIFsPmkMuj9d6nEXzFMGw=
> =93PR
> -----END PGP SIGNATURE-----
> 
> _______________________________________________
> kde-accessibility mailing list
> kde-accessibility@mail.kde.org
> http://mail.kde.org/mailman/listinfo/kde-accessibility