Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
X11 HiDPI will be finished soon, I promise! I'm actually very nearly done with it, but some internal design issues in the X11 backend were actively complicating my work. So, this is yet another refactor PR.
Before this PR:
Window
owns aWindow2
, which contains all the actual methods and additionally owns anXWindow
.Window2
ownsSharedState
, which is shared withEventsLoop
viaRefCell<HashMap<WindowId, Weak<Mutex<window::SharedState>>>>
.EventsLoop
sharesArc<Mutex<HashMap<WindowId, WindowData>>>
withWindow
, but not withWindow2
.Window
has it so it can remove itself from it indrop
, andEventsLoop
uses it to store various state related to the window. Nested inWindowData
isWindowConfig
.Window2
fromEventsLoop
.So, to recap, there are 3 window types (
Window
,Window2
, andXWindow
) and 3 window state types (WindowData
,WindowConfig
, andSharedState
). Chances are, what you want to access isn't going to be where you need it to be. For instance, that's why I didn't work on #242 for the 0.15.0 release, since it would've involved some tedious state coordination and function duplication.After this PR:
XWindow
has been flattened intoWindow2
, andWindow2
has been renamed toUnownedWindow
. This name represents the fact thatUnownedWindow
is just a bundle of state that's used for calling methods, and not a managed resource.Window
owns anUnownedWindow
, and cleans up after it.WindowConfig
has been flattened intoWindowData
, andWindowData
has been flattened intoSharedState
!EventsLoop
has access to everyUnownedWindow
viaRefCell<HashMap<WindowId, Weak<UnownedWindow>>>
. This makes it possible to callUnownedWindow
methods.EventsLoop::with_window
makes it much more ergonomic to operate on windows.Before:
After:
with_window
can also return anyOption<T>
you want it to, so it generally can do what you need it to without you having to think about it.There are still some gotchas, i.e.
Even with that proviso, this design is much easier to work with than the existing one.