Skip to content
This repository has been archived by the owner on Jul 15, 2024. It is now read-only.

Remove WinHandlers, and have only AppHandler #168

Open
DJMcNab opened this issue Sep 17, 2023 · 0 comments · May be fixed by #176
Open

Remove WinHandlers, and have only AppHandler #168

DJMcNab opened this issue Sep 17, 2023 · 0 comments · May be fixed by #176

Comments

@DJMcNab
Copy link
Member

DJMcNab commented Sep 17, 2023

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:

  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
  3. Impact unknown on macOS. I don't know what state the event handlers called by the platform have access to.
  4. I think, but haven't checked, that the impact on X11 is similar to Wayland
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

1 participant