Skip to content

Add global events to the InputSystemUIInputModule #1533

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 1 commit into
base: develop
Choose a base branch
from

Conversation

vrdave-unity
Copy link
Collaborator

Add global events to the InputSystemUIInputModule to allow any behavior to subscribe to UI events when not on the UI object itself.

Goal

Provide existing event functionality to the InputSystemUIInputModule so that the XRUIInputModule can be retired to further our goal of consolidation and reduction of complexity/code-duplication.

Description

This would allow any subscribers to get events before the EventSystem fires them off to the respective components. This method is currently used in the XRUIInputModule to allow non-UI based components to know when events are happening. Some components can modify/update the eventData before it gets handed off to the EventSystem. This can also be used for other tools and management scripts to trigger context-specific behaviors external to the UI system without having to apply the behavior to every button/checkbox/etc.

Changes made

Pulled event definitions from the XRUIInputModule over to InputSystemUIInputModule.
Wired up events to fire before ExecuteEvents.Execute().

Notes

This is a conceptual/informational PR and will need unit tests and documentation added to fully support this feature.

Checklist

Before review:

  • Changelog entry added.
    • Explains the change in Changed, Fixed, Added sections.
    • For API change contains an example snippet and/or migration example.
    • FogBugz ticket attached, example ([case %number%](https://issuetracker.unity3d.com/issues/...)).
    • FogBugz is marked as "Resolved" with next release version correctly set.
  • Tests added/changed, if applicable.
    • Functional tests Area_CanDoX, Area_CanDoX_EvenIfYIsTheCase, Area_WhenIDoX_AndYHappens_ThisIsTheResult.
    • Performance tests.
    • Integration tests.
  • Docs for new/changed API's.
    • Xmldoc cross references are set correctly.
    • Added explanation how the API works.
    • Usage code examples added.
    • The manual is updated, if needed.

During merge:

  • Commit message for squash-merge is prefixed with one of the list:
    • NEW: ___.
    • FIX: ___.
    • DOCS: ___.
    • CHANGE: ___.
    • RELEASE: 1.1.0-preview.3.

Sorry, something went wrong.

…ent to subscribe to UI events when not on the UI object itself.
@@ -387,7 +388,10 @@ private void ProcessPointerMovement(ExtendedPointerEventData eventData, GameObje
if (currentPointerTarget == null || eventData.pointerEnter == null)
{
for (var i = 0; i < eventData.hovered.Count; ++i)
{
onPointerExit?.Invoke(eventData.hovered[i], eventData);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

For all these events, would probably make sense to allow the handler to call Use to "consume" the event and prevent ExecuteEvents from being run.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You mean optionally, correct? I don't think all use-cases will want to fully 'consume' the events, plus there is no mechanism currently in place to prevent subsequent callbacks from being invoked if the prior callback 'consumed' the event.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, optionally.

onPointerExit?.Invoke(eventData.hovered[i], eventData);
if (!eventData.used)
    EXecuteEvents.Execute(eventData.hovered[i], eventData, ExecuteEvents.pointerExitHandler);

@jfreire-unity jfreire-unity added the waiting-for-review The issue is scheduled to be reviewed by the Unity maintainers label Mar 3, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
waiting-for-review The issue is scheduled to be reviewed by the Unity maintainers
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants