Skip to content
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

Windows are not blocking update of components under it #72

Closed
JD557 opened this issue Nov 13, 2023 · 0 comments
Closed

Windows are not blocking update of components under it #72

JD557 opened this issue Nov 13, 2023 · 0 comments

Comments

@JD557
Copy link
Owner

JD557 commented Nov 13, 2023

Imagine a situation like this

imagem

Even though the window calls UiContext.registerItem(id, windowArea, passive = true), this only stops the input if the window is defined first, as in:

onTop(window(...))
button(...)

However, it's much more natural to do the opposite:

button(...)
window(...)

While I think it should be possible to address the button click, the hot button is unfixable with the current model (as, by the time the window code runs, the button already decided that it's hot).

One alternative that can be explored is to delay everything by one frame, namely:

  • The UiContext keeps both the hot/active/selected state and a scratch state
  • registerItem updates the scratch state and returns the ItemStatus based on the current state
  • Before the next frame, the UiContext updates the state with the content of the scratch

It's possible that I'm missing some obvious issue with this approach, but I think with this the components would never see invalid intermediate values of InputStatus.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant