After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 129450 - GOK 'UI Grab' tables
GOK 'UI Grab' tables
Status: RESOLVED FIXED
Product: gok
Classification: Deprecated
Component: general
unspecified
Other Linux
: Normal enhancement
: ---
Assigned To: David Bolter
David Bolter
Depends on: 117568 133413
Blocks: 117582
 
 
Reported: 2003-12-16 11:38 UTC by david.hawthorne
Modified: 2004-12-22 21:47 UTC
See Also:
GNOME target: ---
GNOME version: Unversioned Enhancement



Description david.hawthorne 2003-12-16 11:38:22 UTC
Currently navigating tables such as common 'Browse for file' or 'Pick a
Font' tables are navigable only by using GOK's 'Compose' for keynav. 
Personally I've found this tedious, especially with large tables. Is
there/will there be any plans to make tables 'UI Grabble' so that they are
accessible in GOK in menu-form? I'm aware such a change could be unfeasable.
Comment 1 korn 2003-12-16 17:22:59 UTC
I think this is a good RFE to consider post 1.0.  What are your
thoughts as to where and how this might work?  Only editable tables? 
Tables with particular roles for elements?
Comment 2 david.hawthorne 2003-12-16 17:49:28 UTC
I've only really considered tables such as those in 'Pick a Font'. For
example:
There are 3 tables, 'Family', 'Style', and 'Size'. In simplest form,
if the items populating these tables could populate a separate GOK
menu, selectable using UI Grab. So in this case, UI Grab would not
only have buttons for 'OK' 'Cancel', but also 3 more 'Family' 'Style'
and 'Size'. Clicking these would have the equivalent effect of
clicking a button under GOK's 'Menus' section, and all items would be
readily selectable by the user without having to (slowly) 'Compose'
up/down/tab to achieve 3 selections.

The same could apply for the numerous 'Browse for file' windows,
albeit more tricky to implement as the contents of these tables change
dynamically as one traverses folder/file hierarchy.. just a thought :)
Comment 3 bill.haneman 2004-01-28 12:58:40 UTC
This is partially addressed already by GOK's UI Grab for list items
and table cells which are selectable/actionable.

See related bug 117568, which is currently blocked by some issue in
gail/or/gtk+.
Comment 4 korn 2004-03-07 19:59:25 UTC
I wonder if it would make sense to have a "navigation" keyboard for
addressing the various kinds of navigation scenarios that arise.  Such
a keyboard would have Tab & Shift-Tab, the arrow keys, and perhaps a
few other things (home & end, ESC?).  We've done a very good job of
providing very efficient navigation with UI grab, but there are still
a number of situations where that doesn't work.  I've created a new
RFE to address this topic: Bug #136482.
Comment 5 bill.haneman 2004-03-08 16:17:20 UTC
David: this bug doesn't totally depend on 133413; we could easily work
around 133413 in GOK by calling the libspi methods directly (rather
than via a cspi binding, for the 2 or 3 relevant method calls).
Comment 6 David Bolter 2004-03-08 16:23:05 UTC
Agreed -- I nearly commented to that effect but didn't save.  It is
really just so that this bug pings us when 133413 is fixed...  I'm
abusing bugzilla slightly ;-)
Comment 7 bill.haneman 2004-03-31 20:58:52 UTC
UI Grab for tables now provides for:
* selecting a table row via a GokKey
* activating a row or column header if available (this can do things like sort
according to various headers)

if the patch for bug #117568 is applied.  I think we can close this bug if that
patch goes in, at least for now (we can consider enhancements to the table grab
later, on an individual basis).
Comment 8 bill.haneman 2004-04-01 12:31:17 UTC
fixed by patch for #117568