Fixes #4050 - Select->Activate

[tig]

Fixes

• Fixes Rename/Refactor Command.Select and Selecting Event to Activate #4050
• Fixes Fixes #4167. Button is always raising Accepting event 2 more times by mouse #4168
• Fixes View.Mouse raises MouseClick 3 times when it should just raise it once #4167
• Fixes View.OnMouseClick/MouseClick should be deleted in favor of Activating #4176
• Fixes Button.IsDefault is confusing #4170

Proposed Changes/Todos

• Command.Select->Activate
• 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.
• Update Documentation
  • Clarify Activating vs. Accepting:
  • Update view-specific docs
• Refactor OptionSelector & FlagSelector -> less duplicated code.
• Revisit how Activate and Accept propogate - esp w/in Shortcut etc...
• Go through built-in Views and ensure Selected / Activated terminology is correct (e.g. TreeView, TableView, ...)

For another PR

I was going to do this here, but I'll do it in another PR:

• Introduce Targeted Propagation Model with PropagateActivating
  • Document propagation: Explain the targeted model with PropagateActivating, providing examples for MenuBarv2 and potential Toplevel use cases.
• Delete RadioGroup - OptionSelector is now a 100% compatible clone

[tig]

I'm not convinced we don't still need a Command.Select in ADDITION to Command.Accept.

Code like this in TableView...

        // BUGBUG: OnCellActivated is misnamed, it should be OnCellAccepted? Or is it OnCellSelected?
        // BUGBUG: Does this mean we still need Command.Select?
        AddCommand (Command.Accept, () => OnCellActivated (new (Table, SelectedColumn, SelectedRow)));

And TreeView:

    /// <summary>
    ///     <para>Triggers the <see cref="ObjectActivated"/> event with the <see cref="SelectedObject"/>.</para>
    ///     <para>This method also ensures that the selected object is visible.</para>
    /// </summary>
    /// <returns><see langword="true"/> if <see cref="ObjectActivated"/> was fired.</returns>
    public bool? ActivateSelectedObjectIfAny (ICommandContext commandContext)
    {
        // By default, Command.Accept calls OnAccept, so we need to call it here to ensure that the event is fired.
        if (RaiseAccepting (commandContext) == true)
        {
            return true;
        }

        T o = SelectedObject;

        if (o is { })
        {
            // TODO: Should this be cancelable?
            ObjectActivatedEventArgs<T> e = new (this, o);
            OnObjectActivated (e);

            return true;
        }

        return false;
    }

???

[BDisp]

I think it make sense to have both. Command.Select doesn't mean it was accepted. So, adding Command.Accept will mean it was confirmed and will perform some action, like closing or opening a view, etc.... Command.Select also may perform some action but not definitely. Both must raise the respective events.

[BDisp]

@tig can a MenuBarv2 having a MenuItemv2 with an Action or is mandatory only using MenuBarItemv2?

Edit:
Or maybe more appropriate, can a MenuBarv2 having a MenuBarItemv2 with an Action?

[tig]

IIRC my intent was both
What you describe should work. But I doubt I ever tested MenuBarv2 containing a MenuItemv2.

The end user scenario is a MenuBar item that acts just like a StatusBar item.

[BDisp]

Works like a charm. Doesn't make sense to set Action in a MenuBarItemv2 because it will handle popover menus, although it's possible but the Action will be ignored. With MenuItemv2 works perfectly. Thanks.

[BDisp]

@BDisp I moved your comment to the Issue where it belongs: #4170