Manager: missing/inconsistent keyboard handlers

[RichardHaselgrove]

Describe the bug
Keyboard shortcuts for moving between controls on the Manager's 'Advanced View' display are broken. User report from user with broken pointing device, in https://boinc.berkeley.edu/forum_thread.php?id=13193

Steps To Reproduce
Under Windows -
The TAB key moves focus forward through all active controls on a page (command buttons, list controls). It does not move focus to the tab label.
Shift-TAB moves focus back through all controls, including the tab label - but doesn't continue to re-start the loop.
Ctrl-TAB and Ctrl-Shift-TAB cycle though the notebook pages. If the movement was started with the focus on a tab label, it moves through all pages. If the movement was started with the focus on a different control, it reaches the Notices page and stops there. There's no way off the Notices page (unless it has focus) from the keyboard, except by going via the View menu.

Under Linux -
TAB and Shift-TAB cycle through all controls, including the tab label, and continue on to the next control in the loop.
Ctrl-TAB does nothing.

System Information

• OS: Windows 7 and 10: Linux Mint, Cinnamon desktop: I don't have a Mac
• BOINC Version: up to and including v7.16.3

Additional context
This is poor design for users without the manual dexterity to use a precision pointing device. It also hinders users with a broken or missing pointing device.

[winkies]

@RichardHaselgrove Based on same logic as CTRL+A shortcut, I added the CTRL+TAB shortcut on advance view of boinc manager.
ATM, it's only available on my fork : see the Draft PR.

[CharlieFenton]

Please see my objection to adding the CTRL+TAB shortcut in this comment to #4146

[CharlieFenton]

This PR is not necessary or appropriate.

The ability to move among controls within the Advanced View are already present, at least for the Projects and Tasks tabs on MS Windows and Macs. The existing built-in and, I believe standard, controls for moving among controls within BOINC Manager are Tab and Shift-Tab. I believe these are implemented by wxWidgets itself, or perhaps by the Operating System, not by BOINC code.

As far as I can tell, there is only one problem associated with Tab and Shift-Tab: They don't work until an item in the list of tasks / projects has been selected. This is what needs to be fixed. We do not need to add even more keyboard shortcuts.

Once a list item is selected, the Tab key then moves focus through all the enabled buttons, followed by the selected list item. Shift-Tab moves through them in reverse order. When focus is on the list item, the up and down arrows allow select different items in the list. Holding down the shift key while pressing the up and down arrows selects multiple items.

BOINC already has keyboard shortcuts in the View Menu to select a different tab.

There are accessibility aids for people whose manual dexterity precludes using a pointing device. These are built in to MacOS; I don't know if MS Windows has them by default or if third-party software is needed on that OS or on Linux. We need to be careful not to conflict with these standard accessibility enhancements.

[AenBleidd]

The ability to move among controls within the Advanced View are already present, at least for the Projects and Tasks tabs on MS Windows and Macs.

You're right, but looks like Linux has no these handlers support so they could be added for linux only. I see no issues adding some additional features to particular platform to make user experience smooth (not all people use Mac os Windows).

We need to be careful not to conflict with these standard accessibility enhancements.

We always can test this before merging any stuff on all three platforms: I have limited access to Mac on Cloud so I can test that fixing this issue will not add any unexpected behaviour to Mac (I can do the same for Windows). I don't think it will be a big problem for Richard to test this on Windows and Linux.

[RichardHaselgrove]

Richard to test this on Windows and Linux.

Happy to help. The problem appears to be that standards are only standard within the confines of their own operating system. @CharlieFenton comments in #4146 (comment) that

Cmd+Tab is a standard keyboard shortcut on Macs to step through open applications. It is equivalent to Alt+Tab on MS Windows.

That's a non-standard (incompatible) standard, and we should indeed avoid interfering with it. But some of the problems - like Ctrl-tab reaching the Notices page under Windows and sticking there can only be coding bugs in our own sources. We should at least be internally self-consistent in our own use of private standards that don't conflict with global standards.

Aside - the only physical Mac keyboard in my house (20 years old and no longer connected to a working Mac) has four keyboard modifier keys: shift (up-arrow), control, alt (switch icon), and {apple - cloverleaf}. These are placed to correspond to Shift, Ctrl, Windows, Alt on my Windows keyboards. Are we sure we've got our terminology mappings correct? I don't see any conflict between our use of Ctrl and Apple's use of Cmd?

