GNOME Bugzilla – Bug 132745
Add accessibility implementation for private GtkHSV widget
Last modified: 2011-02-04 16:16:07 UTC
When GtkColorSelctionDialog is activated the focus is on a GtkHSV widget. Accessibility code cannot recognize it a GtkHSV widget as the include file gtkhsv.h is not installed so gnopernicus can only report that an unknown object has focus.
In addition, when focus is moved to or from ring it is not possible to emit any notification.
gtkhsv.h will not be installed, and we need the freedom to use non-public widget classes in composite widgets. So, you can propose how we would fix this without doing that?
I cannot do it in gail if I do not access to gtkhsv.h file. The only other option would be to add the accessibility support to gtkhsv.c file.
One proposal in bug 112479 to improve the keynavigatability of the color selection dialog was to put the initial focus not on the gtkhsv, but on the color name field.
I just had a look and noticed that while we do not install the gtkhsv header, the symbols *are* exported, so you should simply use a gail-private copy of the header, if you're willing to take the small risk that GtkHSV may change incompatibly.
If possible, I think the solution we would like to take here is to put any accessibility implementation needed for GtkHSV into GTK+ itself.
Here is a discussion I had with Bill about the implementation: <maclas> billh: nice to see you're back...today I wondered which accessible interface gtkhsv (the color wheel) should support? <maclas> billh: AtkValue is only for single numerical values, it seems, and the color wheels controls three values at the same time... <billh> maclas: sounds like three AtkValues then. <billh> maclas: there's no rule that every GtkWidget must reduce to only one AtkObject... <maclas> billh: so the accessible of a widget can actually be a collection? <billh> maclas: there are several options. could be a collection (probably most reasonable in this case) * billh tries the colorwheel again <maclas> billh: what does the Java color selector do ? <billh> maclas: want to talk in another channel? hash out the possibilities? * billh isn't sure <maclas> billh: its not as if I actually wanted to work on this, I was just curious... <billh> maclas: good thought though - prolly should be as consistent as reasonably possible. * billh runs SwingSet2 <billh> oh funky, the Java splash screen is transparent on the freedesktop.org xserver! <billh> maclas: heh heh, the SwingSet2 color chooser looks _exactly_ like the gtk+ one! <billh> maclas: predates it though ;-) <andersca> billh: actually, it looks different if you use the motif look and feel <billh> maclas: cop-out :-) the java color chooser triangle widget is just an inert panel :-) <billh> andersca: ah. yes. <maclas> billh: thats cheap <billh> maclas: but I think the easy solution is to implement AtkValue on the H, S, V and R, G, B controllers, and set the CONTROLLER_FOR/CONTROLLED_BY relations on the HSV widget. <billh> maclas: but yeah, cheap. <maclas> billh: may be good to put that in the relevant bug, what's its number ? <billh> maclas: so the HSV etc combos are complex, they implement AtkText, AtkValue, and AtkComponent, with the AtkRelations. <maclas> billh: aren't they just regular spinbuttons, a11y-wise ? <billh> maclas: I guess, lemme see <billh> maclas: actually the SwingSet color picker is bad - inaccessible IMO - or maybe java-access-bridge for GNOME is busted - you can't see the spinbuttons in the hierarchy. <maclas> billh: the relevant bug is #132745; I'll put your comment there <billh> maclas: thx. I think the main prio is making sure the spinbuttons work well, implement AtkValue, and point to the HSV widget as CONTROLLERS. that's 90% of the way there IMO. <billh> maclas: feel free to insert this IRC log.
I want to make sure I undersant what is being proposed here: The accessible object for the HSV should have 6 CONTROLLED_BY relations specifying the accessible object for R,G,B,H,S,V spin-buttons. The accessible object for the spin-buttons should have a CONTROLLER_FOR relation specifying the accessible object for the HSV widget. It looks to me that gtkcolorsel.c is the logical place to set these relations. Currently the accessible object for HSV widget has a null accessible name and an accessible role of UNKNOWN. I think we need to set an accessible name. e.g. "Color Wheel". I do not a better role than unknown. I think that setting the accessible name could also be done in gtkcolorsel.c. If this is acceptable. I can produce a patch.
Sounds good to me padraig - I wonder where ROLE_COLOR_CHOOSER should be used in this hierarchy (rather than for the dialog, as the ATK docs state)? I attach the at-poke hierarchy for the SwingSet2 color chooser dialog.
Created attachment 25514 [details] snapshot of at-poke hierarchy for SwingSet2 color chooser for comparison
Created attachment 25876 [details] [review] Proposed patch
Comment on attachment 25876 [details] [review] Proposed patch Padraig, feel free to go ahead and commit the patch. Don't forget to mail gnome-i18n about the string addition, though.
Should I commit the change without the translated string now and only translate the string after branch for GTK 2.6?
I just went ahead and committed the patch.