TabBehavior naming confuses

[tig]

I've found this new parameter quite confusing. Maybe I need to read docs closer but most times in tests were I needed to specify the parm to build it, i guessed and test passed...

Originally posted by @tznind in #3766 (comment)

Current defns:

https://gui-cs.github.io/Terminal.GuiV2Docs/api/Terminal.Gui.TabBehavior.html

Describes how TabStop behaves. A TabStop is a stop-point for keyboard navigation between Views.

• NoStop = 0 - The View will not be a stop-point for keyboard-based navigation.
  This flag has no impact on whether the view can be focused via means other than the keyboard. Use CanFocus to control whether a View can focus or not.

• TabGroup = 2 - The View will be a stop-point for keyboard-based navigation across groups. (e.g. if the user presses NextTabGroupKey (Ctrl+PageDown)).

• TabStop = 1 - The View will be a stop-point for keyboard-based navigation across Views (e.g. if the user presses Tab).

NOTE: There's a bug above. Replace "Ctrl+PageDown" with Application.NextGroupKey which is F6 by default.

Discussion...

I invented all this primarily for Overlapped scenarios, but it is also relevant in Tiled scenarios where there is either significant nesting of Views or just a large UI surface area. Other UI systems have similar constructs and I borrowed the Group terminology from Win32 where there is the concept of a Groupbox UI element...

In keyboard.md we have these tenets, which I feel are pretty good. But nobody ever pushed back on any of them, so they really just represent MY opinion. Please do yell if there's something in here you disagree with or doesn't feel right to you:

Tenets for Terminal.Gui Keyboard Handling (Unless you know better ones...)

Tenets higher in the list have precedence over tenets lower in the list.

• Users Have Control - Terminal.Gui provides default key bindings consistent with these tenets, but those defaults are configurable by the user. For example, @Terminal.Gui.ConfigurationManager allows users to redefine key bindings for the system, a user, or an application.

• More Editor than Command Line - Once a Terminal.Gui app starts, the user is no longer using the command line. Users expect keyboard idioms in TUI apps to be consistent with GUI apps (such as VS Code, Vim, and Emacs). For example, in almost all GUI apps, Ctrl+V is Paste. But the Linux shells often use Shift+Insert. Terminal.Gui binds Ctrl+V by default.

• Be Consistent With the User's Platform - Users get to choose the platform they run Terminal.Gui apps on and those apps should respond to keyboard input in a way that is consistent with the platform. For example, on Windows to erase a word to the left, users press Ctrl+Backspace. But on Linux, Ctrl+W is used.

• The Source of Truth is Wikipedia - We use this Wikipedia article as our guide for default key bindings.

• If It's Hot, It Works - If a View with a @Terminal.Gui.View.HotKey is visible, and the HotKey is visible, the user should be able to press that HotKey and whatever behavior is defined for it should work. For example, in v1, when a Modal view was active, the HotKeys on MenuBar continued to show "hot". In v2 we strive to ensure this doesn't happen.

NOTE we ALSO have this high-level tenet in mouse.md:

• Keyboard Required; Mouse Optional - Terminal users expect full functionality without having to pick up the mouse. At the same time they love being able to use the mouse when it makes sense to do so. We strive to ensure anything that can be done with the keyboard is also possible with the mouse. We avoid features that are only useable with the mouse.

Examples

Consider AllViewsTester:

If we only had TabStop as in v1, for the user to use the keyboard only to navigate from the list of classes to the selected View (ColorPicker above), they would have to press Tab about 15 times.

Because Classes, AdornmentsEditor, Settings, and the host of the example View are all set to TabStop = TabBehavior.TabGroup the user can press F6 (NextGroupKey) 3 times and ColorPicker will be focused.

Or, the user could press F6 twice and the Settings group will be focused (X: specifically).

F6 was choosen because that's what WIindows uses for navigating to "higher level" UI elements (e.g. in Edge, hit F6 to navigate to the tab-bar).

Consider Navigation:

Without the concept of a TabGroup, how would a user navigate with the keyboard from the Overlapped3 View to the overlapped DatePicker (or to the AdornmentsEditor (without using hot keys)?

FWIW, I did a bunch of work to make sure HotKeys work across the View hierarchy to honor the If It's Hot, It Works tenet above. But I do not think that's good enough. We need something like Tabgroup too

Name

I choose Group. I think this is the source of @tznind's confusion as it's not really a great term. But I'm struggling to suggest an alternative.

Halp!