[CharlieFenton]

That's a non-standard (incompatible) standard

I guess I should have said that Cmd+Tab is a standard on MacOS to step through open applications, just as Alt+Tab is a standard on MS Windows to do the same thing.

the only physical Mac keyboard in my house (20 years old and no longer connected to a working Mac) has four keyboard modifier keys: shift (up-arrow), control, alt (switch icon), and {apple - cloverleaf}. These are placed to correspond to Shift, Ctrl, Windows, Alt on my Windows keyboards. Are we sure we've got our terminology mappings correct?

The alt key on a Mac keyboard is normally referred to as option in current Mac documentation. Most Mac keyboards have both terms on that key. Current Mac documentation refers to the {apple - cloverleaf} key as Command. Unfortunately, Apple generally uses the Command key where Windows and Linux generally use the Control key. so the mapping is different than one would expect from the keyboard layout.

I don't see any conflict between our use of Ctrl and Apple's use of Cmd?

wxWidgets description of wxMenuItem::SetItemLabel says:

Notice that CTRL corresponds to the "Ctrl" key on most platforms but not under OS X where it is mapped to "Cmd" key on Mac keyboard. Usually this is exactly what you want in portable code but if you really need to use the (rarely used for this purpose) "Ctrl" key even under Mac, you may use RAWCTRL to prevent this mapping. Under the other platforms RAWCTRL is the same as plain CTRL.

[CharlieFenton]

But some of the problems - like Ctrl-tab reaching the Notices page under Windows and sticking there can only be coding bugs in our own sources

I agree that is a bug, but I don't think it is in BOINC code. I've looked through BOINC's code and I haven't found any code that would do this. In fact, this website says

In almost any application that offers built-in tabs, you can use Ctrl+Tab to switch between tabs, just as you’d use Alt+Tab to switch between windows. Hold down the Ctrl key, and then tap Tab repeatedly to switch to the tab to the right. You can even switch tabs in reverse (right to left) by pressing Ctrl+Shift+Tab.

This web page offers several more examples of this.

I don't know if the use of Control+Tab and Control+Shift+Tab to step through the tabs are implemented by the Windows OS or by the Windows implementation of wxWidgets, but I nave not found any corresponding keyboard shortcut in BOINC on the Mac.

In any case, BOINC's View menu already offers keyboard shortcuts to each of the tabs in Advanced View on all platforms.

[RichardHaselgrove]

Ah. So we can either use the wxWidgets convention, and avoid using Ctrl modifiers in Mac contexts where clashes might occur.

Or we can use RAWCTRL, so that for our own private standards Ctrl means Ctrl, and we can use it without conflict.

My vote is for the latter.

[RichardHaselgrove]

My experience is with designing complex (multiple controls, of different kinds) user input screens under Windows - using a Microsoft graphical IDE design tool, enabling me to place controls directly on the form, specify their properties, and attach code to as many control-specific actions as necessary. It's a different way of doing things, and not directly transferable.

But I often had to tweak the 'Tab order' property of a control on the page, so that repeated pressing of the tab key cycled focus between controls on the page in a logical order. It strikes me that the 'Notices' tab was added to the page display much later than the others, after the initial design had stabilised. Might something have been omitted or overlooked in the properties of this new page, leading to the behaviour I'm observing? It can't be a generic feature of the wxWidgets (or Windows) implementation, because this one page behaves differently from all the others.

[AenBleidd]

@RichardHaselgrove, there is different issue with Notices tab: in contains web-browsing component that hooks all keyboard hotkeys (ok, not all but these two are hooked) so when your press Ctrl-Tab it actually happens inside this component and not hooked by UI tab itself. So in order to fix this we need to somehow override this behavior for some particular hotkeys.

[CharlieFenton]

This is a wild guess. The Notices tab uses wxWebView, and wxWebView itself supports tabs for displaying multiple web pages in separate tabs like a web browser. Might wxWebView be swallowing the Control-Tab keystroke, preventing it from reaching the higher level tabs in wxNoteBook?

If that is the case, the solution might involve adding an event handler for the EVT_WEBVIEW_NEWWINDOW event in clientgui/NoticeListCtrl.cpp. This documentation says:

Process a wxEVT_WEBVIEW_NEWWINDOW event, generated when a new window is created. You must handle this event if you want anything to happen, for example to load the page in a new window or tab.

[AenBleidd]

