From kde-accessibility Thu Nov 28 13:10:10 2002 From: Bill Haneman Date: Thu, 28 Nov 2002 13:10:10 +0000 To: kde-accessibility Subject: RE: [Kde-accessibility] my crazy thoughts X-MARC-Message: https://marc.info/?l=kde-accessibility&m=103848940121971 Hi all: Thanks Phillippe for your thoughtful message. I think you have a good grasp of the issues we/KDE are facing (I suppose by "we" I mean Linux accessibility folks generally). > > The best corba implementation seems to depend on Gnome, so, using at-spi > corba > > direct won't save me from depending on Gnome. > > Is it Gnome, or just Orbit + GObject ? That's different. ORBit2, which uses glib (which includes gobject). You could use any CORBA ORB that works, but ORBit2 is probably the winner for free desktops. > > I've found that ATK uses GObjects which I am still trying to understand (I > > > asked for help in #gnome and #gtk+ on irc.gnome.org, but I didn't get any > help :| ) yes; could be a timezone thing too. > Read the developer.gnome.org tutorials. Helps a bit. > > > But what really surprised me is that AT-SPI is developed in Gnome by Gnome > > > developers too. It is not the generic way I thought it was. > > I would say that ATK was introduced in Gnome by Sun, which is very > different. Accessibility is supported by Sun. Yes; there was no standard (and virtually no prior work) for accessibility on Linux or Unix prior to ATK; there was Java Accessibility (which Peter Korn has been a major part of), but Java Accessibility didn't at that time export itself outside the Java VM except on Windows, so even Java was without a suitable *nix accessibility API. > > Then I thought why is everybody else using AT-SPI when it is a Gnome > thing. Well, it lives in GNOME CVS but from the outset it was designed to work with multiple toolkits and platforms. ... > I do not agree. Sun has interests in Java and in Gnome, true. It does not > make Java related to Gnome, though. OpenOffice is developed by Sun too. So > it seems that AT-SPI and ATK has indeed been brought not by Gnome but by Sun > to us. And that they have chosen Gtk and Orbit as their toolkit to bring > that. Well, ATK and CORBA, anyhow. We implemented the APIs for GTK+ and Java first, since that is Sun's target accessibility platform, along with Mozilla and OpenOffice.org. Also, note that one of the driving factors in the accessibility work Sun and other companies have been doing is the US "section 508" regulation, which is being adapted and adopted in ever-increasing areas, and which will serve as a major influence on expected regulations around the world. These requirements are specific, detailed, and rigorous, and are one reason why we sometimes speak of a particular accessibility API or capability as being "required" rather than just "helpful" or "useful". > I don't know about this one. Mozilla uses a generic toolkit portable to many > platforms (XUL engine). They are certainly not using Gtk in the way Gnome > does. In fact, there even was once a Qt port of Mozilla. > > If Mozilla has done things properly and I imagine they did, mozilla > interfaces with ATK not at the level of their Gtk widgets but at a higher > GUI level. Mozilla is supposed to have a very versatile GUI which you can > script in many ways. I hope they have put the ATK accessbility at the > generic GUI level. This is correct, they are only touching the GTK+ "ATK" code at a very trivial level. In this respect Mozilla is doing something very similar to what KDE would need to do in order to 'bridge' to ATK. ... > You are wrong. DCOP has been designed not to depend much on KDE. It depends > on Qt and X11 only. And some people thought about removing this dependancy > to make it more reusable. Bindings for C and python were developed, to > ensure that other projects could use it. Similarly we have Python bindings for ATK, thanks to James Henstridge. I believe Murray Cummings has done C++ bindings for ATK too, for those who prefer them ;-) . > There are things you need to take into account: > > - standard: > How standard is AT-SPI ? And ATK ? Two gnome programs use it already and > they will enable access to Mozilla, OpenOffice and every Gnome application. > Does this apply to any Gtk application ? Are there other accessibility > toolkit apart from ATK ? All GTK+ applications that use GTK+-2 work with ATK and AT-SPI "out of the box", that is, without any additional coding. As far as I know the only other accessibility toolkit or API-set available for Linux/Unix is the Java Accessibility API, whose implementation is not LGPL and which isn't available outside of a Java VM. We have written a "java bridge" which bridges/exports the Java interface to AT-SPI, and this is how ATK/AT-SPI/etc. works for Java applications. > > It seem to me that ATK/AT-SPI is an accepted standard, even if it is new. If > some application already use it, it would be a pity that they don't work > with KDE. Or are you going to develop similar applications in KDE ? And if > those helper applications are develop, they must be able to access Mozilla, > OpenOffice and Gnome. So whatever happens, an AT-SPI access is needed. Yes; and to meet 508 requirements, to actually make complex programs like web browsers, email clients, and GUI-based spreadsheets usable by blind and physically challenged people requires a lot of code. The existing GOK and Gnopernicus projects, nearing their first "complete" release, are quite complex pieces of code. I do not forsee independent KDE equivalents being feasible with the current level of resources, even if we put aside the question of whether that would be the most effective solution for end-users. > - relationship to Gnome: > How is accessibility development related to Gnome ? Moving it to a more > neutral place like freedesktop might help to loosen things a bit. I suppose > the license is the LGPL. License is LGPL on all of this code. Moving it doesn't make sense at this time, but as I have already discussed there was broad support for a rename. We just haven't done the formalities to change the name to "GNU Accessibility Project", though RMS has indicated interest in our work before. > - technical: > I suppose AT-SPI is very generic. Is it true for ATK too ? Qt has a > promising architecture, which might be easier to use than ATK. I think that ATK is relatively easy to use, and am not sure that any architecture that provides equivalent functionality could be made much simpler. Thus I question whether duplicating the code and effort makes sense. Also, if one uses something other than ATK, an entirely new bridge to AT-SPI would be needed, which would re-introduce the need to do difficult CORBA coding. > You are facing a decision that KDE has faced a few times: do we use existing > technologies or do we develop our own ? Many times, KDE has chosen its own > technology: dcop and KPart vs Corba and Bonobo, KOffice vs OpenOffice, khtml > vs Mozilla/Gecko. > > However, accessibility is not as simple as these other decisions. Whether > KDE uses dcop or Corba only concerns KDE because this is internal to KDE. > Accessibility is opening KDE to external applications. There seem to be > existing applications that use AT-SPI to provide accessibility and there are > projects that use AT-SPI to be accessible. Yes, absolutely. > We probably don't want the author of accessibility applications to write > their applications twice, once for AT-SPI, and once for a KDE or Qt > framework. It's unlikely that the authors would do so, even if it were practical. > From the information I have gathered so far, I would say that AT-SPI is > unavoidable. You need it. And you don't have many choice to access it. It is > either Corba or ATK, both having some drawbacks. > > Bill, could you clarify on the relationship between ATK and Gnome ? What are > the applications using ATK/AT-SPI today and were they already using Gnome ? ATK is now used by GNOME applications, GTK+ applications (including those that don't use any other parts of GNOME), and Mozilla; there may be others of which I am not aware. The Java accessibility API is used by OpenOffice.org, which is then bridged to AT-SPI; this was done to provide a cross-platform solution since OO.o runs on Windows as well as *nix, but Qt need not do this since it already has a Windows accessibility solution and I am sure you don't want to require a Java VM for each KDE application ;-) Mozilla used GTK+ already, but only in a trivial way (as you point out Phillippe, the Mozilla widgets use XUL, not GTK+). There is interest in eventually providing a direct-to-AT-SPI bridge for OO.o, bypassing the JA-API for efficiency reasons. There have been suggestions about using ATK in other toolkits as well but I am not at liberty to say much about them and in fact don't know the current status. I would say that the main reason that other non-GTK+ applications don't do this yet is lack of developer resource to do the work. ATK was designed from the outset to be non-GNOME-specific; we did accept a dependency on glib as an acceptable tradeoff since the alternative would have required ATK to invent its own object model, which would have been wasteful of resources and of course would have appeared silly to GNOME. Likewise, we designed AT-SPI to be CORBA based since CORBA is in our opinion the only truly platform/language/OS-independent IPC mechanism with sufficient richness to express the needed APIs. Thus AT-SPI works with Java, C, C++, and Python, potentially on non-Unix and non-Posix operating systems as well as on Linux and Solaris, and is potentially network-transparent as well. best regards, Bill > regards, > > Philippe _______________________________________________ kde-accessibility mailing list kde-accessibility@mail.kde.org http://mail.kde.org/mailman/listinfo/kde-accessibility