Standardize common events for Control-like Views (Select, Accept, HotKey, etc...)

[tig]

v1 was all over the map for how the built-in Views dealt with common keyboard user-interactions such as pressing Space, Enter, or the Hotkey. Same for mouse interactions such as Click andDoubleClick.

I fixed a bunch of this a while back in v2 for Accept and Hotkey as part of making Shortcut and the new StatusBar work. Shortcut is a compbound View that needs to be able to host any view as CommandView and translate user-actions of those subviews in a consistent way.

As I've been working on really making Bar support a replacement for Menu, ContextMenu, and MenuBar I've found that my work wasn't quite right and didn't go far enough.

This issue is to document and track what I've learned and lay out the design for addressing this correcxtly.

Related Issues:

• Modernize Menu - Base on Bar and address litany of issues #2975
• Finalize v2 Default Visual Style  #3493
• Enable using MenuBar as an alternative for ComboBox #2404
• Views must not blindly return true from Command functions #3631
• Refactor and align event handling with common/best practices #3209
• Support INSERT key in addition to SPACE for selecting items in ListView #385

I started fixing this in

• Abandoned - Fixes #3691. Adds Popover #3749

However, I'm going to branch that work off to a new branch derived from v2_develop to address this issue separately.

Here's a deep-dive into the existing built-in Views that indicate the inconsistencies.

				Keyboard				Mouse
	Number of States	Static	IsDefault	Hotkeys	Select Command Space	Accept Command Enter	Hotkey Command	CanFocus Click	CanFocus DblCLick	!CanFocus Click	RightClick	GrabMouse
View	1	Yes	No	1		OnAccept	Focus	Focus				No
Label	1	Yes	No	1		OnAccept	FocusNext	Focus		FocusNext		No
Button	1	No	Yes	1	Focus OnAccept	Focus OnAccept	Focus OnAccept	Focus OnAccept		OnAccept		No
Checkbox	3	No	No	1	AdvanceCheckState OnAccept	AdvanceCheckState OnAccept	AdvanceCheckState OnAccept	AdvanceCheckState OnAccept		AdvanceCheckState OnAccept		No
RadioGroup	> 1	No	No	2+	Set SelectedItem OnAccept	Set SelectedItem OnAccept	Focus Set SelectedItem OnAccept	SetFocus Set _cursor		SetFocus Set _cursor		No
Slider	> 1	No	No	1	SetFocusedOption OnOptionsChanged	SetFocusedOption OnOptionsChanged OnAccept	Focus	SetFocus SetFocusedOption		SetFocus SetFocusedOption		Yes
ListView	> 1	No	No	1	MarkUnMarkRow	OpenSelectedItem OnAccept	OnAccept	SetMark OnSelectedChanged	OpenSelectedItem OnAccept			No

Next, I'll post a table showing the proposed design.

This will involve adding View.OnSelect virtual method and a Select event to View.

User Interaction Model

Here's what we're really talking about here: What is the correct user interaction model for common actions on Views within a container. See navigation.md for the baseline. Here we're going beyond that to focus on:

• What happens when there are bunch of SubViews and the user presses Enter with the intention of "accepting the current state".
• What happens when the user presses Space with the intention of changing the selection of the currently focused View. E.g. which list item is selected or the check state?
• What happens when the user presses HotKey with the intention of causing some non-focused View to EITHER "accept the current state" (Button), or "change a selection" (RadioGroup).

Same for mouse interaction:

• What happens when I click on a non-focused View?
• What if that view has CanFocus == false?

This gets really interesting when there's a View like a Shortcut that is a composite of several subviews.