feat: Made UIElement Key Events public

[TranquilAbyss]

PR Details

Made KeyPress Events public on UI Elements to allow for custom UI Hotkeys

Related Issue

#2515

Types of changes

• Docs change / refactoring / dependency upgrade
• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)

Checklist

This is my first PR, let me know if I am missing something.
All the UI tests passed, I am still working on getting my environment setup for other tests.

• My change requires a change to the documentation.
• I have added tests to cover my changes.
• All new and existing tests passed.
• I have built and run the editor to try this change out.

[TranquilAbyss]

@dotnet-policy-service agree

[Eideren]

Sorry for the late reply, completely missed this one somehow, this change kind of makes sense but I think the idea was that those events would be explicitly implemented on components were it make sense, for example, if you need to listen for text input, you can use EditText.TextChanged, there's also the text filter if you are listening for input specifically to ensure no invalid characters are entered.
I have not checked that element which do not contain editable text receive Key* events, if they do not, making them public may be counter intuitive.
Do you have a case were you need those events specifically instead of the specialized ones under the different component types ?

[TranquilAbyss]

I may not answer you with a specific use case directly, right away but let me explain my use case.

The currently UIElement focus functionality is hidden to Stride game developers, and the events the Edit text use implement Key Down on element currently focused. The feature this is directly blocking for me is Send Chat message on Enter pressed, currently using a button for now but that wont work in the game due to taking too long to press.

Future features low priority feature include, tab order manager between UI controls. Other features for Edit Text on focus include, Select all (Ctrl + A), hold down backspace, shift to select and arrows to characters, and a few more of nice to have keys for moving around the text. It seem like a lot of effort to add all this through Stride directly rather than allowing the stride Developers to customize the UI as needed. I can understand protecting the intent of the project though.

Eventually, in another PR, I would want access to the currently focused UIElement, I have a crazy workaround I am using just to keep track of which EditText is selected. But that is not high priority for me since I have the workaround.

[Eideren]

@TranquilAbyss That actually makes sense, and given that the other events are public I'll merge this in.

Just in case here's the workaround I'm using to detect when the ui is hovered/selected, we definitely could do with something more straightforward though, yeah !

var uiProcessor = Entity.EntityManager.GetProcessor<UIRenderProcessor>();
bool uiHasFocus = false;
foreach (var uiElement in uiProcessor.UIRoots)
{
    if (uiElement.Page == null)
        continue;
    
    uiHasFocus |= uiElement.LastMouseOverElement is not null;
    uiHasFocus |= uiElement.Page.RootElement.FindVisualChildrenOfType<EditText>().Any(txt => txt.IsSelectionActive);
}