In https://github.com/linebender/druid/issues/1945, it was proposed to move druid-shell to a model where there are "no" window specific handlers. This has a few advantages:
1) In state management: the application no longer needs to store all their state in Mutexes to share state between windows.
2) Where APIs live can be re-evaluated. For example, creating a timer isn't a Window specific concern
3) 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
4) 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:
1) This is an improvement for Wayland, as the dispatch model means the backend already has access to all the state
2) Impact unknown on Windows. I think events are sent "globally", so this should have no negative impact
2) Impact unknown on macOS. I don't know what state the event handlers called by the platform have access to.
3) I think, but haven't checked, that the impact on X11 is similar to Wayland
In https://github.com/linebender/druid/issues/1945, it was proposed to move druid-shell to a model where there are "no" window specific handlers. This has a few advantages: 1) In state management: the application no longer needs to store all their state in
Mutexes to share state between windows. 2) Where APIs live can be re-evaluated. For example, creating a timer isn't a Window specific concern 3) We could removeCloneforApplicationandWindow, as there would be no need for the application to hold multiple of these. This is especially interesting forApplication4) We no longer need theWinHandler::connectmethod (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: 1) This is an improvement for Wayland, as the dispatch model means the backend already has access to all the state 2) Impact unknown on Windows. I think events are sent "globally", so this should have no negative impact 2) Impact unknown on macOS. I don't know what state the event handlers called by the platform have access to. 3) I think, but haven't checked, that the impact on X11 is similar to Wayland