From: Emmanuele Bassi <eba...@gmail.com> > On Thu, 2011-02-17 at 09:43 -0500, Matthias Clasen wrote: > >> The current state of affairs cannot be useful for anybody. > > let's also look at the state of Atk's API, and what's required to do to > create an ATK implementation. when I looked at the accessible > implementations in GtkSpinner and GtkSwitch I was shocked at the > verbosity and roundabout way you have to go to implement an AtkObject.
Well, ATK has been really useful during a lot of years. But the fact is that is has been mostly the same API with minor aditions during 10 years. ATK is still on 1.X, while gtk has evolved to GTK 2.0 and now to GTK 3.0 There are several things to improve, and also AT developers found several things that should improve. This is the reason we are organizing a ATK hackfest this year (well, in fact ATK/AT-SPI2) hackfest. The page here [1]. I have pending an official announce, but as I'm a horrible blogger and I wanted to also create a blog post about it ... > plus, it's *really* hard to implement an an accessible widget with > anything else but C - and even there the type definition macros are just > papering over the byzantine incantations to register factories and such. I already discussed that with Owen Taylor while solving some bugs related to St [2]. The factories are not required in this new world where a11y is fully integrated with the app/toolkit. It was a lesser evil when gail or other ATK implementation (hail) was an isolated module. As cally was integrated on clutter, we could remove the factory-related code from cally. But as this "just works", I prefered to work on other thinks (priorities). Anyway, I include this on the a11y roadmap item related to ATK [3], as it requires to be discussed. About this "hard to implement with anything else but C" ... well, yes it is true, but for example, in the case of Javascript, right now is also hard to implement a GtkWidget subclass without workarounds like the ShellGenericContainer. > finally, Atk is strictly dependent on how GDK works - especially with > regards to events; I'm using Atk in Clutter, but there's a whole layer > devoted to translating Clutter code into what Atk expects from GDK. for > an abstract toolkit, that's a nice piece of fail right there. Yes this GDK reference here [4] is not a good idea IMHO. Anyway, as a abstract layer, that translation code would be required. From the specific toolkit event structure (GTK, Clutter, WhateverTK) to the abstract toolkit ATK event structure. The fail here is include a GDK reference on the definition of this structure at the ATK level. In fact when I was working on that I detected this, but I forgot to include that here [3]. Anyway, please take into account that ATK was being used on several toolkits (not only Gtk+ and Clutter), so although there are some areas that solve be improved, he worked fine as a abstract intermediate API. > chucking away Atk is not the way, but fixing its glaring issues would > make implementing a11y directly inside gtk+, and other toolkits, a lot > easier. Just for your information, in relation with the ATK hackfest we created this [5] metabug. As a summary, the ATK hackfest would be "solve or propose a solution for as much of this bugs as possible". Feel free to create more bugs there. BR [1] http://live.gnome.org/Hackfests/ATK2011 [2] https://bugzilla.gnome.org/show_bug.cgi?id=626658#c9 [3] http://live.gnome.org/Accessibility/Roadmap#Augmented_and_Consistently-Implemented_Atk [4] http://library.gnome.org/devel/atk/stable/AtkUtil.html#AtkKeyEventStruct [5] https://bugzilla.gnome.org/show_bug.cgi?id=638537 === API (apinhe...@igalia.com) _______________________________________________ gnome-accessibility-devel mailing list gnome-accessibility-devel@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-accessibility-devel
