Regression: Focus scope API no longer accessible

Describe the bug The focus scope API (FocusManager.Scope, FocusManager.GetFocusedElement(IFocusScope)) is no longer accessible as of #11407, which is breaking our app/UI libraries.

Our current app implements ToolBars, RoutedCommands (similar to WPF), a “Quick Launch Box”/“Command palette” and docking windows (like Visual Studio). The application depends on focus scopes. Details:

• Windows, Menus, ToolBarTrays and the “Quick Launch Box” implement IFocusScope.
• The Avalonia FocusManager keeps track of the last focused element in each focus scope.
• Common commands (Cut, Copy, Paste, etc.) are implemented as RoutedCommands. Similar to WPF’s ApplicationCommands.
• When a command in Menu, ToolBar, or “Quick Launch Box” is triggered it needs to be routed to the previously focused element. This is done by determining the current focus scope (FocusManager.Scope), finding the parent focus scope, and routing the event to the last focused element (FocusManager.GetFocusedElement(IFocusScope)).
• After the command is executed the toolbar item or “Quick Launch Box” needs to give up the focus and move it back to the previously focused element.

To Reproduce Third-party apps or UI control libraries can no longer access FocusManager. The focus scope API is not exposed in IFocusManager.

Expected behavior Third-party apps or UI control libraries should have a way to access focus scopes.

Solution This can be solved by pulling the following members from FocusManager into IFocusManager:

/// <summary>
/// Gets the current focus scope.
/// </summary>
IFocusScope? Scope { get; }

/// <summary>
/// Gets the currently focused element in the given focus scope.
/// </summary>
public IInputElement? GetFocusedElement(IFocusScope scope);

Focus scopes are an important concept needed for command routing in complex scenarios and for porting WPF applications to Avalonia UI. I strongly recommend keeping the functionality and not removing it as part of any future changes (e.g. #7607).

Screenshots n.a.

Desktop (please complete the following information):

• OS: Windows
• Version 11.0.0-rc1.1

Additional context n.a.

[kekekeks]

IIRC there were hard to resolve issues with the way focus scopes are implemented. There are some plans to have a full WPF-like implementation, but no ETA yet.

[maxkatz6]

Either way, it doesn’t sound like something that can’t be done with existing API without making it more complex:

• it’s possible to get the currently focused element
• it’s possible to track focus movements globally, i.e. static GotFocus.Raised.Subscribe()

But I might be missing something as well.