-
Notifications
You must be signed in to change notification settings - Fork 121
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
Chaos when a new window is opened during a drag operation #465
Comments
Thinking about how you'd solve this, and the difficulty of shared mutable data structures in Rust, if we don't want to introduce a global lock of some sort that needs to be taken on every event, the way to solve it might be:
It's cheap, allows all windows in the Application to share state, and requires no modifications to anything below WindowHandle in the event processing chain. |
It seems like
some of these, if made global, risk leaking dead view ids into global state where they'd never be removed, so it may be best to simply split At any rate, I'll experiment with the copy/sync approach to determine if it would even fix the problem. |
Given:
draggable()
called on itthings start to go very wrong:
It looks like the root problem here is that a distinct
AppState
is created for eachWindowHandle
- it isn't really "application state" (though it should be). So the tests of fields ofcx.app_state
inWindowHandle.event
don't get the truth of the application's state, just what one window's handler's have been able to learn about the application's state.It seems like a fix would start with
AppState
being shared in some fashion between windows and owned by theApplication
orApplicationHandle
instead of being created in isolation inWindowHandle.new()
.The text was updated successfully, but these errors were encountered: