Implements a new API/implementation for Glazier, in a parallel v2 folder
Resolves #44
Resolves #168
Also incidentally:
Fixes #23
Fixes #78
Fixes #95
This is a massive refactor, but I think it makes things much cleaner. There are a few key differences:
1) There is only one[^1] handler trait you need to implement, which is PlatformHandler
2) Each method on this PlatformHandler is passed a Glazier, which is the root of all interaction with the platform
3) There are no more individual handles to each Window and the application hanging around, instead things are referred to with just Ids (e.g. WindowId)[^2]
This massively reduces the number of locks/sharing required both:
1) Between multiple WindowHandlers and the AppHandler
2) Between the different window handles and the state of the application
Indeed, as an example, the type of the Glazier on the Wayland backend is an exclusive reference to the entire state of the backend, except for only the user's handler.
Progress:
[x] Design the shape of the API
[ ] Implement this API to the smallest possible form to get working behaviour on Wayland
[ ] Port a selection of examples
[ ] Implement more features of the backend
[ ] Merge this PR
Steps after that:
[ ] Bring to other backends
[ ] Windows
[ ] mac
[ ] x11
[ ] (Web?)
[ ] Ensure all documentation is correct
[ ] Port remaining examples
[ ] Remove the old integrations, and move the new V2 as the source folder
[^1]: The design for text fields is as-yet unclear, whether these are also included in PlatformHandler (which intuitively is my preference)
[^2]: There will still be ways to access raw-window-handles, exact API to be determined
Implements a new API/implementation for Glazier, in a parallel
v2
folderResolves #44 Resolves #168
Also incidentally: Fixes #23 Fixes #78 Fixes #95
This is a massive refactor, but I think it makes things much cleaner. There are a few key differences:
1) There is only one[^1] handler trait you need to implement, which is
PlatformHandler
2) Each method on thisPlatformHandler
is passed aGlazier
, which is the root of all interaction with the platform 3) There are no more individual handles to each Window and the application hanging around, instead things are referred to with just Ids (e.g.WindowId
)[^2]This massively reduces the number of locks/sharing required both: 1) Between multiple
WindowHandler
s and theAppHandler
2) Between the different window handles and the state of the applicationIndeed, as an example, the type of the
Glazier
on the Wayland backend is an exclusive reference to the entire state of the backend, except for only the user's handler.Progress:
Steps after that:
[^1]: The design for text fields is as-yet unclear, whether these are also included in
PlatformHandler
(which intuitively is my preference) [^2]: There will still be ways to access raw-window-handles, exact API to be determined