On Tue, May 10, 2011 at 10:46 PM, Brian Cameron <[email protected]> wrote: > > A main reason that there are multiple sets of interfaces is to make the > free desktop accessibility interfaces widget-set neutral. A huge > amount of effort has been invested over the years to make GNOME and KDE > accessibility interoperable. By making both GNOME and KDE talk to the > ATK interfaces, accessibility becomes desktop independent. > Yes, there is two ways to do things. A lot of projects try the idea of defining an abstraction layer and then working on getting that interface implemented on top of a different interface. wxWidgets or AWT try that for toolkits, Cairo tries it for rendering methods and Wine tries it for the Windows interface. KDE has a lot of abstraction layers too, like Phonon, Solid etc.
Now this approach has, as you pointed out, one big advantage. It allows writing code to the abstraction layer and the code will then run unmodified on all supported backends. It has big disadvantages though. First of all, unless the backends you target support your API directly, you have to write glue code that bridges their interface to your interface. And this code will likely try to fix a lot of subtle differences between those interfaces. And if a backend is sufficiently different from the interface that you want to provide, you end up with glue code that looks like a cesspool. The best example for that is probably Wine. Of course you also need to find someone to actively maintain that interface with enough knowledge on both interfaces or it will bitrot. (See my last mail for that topic.) Last but not least, you end up with some sort of lowest common denominator interface. You cannot support features that are only available to one backend, when all the other backends do not support it. Or you have to write your own implementation of it. So your interface will never look very appealing to the outside. And while GTK's ATK interface does provide the huge benefit of providing an easy abstraction layer, I can also clearly see all the bad things happening. And not just that, I can see all of these bad things actually getting worse. Our glue code is in gail. It tries to fix subtle differences in the interfaces. It does look like a cesspool of corner-cases. It's basically unmaintained, there certainly is no core GTK developer caring about it. And it does not gain new features and only supports a bunch of features of GTK in a very limited way. > Your suggestion for ATK programs to just use GTK+ directly seems to > suggest that each widget set should develop its own unique a11y > infrastructure and mechanisms. This would be a huge change in direction > and a huge loss, I think. > What concerns me a lot is that there is only very few applications that actually make use of this huge abstraction layer that is AT-SPI. I'm often thinking that we would have less code to maintain if we indeed wrote Orca code once for every toolkit we target Orca at instead of having to maintain a big ATK interface for every toolkit. (And the same for the other few applications that have accessibility requirements.) But of course I have no idea if that is actually true, I just wouldn't rule it out from the start like you seem to do. What remains is that we have a problem: The AT code in GTK is so bad that it is off by default and nobody is in sight that wants to fix it. And that is bad. Benjamin _______________________________________________ gnome-accessibility-devel mailing list [email protected] http://mail.gnome.org/mailman/listinfo/gnome-accessibility-devel
