Keyboard navigation in wxAUI

[Julian Smart]

As noted by a user who filed a bug report about it (http://sourceforge.net/tracker/index.ph ... tid=109863), there is no keyboard navigation between panes or tabs in wxAUI. This is definitely a problem when it comes to making one's application accessible, and there are even potential legal issues for inaccessible apps.

This probably isn't a priority for Kirix and I recognise it's a relatively boring thing to have to worry about, but I would like to push for some progress on this; wxWidgets should be encouraging development of accessible apps. I would be happy to contribute some or all of a bounty, and perhaps others would like to join in with either coding or funding.

What should we be adding to wxAUI to make it keyboard-friendly? Here are some thoughts:

• When you click on a tab in a wxAuiNotebook, it should get the focus (marked by a dotted rectangle), and left and right arrow keys should navigate through the tabs. Tab should go to the first control in the page (presumably).
• There should be a key combination for showing the Window list in a wxAuiNotebook, or at least a programmatic way of showing it so the application can supply an accelerator.
• There should be a way of cycling through panes. A pane can be shown as active using wxAUI_MGR_ALLOW_ACTIVE_PANE, which is a good start, since then some key combination could be assigned to going to the next available pane. Or maybe there should be a pane menu mirroring the wxAuiNotebook window menu. I don't know if tab should be used for cycling through panes - perhaps some other key combination. The ability to cycle through panes programmatic would at least allow the application to decide how the keyboard should be used to do this.
• There should be a way of docking/undocking panes via the keyboard. This could be supplied by the application, of course, but it would be nice to have support built-in.
• Maybe there could a context menu in each toolbar with a list of commands. However, navigating between toolbars would be tricky unless a toolbar could be marked as 'active': perhaps the gripper could change colour.
• There are other functions that might be harder to support via the keyboard, such as moving tabs between notebooks and resizing panes, but if the API is there to support these things (for example unsplitting a notebook, which currently can't be done programmatically in wxAUI) then the app can do the rest.

Although not wxAUI-specific, another idea is to have a pane or dialog that shows the app's window structure in a tree, so the user can quickly call up this window, navigate through the tree via the keyboard, and then press return to go to the desired pane. wxAUI could present the app with functions for adding a wxAuiManager's panes and tabs to this navigator dialog. Windows that are not currently visible can also be present in the navigator, e.g. a command to invoke the Preferences dialog. (In fact the whole dynamic application and document structure could be reflected in the navigator, but this is getting off-topic.)

It would be helpful to find examples of how pane navigation is done in other apps, but I haven't found anything yet - Visual C++ 2005 doesn't appear to allow keyboard navigation of its tabs, let alone the panes.

Any thoughts very welcome. Pity we don't have another GSoC coming up soon...

Thanks,

Julian

[Huge]

Hi,
I think these are all very worthy ideas, except maybe the toolbar one if there is an equivalent menu option, which I'm guessing there almost always will be. eg Alt (to show menu keys) f (for file) s (for save) is a very reasonable alternative to the "save" toolbar button. If you have accessibility issues, this is probably the preferred method (even better would be a hot key).

In my current applications I create a "view" menu with all panes listed on it, which "Shows" the windows. This is also useful if you do something like drag a window onto a second monitor and save your persective and later unplug your monitor. The option will bring it back.

In a past life, I did some different wxWindows layout code and made use of a dialog box that listed all the panes and their positions, which could be changed with text/combobox, eg "docked left" etc. (list box on the left, properties on the right) This was good for debug purposes, and also gives a centralised way on managing layouts (save layout as... etc).

So here are some ideas that might help.
- Give the AUI a wxMenu* to manage, so it can stick all the panes on it.
- Allow a hot-key to be associated with a pane, to quickly set focus/bring to top/float if required.
- Create a "common" dialog that can be easily instancated (eg mManager->ShowLayoutDialog()), giving fine-grain control over the panes, also perspective control via, say, wxConfig.

I think "tab"bing around would be good too.

Huge

[Julian Smart]

Hello Huge,

Thanks for your insight - good point about not requiring toolbars to be accessible; my thought was that perhaps a user might like to tailor the toolbars and then have just those commands available e.g. via a context menu for each toolbar, but it's probably overkill.

Good point also about the View menu. If we can make that easier for the app to implement without explicitly coding the menus and handlers, plus do tabbing for wxAuiNotebook, it should go a long way to solving the problem. I like the idea of the generic pane manipulation dialog as a slightly lower priority.

To my mind the top priority is getting keyboard navigation working for wxAuiNotebook, since other aspects can be implemented by the app for the time being. I think we need:

• A new wxAuiButtonState state, wxAUI_BUTTON_STATE_FOCUSED.
• Additional code to draw a focused tab. We will need to change the code to test for the presence of a flag rather than the current equality test since a button could be e.g. focused and pressed simultaneously. We could add another flag but that seems unnecessary.
• Code to set button.cur_state to focused when clicked. The tab window will need to return true from AcceptsFocus().
• Code to find and navigate to the next or previous tab when an arrow key is pressed, and tab to the first contained control when tab is pressed.
• When a page selection is set, the page tab should be focused.
• API to programmatically cycle through tabs (see wxNotebook::AdvanceSelection).

Have I left anything out? I expect there will be complications, but the task seems manageable. However I'm a bit hazy about how the actual tab window structure works - there are complications relating to managing split notebooks. Ben, any gotchas that you can see or advice on implementation?

Thanks,

Julian

[Ben]

Hi Julian,

The steps below are exactly what is needed. I'll be happy to review the patch once it's ready. This should be a pretty straight-forward feature addition.

All the best,
Ben

* A new wxAuiButtonState state, wxAUI_BUTTON_STATE_FOCUSED.
* Additional code to draw a focused tab. We will need to change the code to test for the presence of a flag rather than the current equality test since a button could be e.g. focused and pressed simultaneously. We could add another flag but that seems unnecessary.
* Code to set button.cur_state to focused when clicked. The tab window will need to return true from AcceptsFocus().
* Code to find and navigate to the next or previous tab when an arrow key is pressed, and tab to the first contained control when tab is pressed.
* When a page selection is set, the page tab should be focused.
* API to programmatically cycle through tabs (see wxNotebook::AdvanceSelection).

[Julian Smart]

Hi Ben,

In fact I didn't need the extra state flag. I've committed an implementation to SVN trunk and 2.8 (and added some forgotten symbols to version-script.in for binary compatibility, along with the new ones). I've also added the public functions AdvanceSelection (as per wxNotebook) and ShowWindowMenu. Selecting a page now automatically scrolls the tab into view if necessary.

There is a slight difference in mouse behaviour but one can regard this as a bug fix: when clicking on a tab, the page (and therefore a control on the page) doesn't have the focus set; instead the tab itself is focused, allowing visual feedback (the focus rectangle) and keyboard navigation through the pages. On most platforms, tab will take you to the first control. This is the behaviour of the standard wxNotebook on wxMSW so it does have the benefit of being what people will expect. It's tempting to add a flag to bring back the behaviour of focusing on the first control in the dialog, but this would encourage less accessible applications - it would be impossible to navigate the tabs via the keyboard.

I've tested it on wxMSW, wxGTK2, wxX11 and wxMac. (The AUI demo on wxMac in SVN trunk crashes during toolbar creation - I'm hoping Stefan Csomor can comment on that since it's likely to be due to recent wxMac changes.)

Thanks,

Julian

[Julian Smart]

P.S. I've fixed the focus issue - I hope - in a similar way to how it works on Firefox; if you click twice on a tab, it will get the focus, but if the focus is on a page, then clicking on a tab will put the focus on the next page. We probably still need to resolve focusing the tab via the keyboard only.

Regards,

Julian