Rename/Refactor `Command.Select` and `Selecting` Event to `Activate`

[tig]

Summary

The Command.Select, Selecting event, and related APIs (OnSelecting, RaiseSelecting) should be renamed to Command.Activate, Activating event, OnActivating, and RaiseActivating to improve clarity and consistency in the Command system. The term "select" is ambiguous for stateless views (e.g., Button, MenuItemv2, where it only sets focus) and less precise for non-list-based state changes (e.g., toggling a CheckBox). "Activate" better captures the action of changing a view’s state or preparing it for interaction, aligning with both stateful (e.g., CheckBox, FlagSelector, ListView) and stateless (e.g., Button, MenuItem) use cases while clearly distinguishing from Accepting.

Motivation

The current Command.Select and Selecting terminology has several issues:

1. Ambiguity in Stateless Views: For views like Button or MenuItem, Command.Select only sets focus, which isn’t typically considered “selection,” leading to developer confusion.
2. Imprecise for Non-List Contexts: In CheckBox (toggling state) or FlagSelector (toggling flags), “select” doesn’t fully capture the state change, unlike list-based selection in ListView.
3. Overlap with Accepting: In views like ListView or Menu, Selecting and Accepting can feel similar (e.g., Enter triggering both), requiring clearer distinction.
4. Propagation Needs: MenuBar requires Activating events from subviews to manage PopoverMenu visibility, but the current local handling model relies on view-specific events (e.g., SelectedMenuItemChanged), which isn’t generalizable. Subviews should remain decoupled from superviews, avoiding knowledge of superview implementation details (e.g., MenuBar’s popover logic).

The Activate terminology addresses these by:

• Representing both state changes (e.g., toggling a CheckBox, selecting a ListView item) and preparatory actions (e.g., focusing a Button, navigating a MenuItemv2).
• Distinguishing clearly from Accepting, which confirms actions (e.g., executing a menu command, submitting a dialog).
• Supporting a targeted propagation model with PropagateActivating, enabling superviews like MenuBar to opt-in to subview Activating events without coupling subviews to superview details.

Proposed Changes

1. Rename Command.Select and Related APIs to Activate

• Rename Command.Select to Command.Activate in the Command enum.
• Rename Selecting event to Activating, OnSelecting to OnActivating, and RaiseSelecting to RaiseActivating in the View class and all derived classes (e.g., Menuv2, MenuItemv2, CheckBox, FlagSelector).
• Update related code:
  • Modify SetupCommands in View to use Command.Activate.
  • Update Shortcut.DispatchCommand and other command handlers to reference Activating.
  • Ensure all event handlers and documentation reflect the new terminology.
  • Ensure all tests are appropriately renamed and updated

Related

• Enable using MenuBar as an alternative for ComboBox #2404

[tig]

@tznind and @BDisp - Need your thoughts on this before I dive in. Would appreciate any questions or ideas you have.

FWIW, i've already decided PropagateActivating should be a cancellable event and not a bool property.

[BDisp]

I agree that is needed to differentiate some similar states but with different behaviors which will give much more control to the code flow. Good catch.