Might wxWebView be swallowing the Control-Tab keystroke, preventing it from reaching the higher level tabs in wxNoteBook?

Might be. @winkies, could you please try this solution?

[CharlieFenton]

NoticeListCtrl.cpp uses wxHtmlWindow instead of wxWebView on Linux systems which don't support wxWebView. Using wxHtmlWindow instead of wxWebView on MS Windows might fix this issue, though I don't know if wxHtmlWindow would work properly on MS Windows.

Testing this would simply mean changing all instances of #if wxUSE_WEBVIEW to #if (wxUSE_WEBVIEW && !defined(__WXMSW__)) in clientgui/NoticeListCtrl.cpp, clientgui/NoticeListCtrl.h and clientgui/stdwx.h.

[AenBleidd]

@CharlieFenton, this was an intentional change: 27bb3c9

[RichardHaselgrove]

I'll test that in Windows. I got as far as noting that there was no event handler in ViewNotices.cpp, and an unnecessary declaration of the non-existent OnRetryButton in ViewNotices.h, but neither was enough to fix it.

But I'll read up on 27bb3c9 and wxWebView for Windows first...

[winkies]

What a huge debate about shortcut !
I knew that MacOS has different shortcut than other OS (cause Cmd) : that's why I precised "It should be tested on MacOS X".

Or we can use RAWCTRL, so that for our own private standards Ctrl means Ctrl, and we can use it without conflict.

As defined in wxAcceleratorEntry enum, this solution appears to be the smoothest to manage shortcut based on Ctrl for all platform. If the idea is to avoid to write code for specific system, there is already conditional preprocessor only for MacOS shortcut...

[winkies]

Might wxWebView be swallowing the Control-Tab keystroke, preventing it from reaching the higher level tabs in wxNoteBook?

@AenBleidd, I'll investigate in this potential solution.

[RichardHaselgrove]

NoticeListCtrl.cpp uses wxHtmlWindow instead of wxWebView

Many experiments later, I don't think that's going to work on Windows without a lot of re-writing. I got a working build eventually, but I'd taken out so much that it wouldn't display any notices.

But I see that the notice list creator at https://github.com/BOINC/boinc/blob/master/clientgui/NoticeListCtrl.cpp#L86 includes wxTAB_TRAVERSAL (which is not well documented in the wxWidgets documentation).

Removing that property cures a large part of the problem: you can now Ctrl-tab through all pages of the main frame, even when the page tab identifier doesn't have focus. But if you click in the notice window area, ctrl-tab stops working again.

[CharlieFenton]

As defined in wxAcceleratorEntry enum, this solution appears to be the smoothest to manage shortcut based on Ctrl for all platform.

@winkies Have you actually tested this solution to see if it solves the problem of getting stuck in the Notices tab on MS Windows? Your comments say:

Tested only on Linux environment. It should work as well on Windows

@RichardHaselgrove Can you test the changes in #4146 on MS Windows? Based on the probable cause of the problem we have discussed here, it seems unlikely that PR will fix the problem of getting stuck in the Notices tab on MS Windows.

[RichardHaselgrove]

Tested and reported in #4146. Improvement, but not completely fixed.

[winkies]

I investigated and this is like dark magic.

After setup a Window environment, when the focus is on Notices page, there's no way out using keyboard as decribed @RichardHaselgrove.

In details, the Notices page is composed of wxWindow plus wxWebView.
To fix the problem, I tried:

• remove wxTAB_TRAVERSAL on wxWindow ctor option (doc)
• add wxWANTS_CHARS on wxWindow ctor option to get all key/event (doc)
• declare EVT_WEBVIEW_NEWWINDOW event table (= no trigger at all)
• disable child focus from wxWindow to not use Tab on this page.

It didn't work but I can affirm that when I called Ctrl-Tab or Ctrl-Shift-Tab, event is processed by BOINC code and not by MS system.
Based on this observation, I implemented Shift-Tab shorcut in AdvancedFrame, I triggered it on Notices Page and event successfully propagated.

In conclusion, in wxWebView all shorcut Ctrl based are ... in no man's land.

[CharlieFenton]

You might try the solution I suggested here:

adding an event handler for the EVT_WEBVIEW_NEWWINDOW event in clientgui/NoticeListCtrl.cpp

[CharlieFenton]

You might try the solution I suggested here:

Sorry, I see you already tried that. I did not notice that earlier.