GNOME Bugzilla – Bug 117568
unable to select items in trees (and table rows)
Last modified: 2004-12-22 21:47:04 UTC
Using gnome-2.4 nightly build from 14 July 2003. . logged in as normal user from failsafe session - run gok - go to a GTK tree selection(theme prefs or mouse prefs) - select UI GRab . there is no button on GOK keyboard to access the tree options, only the available button widgets are selectable.
David, thanks again. This is a known issue. The UI grab feature is not exhaustive. It is, however an ultimate goal and so I will open an uber-bug for adding UI grabbage. I am not sure this is priority for 2.3 as the user can still branch to the compose keyboard and use "regular" keyboard access to control the GUI.
Apologies for spam... marking as GNOMEVER2.3 so it appears on the official GNOME bug list :)
marking prio and severity 'normal' since we want to expose as much UI via UI-Grab as is feasible.
theme prefs (at least, the list items in the theme list) now appear in gok as separate buttons which are user-actionable. I don't see any trees in the Mouse preferences dialog. However, the sliders are not actionable via UI Grab.
sliders are a separate issue. Current tree issue: cells are visible in UI Grab, but attempting to select or activate them via at-spi doesn't do anything, thus GOK's UI Grab buttons for them are ineffectual.
Padraig informs me that for tables with > 1 column, the present implementation AccessibleSelection won't allow you to select children; you must use AccessibleTable_selectRow instead. Unfortunately that API is missing from cspi, it's only available via libspi (ugh!).
Created attachment 25412 [details] [review] patch to provide back-compatible wrappers for table selection ops
the above patch would give us access to the API we need in order to implement usable selection of lists. To actually make this work for existing GNOME desktop treeviews will require an additional patch to the gok-keyboard/gok-spy code. I suggest that when we get such a patch working we add the PATCH keyword.
*** Bug 137220 has been marked as a duplicate of this bug. ***
I think the above patch would be acceptable into the 2.6.X stream as it does not expose any new API and prevents a dependency on a post-gnome-2.6 version of AT-SPI. David?
Created attachment 26119 [details] [review] patch as applied to cvs
I talked to David on IRC today and he thought this patch was acceptable for HEAD.
marking severity 'major' due to anecdotal reports of dups - this seems to impact a number of our accessibility tests.
Created attachment 26163 [details] [review] attachment to provide UI Grab selection of table rows this patch also supercedes the previous patch - it uses a more elegant alternative to wrapping the methods in gok/gok-table-ops.[ch].
Bill, patch looks good. Do you think we'll see an "unable to select table columns" in the near future ;-)
Created attachment 26179 [details] [review] improved patch which works well with file selectors and more complex tables nearly-complete version of the patch, which works well with the fileselector/filechooser as well as simpler tables. Only thing it's missing at the moment, I think, is logic to make sure it doesn't expose table rows that are scrolled out of the current view (working on that now).
Created attachment 26180 [details] [review] patch which also limits the table's keyboard to visible rows this version of the patch is a candidate for committal once the ChangeLog is written.
Created attachment 26183 [details] [review] patch with ChangeLog, excluding extraneous changes to po files, etc. this version of the patch should be committable as-is.
David: we have two working versions of this patch now - the one from 15:28, which is for simple tables only (i.e. theme selector), and from 15:49 which is considerably more complex, but which provides good support for the GNOME/gtk+ 2.6/2.4 fileselector. Question is whether the risk/complexity of the larger patch is outweighed by the value of good file selector support. I am leaning towards "yes" since the fileselector is so important to GNOME 2.6, but am waiting for your input.
I too lean towards "yes". I am a bit concerned about: + if (!retval) + gok_log ("SELECTACTION failed"); + + return retval; Since I wonder if the gok_log becomes a noop, I don't know what the compiler will do with this. Hopefully a value is always returned. I've skimmed the code, but it would be reassuring to know you had valgrinded your sandbox. There is lots of string stuff... makes me nervous ;-)
the gok_log call does get reduced to a noop call. I can add braces if that makes you feel better :-) I'll valgrind before committing, seems like a good idea in any case.
Created attachment 26207 [details] [review] patch as applied
fixed in cvs