Benjamin:
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. 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. Your analysis seems to not consider this at all, and instead seems to assume that all free software accessibility work is done in a GNOME or GTK+ vacuum. Brian On 05/10/11 09:28 AM, Benjamin Otte wrote:
Hey, So I've been thinking about accessibility in GTK for a whie (since it broke all the time during the unstable GTK 3 development to be exact). And I've been wondering how to fix the somewhat sad state of the code we do have. Unfortunately I have no idea how to solve it, but I have an opinion about what the problem is. The TL;DR version is this: I think the problem is the fact that we support a separate API for accessibility. Now for the long version: Currently there are two APIs that developers can use to interact with applications that run GTK: 1) The official GTK APIs - see http://developer.gnome.org/gtk3/stable/ 2) The official ATK APIs - see http://developer.gnome.org/atk/stable/ Both of these provide a very similar functionality. For example, to write a function like void toggle_switch (GtkSwitch *switch); you can use GTK like this: gtk_switch_set_active (switch, !gtk_switch_get_active (switch)); or you can use ATK like this: AtkObject *object = gtk_widget_get_accessible (GTK_WIDGET (switch)); atk_action_do_action (ATK_ACTION (object), 0); You can easily find more examples for this. Also, while both cover most of the other's functionality, both of them provide functionality that can not be achieved using the other's API. Now, why is this a bad thing? There are multiple reasons. Of course, the most obvious reason is that it is a duplication of work. If you add functionality to one of these APIs, people also want it in the other API. So you have to write and test code twice. Not only this, you also have to wrap your mind around two different philosophies on how to design an API - one of which you've probably never used yourself and don't ever intend to. And maybe you even have to argue with two maintainers about various details. Another problem is that there's a huge imbalance in the amount of users of the given APIs. While there are thousands of developers using the GTK APIs to write applications, there is very few developers using the ATK APIs to write applications for GTK. With way more eyes looking at the GTK side, they are more polished, better documented, less buggy and a lot more featureful. Also, the whole design of GTK internals focuses on these. Even worse, there is not a single GTK core developer that has a personal interest in the ATK interface to GTK. I would even go so far as to claim that developers do just the absolute minimum required to be able to tick the "[x] accessibility" checkbox in the feature list. Now this is especially bad because there is nobody available that can and does give feedback on design questions about internals when it comes to the ATK APIs. (examples: Is it a good idea to adapt the allocation automatically based on margins? Or will this conflict with what AtkComponent does? Does using Cairo to do drawing conflict with ATK in any way?) Due to the previous reasons, the ATK interface is bitrotting. The code is crashing more and generally behaving buggier with every release. This was not that much of a problem while the GTK API remained mostly stable during the GTK 2 cycle, but turned a lot worse when we did the API break leading to GTK3. And since we want to accelerate GTK development, I don't think it is getting better. But then, it certainly can't get a lot worse. Everybody not using programs that require the ATK interface just doesn't use it. And because ATK is pretty much only used by the accessibility interface, more than 90% of the people fall into that category. Which is a vicious cycle: People don't use the API because it is bad and because the API is bad, people make sure not to use it. So now after describing the problem, let me look at possible solutions. The easiest solution of course is to just drop one API. If we dropped ATK (which is the only option really, unless you want to rewrite all the thousands of applications like the Gimp and Inkscape to use ATK exclusively), you can only toggle a switch by using gtk_switch_set_active(). There is no accessible object for doing the same thing anymore. Of course, everybody that does now use ATK would need to completely redo their application to actually use the GTK APIs. It would also likely point out gaps in the GTK interfaces so large that some things that are easy with the ATK interfaces are impossible with the GTK interface. And it might end in a way that somebody writes an abstraction layer for common required functionality of apps that used to use ATK and ships it as a separate library. (And that library might be named gail...) We could merge the APIs so that in the end there is no duplication anymore and the design philosophies from GTK and ATK are preserved as well as possible. To stay with the switch example, it might turn out that it's actually important to provide a gtk_switch_toggle() function as opposed to just having gtk_switch_set_active(). This of course will mean that we need to reorganize code and probably will end up deprecating quite a bit of functions. And of course this is quite a bit of work. We could also try to auto-generate APIs. Especially now that we have introspection capabilities it might be tempting to have a postprocessing step that generates the ATK interface from the GTK interface or vice versa. Of course, this would still be a duplication, we'd just make it more bearable by automating it. And of course it requires somebody sitting down and actually writing this tool. And finally we could continue as-is and keep maintaining two interfaces. If we do this, we need to find people interested in and willing to actively maintain the ATK interface. First of all, that would require someone with intimate knowledge of GTK, as that developer would need to influence the direction of the project. Code-wise, it would first require bringing its quality up to par and after that it would require constantly keeping track of GTK development and adapt the interfaces to new features. (Fwiw, I would suspect that would involve roughly a full-time job for an experienced GTK developer.) And I don't think anybody is up for that task. And that would mean the ATK interface remains in the sorry state it is in. This is where I am at the moment. I'm looking for solutions to the problem, but none of them makes me very happy. So if anybody has an idea about how to fix this, please tell me. Benjamin _______________________________________________ gnome-accessibility-devel mailing list gnome-accessibility-de...@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-accessibility-devel
_______________________________________________ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list