You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Jul 15, 2024. It is now read-only.
In linebender/druid#1945, it was proposed to move druid-shell to a model where there are "no" window specific handlers. This has a few advantages:
In state management: the application no longer needs to store all their state in Mutexes to share state between windows.
Where APIs live can be re-evaluated. For example, creating a timer isn't a Window specific concern
We could remove Clone for Application and Window, as there would be no need for the application to hold multiple of these. This is especially interesting for Application
We no longer need the WinHandler::connect method (although we do need to be careful with timings around when the window handle is ready to be drawn into)
This has also been discussed in office hours, and I don't believe any concern were raised then.
This will be quite a significant task - however, a transitional API can be created, such that backends can continue to use the old system.
I propose that we don't do the same the other way, as the only current users of Glazier are our own examples and Xilem
Some backend specific consideration:
This is an improvement for Wayland, as the dispatch model means the backend already has access to all the state
Impact unknown on Windows. I think events are sent "globally", so this should have no negative impact
Impact unknown on macOS. I don't know what state the event handlers called by the platform have access to.
I think, but haven't checked, that the impact on X11 is similar to Wayland
The text was updated successfully, but these errors were encountered:
In linebender/druid#1945, it was proposed to move druid-shell to a model where there are "no" window specific handlers. This has a few advantages:
Mutex
es to share state between windows.Clone
forApplication
andWindow
, as there would be no need for the application to hold multiple of these. This is especially interesting forApplication
WinHandler::connect
method (although we do need to be careful with timings around when the window handle is ready to be drawn into)This has also been discussed in office hours, and I don't believe any concern were raised then.
This will be quite a significant task - however, a transitional API can be created, such that backends can continue to use the old system.
I propose that we don't do the same the other way, as the only current users of Glazier are our own examples and Xilem
Some backend specific consideration:
The text was updated successfully, but these errors were encountered: