[Feature] FocusTracker: Handle RootScrollViewer has focus and window unfocused better

[Marv51]

Describe the problem this feature would solve

Focus in UWP/WinUI is a not exactly trivial problem, I guess that's why FocusTracker was added in the first place.

This is what the FocusTracker looks like if the RootScrollViewer has focus:

Name:
Type:                            ScrollViewer
Automation.Name:
Parent with Name:
               FocusTracker

It is hard to understand what is going on in this case, because this ScrollViewer is not visible and not added by the users XAML.

In the case that the window is unfocused or the FocusTracker is not active the four fields are simply empty. It would be better to add some information describing why no information is displayed.

Describe the solution

Different solutions for these common focus cases are possible.

Ideas:

1. A status text could be added after the FocusTracker caption:
   • FocusTracker (inactive)
   • FocusTracker (Window unfocused)
   • FocusTracker (RootScrollViewer focused)
2. A new status line could be added with the same status as above.
3. The type or name rows could be used, when the RootScrollViewer is selected show that and show [Window unfocused] or [FocusTracker deactivated] in the other cases.

If this is a feature that would be interesting for the toolkit, I could try to implement this.

[ghost]

Hello, 'Marv51! Thanks for submitting a new feature request. I've automatically added a vote 👍 reaction to help get things started. Other community members can vote to help us prioritize this feature in the future!

[Kyaa-dost]

Thanks, @Marv51 for the initiative! @michael-hawker what do you think about more explicitly describing the fields?

[michael-hawker]

Thanks for the issue @Marv51, FocusTracker is a pretty naïve helper at the moment just calling to ask about what has focus. If you think there can be some light-heuristics to add on top of it, feel free to continue the discussion here with suggestions.

I'm not sure how the window focus stuff will work with WinUI 3 in the future, so I'd just want to make sure we're thinking ahead with any extra logic we add to the control. FYI @azchohfi

[azchohfi]

There is no difference in the APIs being used for UWP vs WinUI3 in this control. It is all just events that the Xaml framework automatically fires. The biggest difference was that in the past, before XamlRoot, we used the FocusManager.GetFocusedElement() method, and now we use the XamlRoot version, but that was/is already the case if the UWP APIs reports that there is a XamlRoot. Any change here would just work for WinUI3, so I'm not worried.

[michael-hawker]

@azchohfi I was thinking more for the focus of the application itself as @Marv51 calls out as a potential improvement, like (Window unfocused).

[michael-hawker]

@Marv51 is this something you still wanted to try and contribute to the Toolkit? If so, feel free to check out our wiki with intro on getting started with contributions, and let us know if you run into troubles. Thanks!