-
Notifications
You must be signed in to change notification settings - Fork 25
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
Add OnPress
callbacks
#229
Conversation
I also want some feedback from @alice-i-cecile before merging since this is an alternative to her suggestion |
I like |
Note that a possible extension of this could be an API like |
IMO this is more likely to end up using observers, but this is fine until we get a first party solution. |
@alice-i-cecile do you mean by that that a player will end up changing it to observers or that a first party solution will use observers? I assume the latter. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
IMO on_credits
etc. names should instead be named based on the action they perform, like enter_credits
or exit
.
Co-authored-by: Ben Frankel <[email protected]>
Co-authored-by: Ben Frankel <[email protected]>
Part of #203
Pattern taken from @Freyja-moth. Thanks Freyja!
Alternative to the following:
Relevant discussion.
The TL;DR is that registering a similar
OnPress<T: Event>(pub T)
, which would be need to trigger observers on presses, would require you to register yourT
in your menu in order to register the actual generic system for yourT
. Which seems like a weird extra abstraction to add and a potential source of errors, same a when a user forgets to doadd_event
forEventReader
s andEventWriter
s.That, or you setup your logic for triggering observers on presses separately for every menu, which seems like a lot of boilerplate for something as trivial as pressing on a button.
Additionally, adding observer structs introduces additional indirection where none is needed.
The ugly reflection stuff is due to bevyengine/bevy#14496.
The need for one-shot systems to be registered at the top of the function will be gone after #223