STR #2862: Fl_Table keyboard nav issue: can't use tab to navigate off the widget

STR #2862

Application:	FLTK Library
Status:	4 - Pending
Priority:	3 - Moderate, e.g. unable to compile the software
Scope:	3 - Applies to all machines and operating systems
Subsystem:	Core Library
Summary:	Fl_Table keyboard nav issue: can't use tab to navigate off the widget
Version:	1.3-current
Created By:	greg.ercolano
Assigned To:	greg.ercolano
Fix Version:	1.3-current
Update Notification:	Receive EMails Don't Receive EMails

Trouble Report Files:

Post File

#1	greg.ercolano 11:16 Jul 19, 2012

foo.cxx
4k

#2	greg.ercolano 11:21 Jul 19, 2012

foo_v2.cxx
4k

Trouble Report Comments:

Post Text

#1	greg.ercolano 11:13 Jul 19, 2012

As per a thread started on fltk.general (**), investigating why tab doesn't navigate focus off Fl_Table. Attaching code showing the issue, a modified version of the simple-table.cxx example with just an Fl_Input field added. When run: 1) one can't use Tab to navigate to the input field 2) if focus is moved to the input field with the mouse, hitting tab moves focus to the table, but can't again be moved off using tab. So: a) Fl_Table should handle tab navigation b) Fl_Table should honor the new Fl::option(OPTION_ARROW_FOCUS) flag for arrow key focus navigation as well c) the table example programs that depend on arrow keys for internal navigation may need modification to take this flag into account, since arrow keys are used to navigate the cells in the table in some cases. d) Fl_Table should be modified to show focus (eg. focus box), as I don't think it currently does. **jseb opened a thread on fltk.general on 7/7/2012 asking about an issue with keyboard navigation and Fl_Table (Subject: keeping keyboard events in a widget)

#2	greg.ercolano 11:42 Jul 19, 2012

Added a v2 of the test program to this STR to fix a few things in the trivial first version: 1) Needed to end() the table to prevent the input field from becoming a child of the table. 2) Added code to show the selection state of the cells, as this is relevant; apparently the table is using tab navigation for its cells; hitting tab shows it walks the cells from left-to-right, and when it hits the end, focus moves on to the input field. Probably like the Fl_Input_ widget, Fl_Table needs something like the tab_nav() method which controls how the table responds to tab navigation specifically. Also, an odd behavior was noticed in v2; assuming the table were had a tab_nav() method and it were disabled (so that tab navigation doesn't move to other widgets, causing the table to use it for itself): Tab navigates cells forward (OK) Shift-Tab navigates cells in reverse (OK) but also does a multi-cell selection (BAD) IMHO, the behavior should work this way: tab_nav() enabled: tab + shift-tab navigate widgets, table does not use tab for its own cell navigation. Only arrow key navigation can be used to navigate cells (dependent on the OPTION_ARROW_FOCUS setting), and SHIFT can be used for multicell selection. tab_nav() disabled: tab + shift-tab navigate /cells/ forward or reverse. (No multi-select behavior for Tab) Arrows should also work, and Shift-Arrows should do multiselect, dependent on OPTION_ARROW_FOCUS. Perhaps too, there should be an Fl_Table method (if there isn't one now) to control whether multicell selection should be allowed or not. I imagine there might be cases where an app doesn't want multi-cell selection, or might not want interactive cell selection at all via mouse or keyboard. (eg. a 'read only' interface, where only the program can select cells)

#3	greg.ercolano 11:50 Jul 19, 2012

> Also, an odd behavior was noticed in v2; assuming the table were > had a tab_nav() method and it were disabled (so that tab navigation > doesn't move to other widgets, causing the table to use it for itself): Good grief, grammar. Too bad we can't edit bugs. That should have been: Also, an odd behavior was noticed in v2; assuming the table had a tab_nav() method, and the flag was disabled so that tab navigation doesn't move to other widgets and the table can use Tab for itself:

#4	greg.ercolano 01:41 Mar 23, 2013

Fixed in Subversion repository. Fixed (a) and (b) in r9843. Partial changes for (c): examples/table-spreadsheet.cxx Regarding (a): by default FLTK uses Tab to navigate widgets. However, one can enable the new Fl_Table::tab_cell_nav() flag to allow Tab to navigate table cells. Regarding (c): the examples/table-spreadsheet.cxx example was modified to make use of this new feature, and the example works better/more predictably. More to come as other table examples are modified. The new Fl_Table::tab_cell_nav() method breaks ABI, so to to access it in FLTK 1.3.x, YOU MUST UNCOMMENT the FLTK_ABI_VERSION macro at the top of the FL/Enumerations.H file before rebuilding FLTK.

#5	greg.ercolano 02:19 Mar 23, 2013

Looks like Fl_Table_Row needs some fixes as well to support keyboard navigation. So still todo: e) Fl_Table_Row should heed new tab_cell_nav() f) Fl_Table_Row needs a row focus box, similar to Fl_Browser, so user can toggle-select rows in MULTI select mode g) Fl_Table_Row needs to support things like SHIFT-Home, etc to extend selections, and other key combos to toggle selection, etc.

#6	greg.ercolano 02:57 Mar 23, 2013

Made small change in r9844 so that Tab can navigate to/from the input field in foo_v2.cxx attached in this STR when the ABI feature is /disabled/. (It worked OK when ABI feature was enabled) This also fixes the test/table app, which previously had trouble with tab navigation. With r9844, status of issues is: (a) Done (b) Done (c) Tested: -- OK -- > test/table -- OK: tab navigates to/from inputs > examples/table-as-container -- OK: tab navigates table widgets -- FAILED -- > examples/table-sort -- FAIL: because Fl_Table_Row (WIP) > examples/table-with-keynav -- FAIL: can't nav to checkbox+Output -- NOT APPLICABLE -- > examples/table-spreadsheet -- N/A: no other widgets to tab to > examples/table-simple -- N/A: read only, "" > examples/table-spreadsheet-with-keynav -- will be obsolete (d) TODO (e) TODO (f) TODO (g) TODO

#7	greg.ercolano 03:01 Mar 23, 2013

Adding another item to the issues list: (h) Both Fl_Table and Fl_Table_Row will need to heed Fl_Widget::visible_focus() (when focus box is added)

#8	ianmacarthur 16:38 Sep 04, 2014

Greg, what's the state of this one? We can close...?

#9	greg.ercolano 13:39 Oct 27, 2014

Regarding Ian's comment #8: partially fixed (see commits in comments #4 and #6), but some stuff still to do. Current unfinished state should not affect 1.3.3 release I think; the items fixed in comment #4 and #6 stand on their own.