Re: [g-a-devel] Gail next steps (was Re: GTK and ATK)
On 06/27/2011 05:18 PM, Matthias Clasen wrote: Another week gone by, time for another status update on the a11y branch of GTK+. - We have more tests in tests/a11y: * a tree-performance test that compares populating a large treeview with / without accessibles * a text test that checks most of the AtkText interface for labels, entries and text views - The factories for creating accessibles are being removed. Instead we are associating the accessible type directly with the widget class, via gtk_widget_class_set_accessible_type. Currently, about a third of all accessible have been converted FWIW, on ST right now this is done by a class method called get_accessible_type. But probably it would be good to homogenize this stuff, including cally, and remove also the factories there. BR -- Alejandro Piñeiro Iglesias (API) (apinhe...@igalia.com) ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: [g-a-devel] Gail next steps (was Re: GTK and ATK)
Another week gone by, time for another status update on the a11y branch of GTK+. - We have more tests in tests/a11y: * a tree-performance test that compares populating a large treeview with / without accessibles * a text test that checks most of the AtkText interface for labels, entries and text views - The factories for creating accessibles are being removed. Instead we are associating the accessible type directly with the widget class, via gtk_widget_class_set_accessible_type. Currently, about a third of all accessible have been converted - AtkText implementations have been removed from most accessibles where the widget just has a simple string. Currently, there's still some extra AtkText implementations around; the end goal is to just keep the ones for labels, entries and text views - The AtkText implementations of labels, entries and text views have been ported from GailTextUtil to new text-related api in gtkpango.h / gtktextbuffer.h. - A number of trivial accessible implementations there were just setting roles have been dropped altogether. Next steps: - complete the factory removal - drop the init vs initialize distinction - get rid of all uses of idles - replace the notify_gtk mechanism by direct update calls from the widget side, where appropriate\ - always create accessibles in gtk_widget_init Longer-term: - rewrite the tree view accessible to store its cell-accessibles inside the rbtree, instead of separately - same for icon view I think once the factory removal is complete, we should think about merging the branch, and continue the work in master. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: [g-a-devel] Gail next steps (was Re: GTK and ATK)
On 06/20/2011 06:18 AM, Matthias Clasen wrote: I think we should probably give a quick status update. Thanks for the update. Just a question. In the last week, Benjamin and I have started to implement the outlined plan. Achievements so far: - Code has been moved from modules/other/gail to gtk/a11y - Gail is no longer a module, but gets compiled into GTK+ proper. You still need to load atk-bridge to make your application visible to ATs, but using accessible objects inside the process now just works; gtk_widget_get_accessible() always gives you a fully functional accessible. I don't understand this you still need to load atk-bridge ..., are there short-term plans to avoid the atk-bridge loading? BR -- Alejandro Piñeiro Iglesias (API) (apinhe...@igalia.com) ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: [g-a-devel] Gail next steps (was Re: GTK and ATK)
No, there is no such plan in the short term. I was just trying to clarify how things will fit together. On Jun 20, 2011 8:59 AM, Piñeiro apinhe...@igalia.com wrote: On 06/20/2011 06:18 AM, Matthias Clasen wrote: I think we should probably give a quick status update. Thanks for the update. Just a question. In the last week, Benjamin and I have started to implement the outlined plan. Achievements so far: - Code has been moved from modules/other/gail to gtk/a11y - Gail is no longer a module, but gets compiled into GTK+ proper. You still need to load atk-bridge to make your application visible to ATs, but using accessible objects inside the process now just works; gtk_widget_get_accessible() always gives you a fully functional accessible. I don't understand this you still need to load atk-bridge ..., are there short-term plans to avoid the atk-bridge loading? BR -- Alejandro Piñeiro Iglesias (API) (apinhe...@igalia.com) ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Gail next steps (was Re: GTK and ATK)
Piñeiro apinheiro at igalia.com writes: On 06/07/2011 05:06 PM, Emmanuele Bassi wrote: 5) figure out new interfaces for GTK to expose necessary features to a11y (and other consumers, such as IM and OSK) we should probably establish some common interfaces so that Clutter can expose the same functionality for its own items — and so that embedding a GtkWidget inside a Clutter scene graph doesn't break the AT tools. Well, I thought that this common interface was ATK ;) Just to make my point very clear about what I mean here: Nobody I know is using ATK to handle cursors and word detection inside a PangoLayout. Nor should they. In fact, nobody should use ATK for anything but implementing accessibility. Because, as it turns out, ATK does not do anything but define such an interface. Also, the point (5) you were looking here is about a fundamental problem with how application developers handle accessibility. Hrm, I guess I'll try to use ASCII art to explain it. So this is my view about how it should work in the future and how I think most developers see accessibility: glib ^ | gtk/clutter - atk/accessibility ^ | app And this is how it works today and how I think most accessibility developers think people develop applications: glib ^ | gtk/clutter - atk ^ ^ \ / app They expect application developers to interact with ATK directly and attach useful properties to the accessible objects of the widgets they are using. This is how ATK works today. Now, this is a fundamental difference. Because one approach assumes developers must be knowledgeable about accessibility and actively handle it and the other assumes they can usually be ignorant of it and pretend it will just work. It would of course be nice if we could have the second approach because it leads to a way higher code quality. But it's also way worse in a non-ideal world where developers only care very little, like the current world. Because in this world an automatic accessibility framework could at least present an ok view of the app. To give an example for what I mean: It might be useful to add a function like gtk_label_set_is_labelling (label, entry); might be useful. It would let people say this label is labelling this widget. And it would then proceed to do set the right relation automatically behind your back. Or we could have a gtk_widget_class_add_remote_action (switch_class, toggle, gtk_switch_toggle) which would allow this widget, similar to key bindings, to expose a toggle action to remote listeners. It would also do the right thing automatically using AtkAction. What this would do, is to let people continue to be ignorant of accessibility, but provide them with functionality inside GTK that they will probably find genuinely useful for various things. And instead of painting this stuff into an accessibility corner, it'd be in the GTK corner. And people would find out about it when reading GtkLabel/GtkWidget docs, which they are a lot more likely to do than reading ATK docs. Benjamin ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Gail next steps (was Re: GTK and ATK)
On Mon, Jun 6, 2011 at 11:17 AM, Piñeiro apinhe...@igalia.com wrote: I don't think we can treat that as a first step and hold off on doing any other fixes until that migration is done. The migration is a significant undertaking, and will not be finished for 3.2. Sorry, I didn't want to say that we should hold off any other fix and focus just on the migration. Just trying to focus on the current big task defined as much as possible. So, I've discussed the best way forward for this with Benjamin today. Here is a rough 6-step plan for dealing with the 'gail problem': 0) write tests for accessible implementations 1) move modules/other/gail nach gtk/a11y 2) add tons of private headers for private structs, to share things 3) remove now unnecessary code 4) add a11y features support to core libs (mainly pango) - word detection, cursor handling etc, share with clutter 5) figure out new interfaces for GTK to expose necessary features to a11y (and other consumers, such as IM and OSK) 6) get rid of gtk/a11y and atk-bridge and use a generic dbus marshaller using the new interface As I've said earlier, some of this is clearly long-term and not remotely doable for 3.2. But some of it is; at least steps 0-3. So, here is the rough roadmap for the near future: This week, Benjamin and Cosimo review and merge all the outstanding CSS feature branches for 3.2. Then I do a 3.1 release. After that, we (mainly Benjamin and me, I guess) work on moving the gail code to gtk/a11y and doing some initial cleanups in master. The goal is to have things back to a more or less working state (I would expect a11y to work about as well as it does now, no major improvements yet) by mid-July, so we can do another 3.1 release with this before Guadec. Further work on steps 4, 5 and 6 can happen later, and does not block 3.2. Comments ? ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Gail next steps (was Re: GTK and ATK)
On 2011-06-07 at 09:46, Matthias Clasen wrote: I don't think we can treat that as a first step and hold off on doing any other fixes until that migration is done. The migration is a significant undertaking, and will not be finished for 3.2. Sorry, I didn't want to say that we should hold off any other fix and focus just on the migration. Just trying to focus on the current big task defined as much as possible. So, I've discussed the best way forward for this with Benjamin today. Here is a rough 6-step plan for dealing with the 'gail problem': 0) write tests for accessible implementations 1) move modules/other/gail nach gtk/a11y 2) add tons of private headers for private structs, to share things 3) remove now unnecessary code 4) add a11y features support to core libs (mainly pango) - word detection, cursor handling etc, share with clutter 5) figure out new interfaces for GTK to expose necessary features to a11y (and other consumers, such as IM and OSK) we should probably establish some common interfaces so that Clutter can expose the same functionality for its own items — and so that embedding a GtkWidget inside a Clutter scene graph doesn't break the AT tools. at the same time of 0-3 in gtk I can work on the equivalent for the Clutter side as well. Comments ? I totally agree with this plan. ciao, Emmanuele. -- W: http://www.emmanuelebassi.name B: http://blogs.gnome.org/ebassi ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Gail next steps (was Re: GTK and ATK)
On 06/07/2011 03:46 PM, Matthias Clasen wrote: So, I've discussed the best way forward for this with Benjamin today. Here is a rough 6-step plan for dealing with the 'gail problem': 0) write tests for accessible implementations 1) move modules/other/gail nach gtk/a11y 2) add tons of private headers for private structs, to share things 3) remove now unnecessary code 4) add a11y features support to core libs (mainly pango) - word detection, cursor handling etc, share with clutter 5) figure out new interfaces for GTK to expose necessary features to a11y (and other consumers, such as IM and OSK) 6) get rid of gtk/a11y and atk-bridge and use a generic dbus marshaller using the new interface As I've said earlier, some of this is clearly long-term and not remotely doable for 3.2. But some of it is; at least steps 0-3. So, here is the rough roadmap for the near future: This week, Benjamin and Cosimo review and merge all the outstanding CSS feature branches for 3.2. Then I do a 3.1 release. After that, we (mainly Benjamin and me, I guess) work on moving the gail code to gtk/a11y and doing some initial cleanups in master. The goal is to have things back to a more or less working state (I would expect a11y to work about as well as it does now, no major improvements yet) by mid-July, so we can do another 3.1 release with this before Guadec. This seems an awesome plan, thanks. Further work on steps 4, 5 and 6 can happen later, and does not block 3.2. Comments ? 0) (in relation with being isolated) Don' hesitate to ask to the gnome-accessibility-devel list to try to clarify it, bugzilla, or propose any specific topic on the a11y weekly meeting [0] 3) I think that it is worth to mention this bug [5], as one of the current messiest code on gail is related with the focus. I will try to work on clutter about the same [7] (although in the case of clutter is no so messy, and it would be also required some change on at-spi2). 4) Is also an awesome plan (proper shared libgailutil replacement). About 5) and 6) and without the intention of being controversial again ... : 5) Li already mentioned here [1] that ATK is already an abstraction layer, so not sure why it is required a new one. 6) This is mostly the same original merge both interfaces proposal that Benjamin sent to the list. Proposal with some advantages but several disadvantages (IMHO). Most of the people involved on the discussion were against it, and several questions were not answered (like IPC abstraction [2], one-screen-reader per toolkit problem, multi-toolkit environment [3]), etc. Taking into account this point, it seems that this thread was started in order to communicate a final decision instead of creating a real debate. Anyway, as I said, this is a long term item, so probably it is still not written on stone, and we can debate it again (so you will have another chance to convince the others, and the others to convince you, and blabla). And after all, this is more or less what Qt is trying to do these days, and Frederik Gladhorn is still alive after being present on the *ATK*/AT-SPI2 hackfest. Again, thanks for your interest and effort. PS: is there the intention to have any some kind of GTK BoF/Workshop on the desktop summit [4]? It would be a good place to talk about this again, face-to-face. BR [0] http://live.gnome.org/Accessibility/Meetings [1] https://mail.gnome.org/archives/gtk-devel-list/2011-May/msg00057.html [2] https://mail.gnome.org/archives/gtk-devel-list/2011-May/msg00058.html [3] https://mail.gnome.org/archives/gtk-devel-list/2011-May/msg00059.html [4] https://www.desktopsummit.org/program [5] https://bugzilla.gnome.org/show_bug.cgi?id=649575 [7] https://bugzilla.gnome.org/show_bug.cgi?id=650669 -- Alejandro Piñeiro Iglesias (API) (apinhe...@igalia.com) ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Gail next steps (was Re: GTK and ATK)
On Tue, Jun 7, 2011 at 11:06 AM, Emmanuele Bassi eba...@gmail.com wrote: 0) write tests for accessible implementations 1) move modules/other/gail nach gtk/a11y 2) add tons of private headers for private structs, to share things 3) remove now unnecessary code 4) add a11y features support to core libs (mainly pango) - word detection, cursor handling etc, share with clutter 5) figure out new interfaces for GTK to expose necessary features to a11y (and other consumers, such as IM and OSK) we should probably establish some common interfaces so that Clutter can expose the same functionality for its own items — and so that embedding a GtkWidget inside a Clutter scene graph doesn't break the AT tools. yep. at the same time of 0-3 in gtk I can work on the equivalent for the Clutter side as well. Isn't clutter ahead of us here ? It thought cally was already inside clutter ? ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Gail next steps (was Re: GTK and ATK)
On 06/07/2011 05:06 PM, Emmanuele Bassi wrote: 5) figure out new interfaces for GTK to expose necessary features to a11y (and other consumers, such as IM and OSK) we should probably establish some common interfaces so that Clutter can expose the same functionality for its own items — and so that embedding a GtkWidget inside a Clutter scene graph doesn't break the AT tools. Well, I thought that this common interface was ATK ;) Saying so, it is true that we didn't have time to check clutter-gtk in that aspect. But we talked about it on the ATK hackfest, and we got some initial conclusions: https://bugzilla.gnome.org/show_bug.cgi?id=611507#c3 at the same time of 0-3 in gtk I can work on the equivalent for the Clutter side as well. Any schedule? If so, I could try to plan myself in order to try to work a little on this bug, to get some conclusions. BR -- Alejandro Piñeiro Iglesias (API) (apinhe...@igalia.com) ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Gail next steps (was Re: GTK and ATK)
On Tue, Jun 7, 2011 at 11:08 AM, Piñeiro apinhe...@igalia.com wrote: 4) Is also an awesome plan (proper shared libgailutil replacement). A very quick-and-dirty sketch of this can be found in the drop-gail branch: http://git.gnome.org/browse/gtk+/tree/gtk/gtkpango.h?h=drop-gailid=0e11f6eb18bf75a0b4420dc60e57ad1ec58404de ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Gail next steps (was Re: GTK and ATK)
On 06/07/2011 05:11 PM, Matthias Clasen wrote: On Tue, Jun 7, 2011 at 11:06 AM, Emmanuele Bassieba...@gmail.com wrote: 0) write tests for accessible implementations 1) move modules/other/gail nach gtk/a11y 2) add tons of private headers for private structs, to share things 3) remove now unnecessary code 4) add a11y features support to core libs (mainly pango) - word detection, cursor handling etc, share with clutter 5) figure out new interfaces for GTK to expose necessary features to a11y (and other consumers, such as IM and OSK) we should probably establish some common interfaces so that Clutter can expose the same functionality for its own items — and so that embedding a GtkWidget inside a Clutter scene graph doesn't break the AT tools. yep. at the same time of 0-3 in gtk I can work on the equivalent for the Clutter side as well. Isn't clutter ahead of us here ? It thought cally was already inside clutter ? Yes, cally is already part of clutter. So 1) doesn't apply to clutter. I guess that Emmanuele was talking about 5) (as cally is after all an ATK implementation) BR -- Alejandro Piñeiro Iglesias (API) (apinhe...@igalia.com) ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Gail next steps (was Re: GTK and ATK)
On 2011-06-07 at 17:16, Piñeiro wrote: On 06/07/2011 05:11 PM, Matthias Clasen wrote: On Tue, Jun 7, 2011 at 11:06 AM, Emmanuele Bassieba...@gmail.com wrote: 0) write tests for accessible implementations 1) move modules/other/gail nach gtk/a11y 2) add tons of private headers for private structs, to share things 3) remove now unnecessary code 4) add a11y features support to core libs (mainly pango) - word detection, cursor handling etc, share with clutter 5) figure out new interfaces for GTK to expose necessary features to a11y (and other consumers, such as IM and OSK) we should probably establish some common interfaces so that Clutter can expose the same functionality for its own items — and so that embedding a GtkWidget inside a Clutter scene graph doesn't break the AT tools. yep. at the same time of 0-3 in gtk I can work on the equivalent for the Clutter side as well. Isn't clutter ahead of us here ? It thought cally was already inside clutter ? Yes, cally is already part of clutter. So 1) doesn't apply to clutter. I guess that Emmanuele was talking about 5) (as cally is after all an ATK implementation) yes, but Cally is also not using internal API even though it could — and ClutterActors are generally unaware of Cally's implementation; for instance, CallyActor installs a bunch of signal handlers where it would be perfectly possible to have internal functions, or even call ATK/Cally methods directly from ClutterActor. ciao, Emmanuele. -- W: http://www.emmanuelebassi.name B: http://blogs.gnome.org/ebassi ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Gail next steps (was Re: GTK and ATK)
On 2011-06-07 at 17:13, Piñeiro wrote: On 06/07/2011 05:06 PM, Emmanuele Bassi wrote: 5) figure out new interfaces for GTK to expose necessary features to a11y (and other consumers, such as IM and OSK) we should probably establish some common interfaces so that Clutter can expose the same functionality for its own items — and so that embedding a GtkWidget inside a Clutter scene graph doesn't break the AT tools. Well, I thought that this common interface was ATK ;) Saying so, it is true that we didn't have time to check clutter-gtk in that aspect. But we talked about it on the ATK hackfest, and we got some initial conclusions: https://bugzilla.gnome.org/show_bug.cgi?id=611507#c3 cool; I'll cc myself to the bug. at the same time of 0-3 in gtk I can work on the equivalent for the Clutter side as well. Any schedule? If so, I could try to plan myself in order to try to work a little on this bug, to get some conclusions. I can definitely help out to get this done in the 1.7 cycle, given that the scope is way smaller for changes in Clutter. ciao, Emmanuele. -- W: http://www.emmanuelebassi.name B: http://blogs.gnome.org/ebassi ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Gail next steps (was Re: GTK and ATK)
On Sat, Jun 4, 2011 at 8:44 PM, Piñeiro apinhe...@igalia.com wrote: About this specific case it is about improve the documention: http://developer.gnome.org/atk/stable/AtkObject.html#AtkObject--accessible-name Or something else? Well, more than that, really. We need to know for each widget what the property is supposed to contain. I guess this also requires coming to grips with the somewhat haphazard way in which the acessible tree is different from the widget tree: sometimes there is a single accessible that 'wraps up' a whole widget subtree, e.g a button accessible 'hides' the image and label children of the widget, and instead implements corresponding interfaces itself. And the same is very much true for the ::accessible-name, which is often taken from 'somewhere below'. Anyway, I thought that the first step here was to migrate the current gail (with their virtues and drawbacks) to gtk. And although things would be easier with a good atk documentation, Im not sure if this is a blocking here. I don't think we can treat that as a first step and hold off on doing any other fixes until that migration is done. The migration is a significant undertaking, and will not be finished for 3.2. 2. Test that the accessible implementations actually follow that spec. I want to be able to have a unit test in the GTK+ repository that instantiates a widget, gets the corresponding accessible, and then verifies that it has the expected properties. If we had such testcases, it would not have taken 9 months from me committing the breaking change to me committing the fix. On the other hand, the fact that nobody filed a bug maybe tells us something about the amount of real-life usage that the gnome3 accessibility stack currently gets... Real-life usage is mostly done by users. GNOME 3 is not accessible, or at least was announced as not accessible. In general most of the tests done by the users were mostly a disappointment (ie: [1][2][3][4]). In summary: there is no real-life usage of the gnome3 accessibility stack. For the moment GNOME 3 accessibility stack is mostly developers tested. I would say not even that, unless you mean just the handful of a11y developers. I can't even turn on toolkit-accessiblity on my system; evolution crashes as soon as I switch to the calendar... ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Gail next steps (was Re: GTK and ATK)
On 06/06/2011 04:33 PM, Matthias Clasen wrote: On Sat, Jun 4, 2011 at 8:44 PM, Piñeiroapinhe...@igalia.com wrote: About this specific case it is about improve the documention: http://developer.gnome.org/atk/stable/AtkObject.html#AtkObject--accessible-name Or something else? Well, more than that, really. We need to know for each widget what the property is supposed to contain. I guess this also requires coming to grips with the somewhat haphazard way in which the acessible tree is different from the widget tree: sometimes there is a single accessible that 'wraps up' a whole widget subtree, e.g a button accessible 'hides' the image and label children of the widget, and instead implements corresponding interfaces itself. And the same is very much true for the ::accessible-name, which is often taken from 'somewhere below'. Ok, thanks for the explanation. In summary you are proposing to somehow make current heuristic practices more homegeneous. Well, in the end this is also documentation, and providing a proper good practices document. Because in the end, as an abstracted interface, what ATK needs to expose is a coherent model of the original hierarchy. Although I would need to see it in further detail, I guess that exposing the full subtree would be also OK, and that in this case, original developer concluded that was more clear in this way. But as you say, it would be good to having a document explaining good practices, instead of trying to reinvent the wheel over and over. We always said that current accessibility documentation is just bad. And this is a bigger problem taking into account that original ATK developers seems to be out of this planet. This was also a problem on the ATK hackfest, as some of the things that we discussed started with I don't understand why they did this in that way, but it would be odd if they didn't have a reason to do that ... Anyway, I thought that the first step here was to migrate the current gail (with their virtues and drawbacks) to gtk. And although things would be easier with a good atk documentation, Im not sure if this is a blocking here. I don't think we can treat that as a first step and hold off on doing any other fixes until that migration is done. The migration is a significant undertaking, and will not be finished for 3.2. Sorry, I didn't want to say that we should hold off any other fix and focus just on the migration. Just trying to focus on the current big task defined as much as possible. 2. Test that the accessible implementations actually follow that spec. I want to be able to have a unit test in the GTK+ repository that instantiates a widget, gets the corresponding accessible, and then verifies that it has the expected properties. If we had such testcases, it would not have taken 9 months from me committing the breaking change to me committing the fix. On the other hand, the fact that nobody filed a bug maybe tells us something about the amount of real-life usage that the gnome3 accessibility stack currently gets... Real-life usage is mostly done by users. GNOME 3 is not accessible, or at least was announced as not accessible. In general most of the tests done by the users were mostly a disappointment (ie: [1][2][3][4]). In summary: there is no real-life usage of the gnome3 accessibility stack. For the moment GNOME 3 accessibility stack is mostly developers tested. I would say not even that, unless you mean just the handful of a11y developers. I can't even turn on toolkit-accessiblity on my system; evolution crashes as soon as I switch to the calendar.. Yes, specifically a11y developers. You already mentioned that it is a problem that a11y developers are perceived as a different group than developers in general, right? About the evolution thing, in this case there is a real-life usage, as probably is this bug: https://bugzilla.gnome.org/show_bug.cgi?id=330728 Fixed recenly, although AFAIU comment 154, it is just a workaround (If ever we get someone to update our accessibility code then we can bring this back and let him/her try and debug the crash). Which is valid right now. AFAIK evolution right now is not really accessible friendly, in general, gtkhtml is not really accessible friendly. Lets hope the situation improves with the WekkitGTK move: https://live.gnome.org/Evolution/Planning32 BR -- Alejandro Piñeiro Iglesias (API) (apinhe...@igalia.com) ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Gail next steps (was Re: GTK and ATK)
On 06/03/2011 06:01 PM, Matthias Clasen wrote: On Wed, Jun 1, 2011 at 7:48 PM, Piñeiroapinhe...@igalia.com wrote: On 05/10/2011 04:28 PM, Benjamin Otte wrote: In fact, IMHO, some of the issues pointed by Benjamin would be solved by this [2] and the gail migration, but lets not talk about it. As I said, those are long term tasks, and the fact is that the current accessibility status needs to be improved also in the short and medium term. I also planned to define those short-medium tasks, but after reading again some mails, Matthias already did it in this mail [3], so I will not repeat that. I will just include that as task 1.5 I would include refactoring gailtreeview, one of the big problems related to performance that prevents having a11y enabled as default [5] For making things work better in the short/medium term (ie before we land a complete refactoring/rewrite of gail), I think two things are essential: 1. Define the atk interfaces to a testable level. One example that I have run in recently is the 'name' property of AtkObject - it is not really defined at all what this is supposed to contain, and how it is supposed to be used. It turns out a change that I committed last September made menu accessibles not have names - it turns out that that breaks ATs which expected those names to be taken out of the labels contained in the menuitems. This needs to be specified somewhere, so that we can then About this specific case it is about improve the documention: http://developer.gnome.org/atk/stable/AtkObject.html#AtkObject--accessible-name Or something else? You could also try to create a bug to debate it, or include it as a item on the a11y weekly. Anyway, I thought that the first step here was to migrate the current gail (with their virtues and drawbacks) to gtk. And although things would be easier with a good atk documentation, Im not sure if this is a blocking here. 2. Test that the accessible implementations actually follow that spec. I want to be able to have a unit test in the GTK+ repository that instantiates a widget, gets the corresponding accessible, and then verifies that it has the expected properties. If we had such testcases, it would not have taken 9 months from me committing the breaking change to me committing the fix. On the other hand, the fact that nobody filed a bug maybe tells us something about the amount of real-life usage that the gnome3 accessibility stack currently gets... Real-life usage is mostly done by users. GNOME 3 is not accessible, or at least was announced as not accessible. In general most of the tests done by the users were mostly a disappointment (ie: [1][2][3][4]). In summary: there is no real-life usage of the gnome3 accessibility stack. For the moment GNOME 3 accessibility stack is mostly developers tested. BR [1] https://mail.gnome.org/archives/orca-list/2011-May/msg00307.html [2] https://mail.gnome.org/archives/orca-list/2011-May/msg00165.html [3] https://mail.gnome.org/archives/orca-list/2011-May/msg00048.html [4] https://mail.gnome.org/archives/orca-list/2011-May/msg00143.html -- Alejandro Piñeiro Iglesias (API) (apinhe...@igalia.com) ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Gail next steps (was Re: GTK and ATK)
On Wed, Jun 1, 2011 at 7:48 PM, Piñeiro apinhe...@igalia.com wrote: On 05/10/2011 04:28 PM, Benjamin Otte wrote: In fact, IMHO, some of the issues pointed by Benjamin would be solved by this [2] and the gail migration, but lets not talk about it. As I said, those are long term tasks, and the fact is that the current accessibility status needs to be improved also in the short and medium term. I also planned to define those short-medium tasks, but after reading again some mails, Matthias already did it in this mail [3], so I will not repeat that. I will just include that as task 1.5 I would include refactoring gailtreeview, one of the big problems related to performance that prevents having a11y enabled as default [5] For making things work better in the short/medium term (ie before we land a complete refactoring/rewrite of gail), I think two things are essential: 1. Define the atk interfaces to a testable level. One example that I have run in recently is the 'name' property of AtkObject - it is not really defined at all what this is supposed to contain, and how it is supposed to be used. It turns out a change that I committed last September made menu accessibles not have names - it turns out that that breaks ATs which expected those names to be taken out of the labels contained in the menuitems. This needs to be specified somewhere, so that we can then 2. Test that the accessible implementations actually follow that spec. I want to be able to have a unit test in the GTK+ repository that instantiates a widget, gets the corresponding accessible, and then verifies that it has the expected properties. If we had such testcases, it would not have taken 9 months from me committing the breaking change to me committing the fix. On the other hand, the fact that nobody filed a bug maybe tells us something about the amount of real-life usage that the gnome3 accessibility stack currently gets... ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Gail next steps (was Re: GTK and ATK)
On 05/10/2011 04:28 PM, Benjamin Otte wrote: So I've been thinking about accessibility in GTK for a while (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: Well, some weeks have passed and seems that nobody wants to add anything new to this thread, so I will try to add some conclusions. First, thanks for this review and proposal. But it is a long term solution, and means so many changes on a lot of different modules, so if it finally implemented, this is a task to be planned for GTK4/glib3. Although this also applies to ATK2. Summarizing we have on the table two long term proposals: * Benjamin one about merging ATK and GTK, so the accessibility support towards AT-SPI2 would be more similar to current Qt one (WIP) (although he also implied that the interaction with AT-SPI2 could change) * A new ATK2 (some of the tasks related to ATK2 here [1]) In fact, IMHO, some of the issues pointed by Benjamin would be solved by this [2] and the gail migration, but lets not talk about it. As I said, those are long term tasks, and the fact is that the current accessibility status needs to be improved also in the short and medium term. I also planned to define those short-medium tasks, but after reading again some mails, Matthias already did it in this mail [3], so I will not repeat that. I will just include that as task 1.5 I would include refactoring gailtreeview, one of the big problems related to performance that prevents having a11y enabled as default [5] Finally, some of us thought that Benjamin was already looking that, starting with the gail-to-gtk, and included that here [4]. It seems that we were wrong to that conclusion. So please, update that section accordingly. BR [1] https://live.gnome.org/Accessibility/ATK/Tasks [2] https://bugzilla.gnome.org/show_bug.cgi?id=642597 [3] https://mail.gnome.org/archives/gtk-devel-list/2011-February/msg00083.html [4] https://live.gnome.org/Accessibility/ThreePointTwo/NiceToHaves#Gtk.2BAC8-Gail [5] https://bugzilla.gnome.org/show_bug.cgi?id=651345 -- Alejandro Piñeiro Iglesias (API) (apinhe...@igalia.com) ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: [g-a-devel] GTK and ATK
On Wed, May 11, 2011 at 11:09 AM, Brian Cameron brian.came...@oracle.com wrote: Another example is that the ATK abstracts common characteristics of widgets in a way that is useful to AT programs. All widgets that deal with text (labels, entry fields, combo boxes, etc.) all implement the same AtkText interfaces, providing AT programs a common way to provide alternative UI's for the end user. While not trivial, adding ATK code for a custom widget is a more reasonable approach to making a custom widget accessible than having to update every AT program like orca to support it. If we did not have the ATK, the AT program suddenly needs to know how to interact with each stock and custom widgets directly and separately. This adds a lot of code to the AT program, you see. I would argue that if all the widgets dealing with text really have the same needs, they should really support the same interface in GTK+, and there should be no need to write n adaptors for widget-with-text to atktext, but instead just one for text-widget-interface to atktext. And ideally, text-widget-interface and atktext would be so close to each other that that would be trivial. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: [g-a-devel] GTK and ATK
On Thu, May 12, 2011 at 5:25 AM, Piñeiro apinhe...@igalia.com wrote: On 05/11/2011 02:57 PM, Benjamin Otte wrote: Well most of the paragraphs were already answered by Brian, but I would like to add a comment here.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, Well, there are some issues with this proposal: * It is true that right now the AT more mature and maintained is Orca, but we still have other AT tools, like Caribou, Dasher (if it migrates to libatspi), MouseTrap/OpenGazer, Gnome Shell magnifier (Joseph is planning to use some AT-SPI features). One thing that would be very instructive would be to make a little table to show which of these technologies use/need what parts of the atk interfaces. I don't think the magnifier needs any really, for example. And for the others, probably only orca needs text and navigation support. dasher and caribou are much closer to input methods and could probably get away with just using im interfaces. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: [g-a-devel] GTK and ATK
On 05/13/2011 04:48 PM, Matthias Clasen wrote: On Thu, May 12, 2011 at 5:25 AM, Piñeiroapinhe...@igalia.com wrote: On 05/11/2011 02:57 PM, Benjamin Otte wrote: Well most of the paragraphs were already answered by Brian, but I would like to add a comment here.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, Well, there are some issues with this proposal: * It is true that right now the AT more mature and maintained is Orca, but we still have other AT tools, like Caribou, Dasher (if it migrates to libatspi), MouseTrap/OpenGazer, Gnome Shell magnifier (Joseph is planning to use some AT-SPI features). One thing that would be very instructive would be to make a little table to show which of these technologies use/need what parts of the atk interfaces. I don't think the magnifier needs any really, for example. And for the others, probably only orca needs text and navigation support. dasher and caribou are much closer to input methods and could probably get away with just using im interfaces Yes, this kind of table would be instructive. Some quick comments (although a exhaustive investigation would found more requirements): The magnifier requires it for focus-tracking. As I said Joseph was planning to try to use some at-spi functionalities on the gs magnifier. As right now at-spi2 python bindings are created with gobject introspection, in theory it could be possible to have also javascript bindings, and call them from gs magnifier code. AFAIK, dasher and caribou although were using at-spi for focus-tracking, although in the case of Dasher this is an optional feature. BR -- API ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: [g-a-devel] GTK and ATK
On 05/13/2011 04:32 PM, Matthias Clasen wrote: On Wed, May 11, 2011 at 11:09 AM, Brian Cameron brian.came...@oracle.com wrote: Another example is that the ATK abstracts common characteristics of widgets in a way that is useful to AT programs. All widgets that deal with text (labels, entry fields, combo boxes, etc.) all implement the same AtkText interfaces, providing AT programs a common way to provide alternative UI's for the end user. While not trivial, adding ATK code for a custom widget is a more reasonable approach to making a custom widget accessible than having to update every AT program like orca to support it. If we did not have the ATK, the AT program suddenly needs to know how to interact with each stock and custom widgets directly and separately. This adds a lot of code to the AT program, you see. I would argue that if all the widgets dealing with text really have the same needs, they should really support the same interface in GTK+, and there should be no need to write n adaptors for widget-with-text to atktext, but instead just one for text-widget-interface to atktext. And ideally, text-widget-interface and atktext would be so close to each other that that would be trivial. In general the main difference of what an accessibility oriented text interface (AtkText and AtkEditableText) required and what and UI toolkit text interface provides are more accurate ways to get the text based on the current position, and general on a more high level point of view that just a text between some offsets, as usually you want full words. ie: AtkTextBoundary defines 7 different boundaries when you ask for the word. In fact, current gail-text-util is mostly an utility library to make a conversion between them. [1] http://developer.gnome.org/atk/stable/AtkText.html#AtkTextBoundary -- API ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: [g-a-devel] GTK and ATK
On 05/13/2011 04:47 PM, Benjamin Otte wrote: On Fri, May 13, 2011 at 4:32 PM, Matthias Clasen matthias.cla...@gmail.com wrote: I would argue that if all the widgets dealing with text really have the same needs, they should really support the same interface in GTK+, and there should be no need to write n adaptors for widget-with-text to atktext, but instead just one for text-widget-interface to atktext. And ideally, text-widget-interface and atktext would be so close to each other that that would be trivial. Interestingly, there is a lot of use cases where people want to do stuff with text and an interface supporting it would help them greatly. Besides AtkText, spell checking, IM contexts and maybe even searching come to mind. If we could come up with an interface for Gtk that could satisfy all these needs without getting overly complex, that would be great. And as I just added on my last mail, also a way to get the current word or full sentence around the current cursor. (Ideally, this interface would have a default implementation that just maps to a PangoLayout very well, because that is what all text-related widgets in GTK use.) And in clutter. One of the more important bugs right now on Cally is the lack of a equivalent functionality provided by gail-text-util, so AtkText implementation is missing. This was postponed as most of current text representation on gnome-shell doesn't require it, but it needs to be solved eventually. And sincerely, I would like to avoid to re-implement that on clutter. So it would be good to have something like a pangolayout based library providing this functionality, in order to be used on both gail and cally. BR -- API ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: [g-a-devel] GTK and ATK
On 05/13/2011 05:47 PM, Piñeiro wrote: The magnifier requires it for focus-tracking. As I said Joseph was planning to try to use some at-spi functionalities on the gs magnifier. As right now at-spi2 python bindings are created with gobject introspection, in theory it could be possible to have also javascript bindings, and call them from gs magnifier code. In fact this was already reported as a bug: https://bugzilla.gnome.org/show_bug.cgi?id=647074 BR -- API ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: [g-a-devel] GTK and ATK
On Fri, May 13, 2011 at 12:15 PM, Piñeiro apinhe...@igalia.com wrote: On 05/13/2011 05:47 PM, Piñeiro wrote: The magnifier requires it for focus-tracking. As I said Joseph was planning to try to use some at-spi functionalities on the gs magnifier. As right now at-spi2 python bindings are created with gobject introspection, in theory it could be possible to have also javascript bindings, and call them from gs magnifier code. In fact this was already reported as a bug: https://bugzilla.gnome.org/show_bug.cgi?id=647074 Depending on what the exact needs are, this might be something that can be provided independently from a11y interfaces. Input methods want to know, too... ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: [g-a-devel] GTK and ATK
On 05/11/2011 02:57 PM, Benjamin Otte wrote: Well most of the paragraphs were already answered by Brian, but I would like to add a comment here.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, Well, there are some issues with this proposal: * It is true that right now the AT more mature and maintained is Orca, but we still have other AT tools, like Caribou, Dasher (if it migrates to libatspi), MouseTrap/OpenGazer, Gnome Shell magnifier (Joseph is planning to use some AT-SPI features). * And although that would be true, I think that our target is GNOME being accessible, and provide a proper framework to do that. Just providing support to Screen Readers are limited. * In fact, improving the a11y general support would allow to create new ATs easily. * As you said, one of the current problems on the ATK-toolkit relation is that the implementor requires to know both in order to do a good work here. But with this proposal you are just moving from need to know about an abstract accessibility toolkit and an specific toolkit to need to know about screen readers and an specific toolkit. Screen readers can be tricky. * A lot of people working on those toolkits already know about abstract accessibility toolkits. IE: LibreOffice and Gecko has also support for IA2. Most of the people that are already implementing support for IA2 are also implementing ATK support. I just wouldn't rule it out from the start like you seem to do. Well, sorry if thats what you extracted from my comments. It is clear that current accessibility status is not good enough. Thats a fact. And we all are open to proposals to solve that. I was just trying to discuss your proposals in a constructive way. Sorry if I failed at that. 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. Well, just a comment here. As Brian said one of the reason is that a lot of effort these years were used on the at-spi IPC switch. During those years we were in a situation were nobody put a lot of effort on at-spi as it was using an deprecated technology, and at-spi2 was in a work in progress status. Mike Gorse was starting to try to solve the just on the last iterations. (And DBUS is still, in general, less performant that CORBA). Anyway, one of the big problems in performance preventing to having by default the a11y on is related to the treeview. Specifically the adding/removing a lot of rows on the model means a performance penalty [1]. As Li said a11y treeview implementation is really complex because the lacking way to expose the internal information of the treeview. I hope that this gail-to-gtk move could help to improve this, and mainly, simplify gailtreeview implementation. Right now it is mostly an gtktreeview replication. BR [1] https://bugzilla.gnome.org/show_bug.cgi?id=577098 -- API ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: [g-a-devel] GTK and ATK
On May 12, 2011, at 5:25 AM, Piñeiro wrote: On 05/11/2011 02:57 PM, Benjamin Otte wrote: Well most of the paragraphs were already answered by Brian, but I would like to add a comment here.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, Well, there are some issues with this proposal: * It is true that right now the AT more mature and maintained is Orca, but we still have other AT tools, like Caribou, Dasher (if it migrates to libatspi), MouseTrap/OpenGazer, Gnome Shell magnifier (Joseph is planning to use some AT-SPI features). * And although that would be true, I think that our target is GNOME being accessible, and provide a proper framework to do that. Just providing support to Screen Readers are limited. * In fact, improving the a11y general support would allow to create new ATs easily. * As you said, one of the current problems on the ATK-toolkit relation is that the implementor requires to know both in order to do a good work here. But with this proposal you are just moving from need to know about an abstract accessibility toolkit and an specific toolkit to need to know about screen readers and an specific toolkit. Screen readers can be tricky. * A lot of people working on those toolkits already know about abstract accessibility toolkits. IE: LibreOffice and Gecko has also support for IA2. Most of the people that are already implementing support for IA2 are also implementing ATK support. I just wouldn't rule it out from the start like you seem to do. Well, sorry if thats what you extracted from my comments. It is clear that current accessibility status is not good enough. Thats a fact. And we all are open to proposals to solve that. I was just trying to discuss your proposals in a constructive way. Sorry if I failed at that. 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. Well, just a comment here. As Brian said one of the reason is that a lot of effort these years were used on the at-spi IPC switch. During those years we were in a situation were nobody put a lot of effort on at-spi as it was using an deprecated technology, and at-spi2 was in a work in progress status. Mike Gorse was starting to try to solve the just on the last iterations. (And DBUS is still, in general, less performant that CORBA). Anyway, one of the big problems in performance preventing to having by default the a11y on is related to the treeview. Specifically the adding/removing a lot of rows on the model means a performance penalty [1]. As Li said a11y treeview implementation is really complex because the lacking way to expose the internal information of the treeview. I hope that this gail-to-gtk move could help to improve this, and mainly, simplify gailtreeview implementation. Right now it is mostly an gtktreeview replication. I would like to inject into this discussion the point that however a11y is implemented there need to be hooks to integrate it with the native a11y features of all platforms that Gtk supports, not just Linux. It rather misses the point of a11y to force users who depend upon it to use an a11y tool for the Gtk applications on their systems different from the one provided by the OS. Regards, John Ralls ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: [g-a-devel] GTK and ATK
Benjamin: Overall, I was just trying to suggest that I think we need more analysis before making a decision. You raise a number of important issues at the GTK+ layer, but there are many high-level issues that also need to be considered. Cross-free-desktop interoperability is just an example. Another example is that the ATK abstracts common characteristics of widgets in a way that is useful to AT programs. All widgets that deal with text (labels, entry fields, combo boxes, etc.) all implement the same AtkText interfaces, providing AT programs a common way to provide alternative UI's for the end user. While not trivial, adding ATK code for a custom widget is a more reasonable approach to making a custom widget accessible than having to update every AT program like orca to support it. If we did not have the ATK, the AT program suddenly needs to know how to interact with each stock and custom widgets directly and separately. This adds a lot of code to the AT program, you see. On 05/11/11 07:57 AM, Benjamin Otte wrote: On Tue, May 10, 2011 at 10:46 PM, Brian Cameron brian.came...@oracle.com 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. Agreed. 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. Typically the problems and issues we find with GAIL are not situations where subtle differences are being managed. Instead, the worst problems tend to arise when the widget does not directly provide information or functionality that the ATK interfaces require, and hacks are used. 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. I am sure there are issues, but the ATK was implemented with the GTK+ first in mind. It was the first widget set that supported ATK. So, this was not really the situation in this case. Obviously, there are issues. For example, I know there are hacks in the GAIL Treeview/TextView widgets since they were never designed well to expose internal data. Issues like this tend to make the glue code messy. But, if we agree that widgets should provide the information that the ATK wants, then it seems it would be better to just fix the GTK+ widgets to avoid needing such mess. 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. I do not think your analogy works well here. The point of the ATK interface is not to provide a lowest-common-denominator interface. Its point is to abstract things so that AT programs can access all widgets that contain text in a common way. 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. We agree there is a problem here. I would like to better understand the situation, though. For the past couple of years, the GNOME a11y team has been focused on making accessibility work with D-Bus instead of CORBA and trying to provide some reasonable accessibility for GNOME Shell. These tasks seem to be well underway or starting to ramp down. So,
Re: [g-a-devel] GTK and ATK
于 2011/5/10 22:28, Benjamin Otte 写道: 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. I don't see ATK interfaces has anything to do with the bugs you said. It is an abstract layer. If you are suggesting that GTK+ implements ATK interface directly then I am totally agree with that. Matthias has point this out : http://mail.gnome.org/archives/gnome-accessibility-devel/2011-February/msg3.html 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...) ATK is that abstraction layer, why do we want another? 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. As people pointed out, ATK is an abstract layer which is supposed to work not only for GTK+, but many other toolkits. 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. Actually we have. And many people cares about ATK are getting together for ATK hackfest 2011 for the next version of ATK. And again, I don't think ATK has anything to do with the problem you said. 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.) If you are talking about the GTK+ accessibility implementation (currently GAIL), then I agree with you. ATK is an abstract layer, but GAIL is the implementation for GTK+. 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. Talking about GAIL, I agree that we don't have enough resource to work on that when GTK+ are changing its API. This may need efforts from both GTK+ people and accessibility people. Li ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: [g-a-devel] GTK and ATK
On 05/11/2011 02:10 PM, Li Yuan wrote: 于 2011/5/11 2:38, Federico Mena Quintero 写道: ATK is duplicated interfaces. It needs to be kept in sync with the rather axiomatic interfaces provided by at-spi. It has to deal with messy details like GTK+'s reference counting (and who knows if at-spi is amenable to that kind of detail). By implementing ATK interfaces, applications don't need to care about the IPC stuff. Or every toolkit will need to do a lot work when we transfer from CORBA to D-Bus, and to another IPC in the future. One problem may be that at-spi sometimes wants to be tightly-bound to things that are far away from it, and that's bad design. Maybe at-spi needs to be more stateless. I don't know exactly how that would work, but maybe it's about letting you reconstruct your view of an accessible application easily, in a couple of D-Bus calls, instead of doing a million calls just to re-sync everything. Take a widget hierarchy and its available accessible interfaces, and push the entire thing as a JSON blob? Use paths to refer to widgets (or accessible objects), like SomeApp/MainToolbar/SaveButton instead of querying each sub-hierarchy by hand just to get a volatile object reference? I don't know. I don't know how accessibility is going to work in the way you suggest too. Maybe the D-Bus stuff on the client side should be maintained directly inside GTK+? (Does anyone *call* ATK directly to implement an accessibility dongle, or do they always go through D-Bus? Why does ATK need a public API - can't it just be basically the structs for the GTypeInterfaces and as little boilerplate as needed to make those interfaces implementable?) You don't want to modify all toolkits' accessibility implementation when we switch to another IPC. This is what ATK doing - letting toolkit's accessibility implementation separate from IPC. Li ___ 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
Re: [g-a-devel] GTK and ATK
On 05/11/2011 08:57 PM, Benjamin Otte wrote: On Tue, May 10, 2011 at 10:46 PM, Brian Cameron brian.came...@oracle.com 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.) Yes, of course there are pros and cons. An abstract layer cost every toolkit to implement it. And this is why GAIL needs to be implemented in GTK+ directly to gather more information. 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. ATK has a lot of interfaces, roles and so on which a toolkit does not necessarily implement or use all of them. 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. Then GTK+ is changing its API, it cost a lot of resource to make GAIL catch up with it, which I think we don't have. So this require both GTK+ people and accessibility people work on it. And again, implement GAIL directly in GTK+ will help. 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.) That would mean we need to have one screen reader for each toolkit, and one on-screen keyboard for each toolkit and ... Even worse, I can't image what happen for applications that use two or more toolkits at the same time. Li ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GTK and ATK
On Tue, 2011-05-10 at 16:28 +0200, Benjamin Otte wrote: The TL;DR version is this: I think the problem is the fact that we support a separate API for accessibility. Let me present my (very limited) understanding of how a11y works right now. This is for the benefit of gtk-devel-list; people on gnome-accessibility-devel are obviously already well-informed of all of this. All the a11y code we have is essentially a solution to the problem of mapping an unknown number of accessibility-specific dongles (screen readers, braille readers, sip-and-puff controls, debugging shit like accerciser and the old at-poke), to an unknown number of widgets and widget toolkits. We have: screen readers \/--- Firefox dasher -\\ // LibreOffice debugging software --- ? - GTK+ apps braille readers // \\ Qt apps sip-and-puff control ---/\--- Your Momma's toolkit This is a classic mapping problem. You don't want to write (N+M)^2 implementations so that every screen reader can talk to Firefox, LibreOffice, etc., and vice-versa. Instead, you want a central abstraction so that you only have to write (N+M) implementations. at-spi is the central abstraction. It lets you navigate a user interface in very abstract terms, read what its various parts say, and write to user-modifiable parts. What controls do you have? Oh, is that control a table? Does that cell support an editable text interface? You say that there's an image there but the user can't see - do you have a textual description for it? Stuff like that. at-spi is that set of abstract interfaces described in D-Bus parlance. Right now, the at-spi2-core module is a C binding to those D-Bus interfaces. In C you call atspi_selection_get_selected_child() and it does a D-Bus call for you. That module also has a registry, whose purpose I don't fully understand, but I think it's so that things on the left side of the diagram above can find things on the right, and vice-versa. Or something like that. You also need the converse - something that receives the D-Bus requests and marshals them to real code. You want something that receives the D-Bus requests, unpacks the arguments, and marshals them to... what? anything could be on the other side - Firefox, GTK+, Qt, LibreOffice, etc. For GTK+, there are two intermediate layers between the D-Bus glue and GTK+ itself. One is the layer that actually receives the D-Bus requests and marshals them to more concrete code. That layer is at-spi2-atk. The other layer is ATK. As far as I can tell, ATK is just a re-statement of the interfaces that at-spi gave us, but in GObject terms. Instead of a DBus interface called org.blahblah.a11y.Selection, you have an AtkSelection which is a GTypeInterface. Instead of a DBus method called SelectChild, you have a vtable slot in AtkSelection called ref_selection. It's not called the same as the DBus method because... oh, I don't know, memory management details, or something. But ATK is just interfaces and glue, not real code. You want something that will take a GtkLabel and expose it as an AtkText. This adapter is GAIL. It's just a ton of code that takes GTK+'s ad-hoc, comfortable structure, and plugs it to the bunch of abstract interfaces that come from ATK (and that in turn come from at-spi). GAIL exists for historical reasons. We didn't want to glue the experimental a11y code directly to our stable GTK+ and the GNOME libraries, so we put that glue in a separate module. Applications with custom widgetry, like Evolution, usually implement the ATK interfaces directly in their code - they don't have a separate module like GAIL. There are several problems with all of this. Nobody likes to maintain glue code. It's tedious to write and it breaks in ways that are hard to test. Having GAIL separated from GTK+ makes them tend to be out of sync. ATK is duplicated interfaces. It needs to be kept in sync with the rather axiomatic interfaces provided by at-spi. It has to deal with messy details like GTK+'s reference counting (and who knows if at-spi is amenable to that kind of detail). Various other software has seen that ATK is a convenient place to plug in, and instead of providing its own DBus-toolkit layer, it instead implements ATK interfaces in terms of calling its own toolkit, and calls it a day. This is not a problem in itself, but it makes ATK even more of a point of failure. (FIXME: is this accurate? http://accessibility.kde.org/developer/atk.php suggests that this is what Mozilla does.) One problem may be that at-spi sometimes wants to be tightly-bound to things that are far away from it, and that's bad design. For example, consider the use of numerical indices in the Selection interface. When the innermost layer (GTK+ or any other toolkit, or a custom widget) changes something in its UI, the numerical indices that you got from at-spi may no
Re: [g-a-devel] GTK and ATK
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
