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
