macOS: Refactor NSView subclass implementation#262
Open
prokopyl wants to merge 14 commits into
Open
Conversation
4d7a9cb to
0bc5754
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
This PR introduces a safe wrapper around the AppKit
NSViewcreation and lifecycle.While a large part of
objc2's API surface is safe, managing our custom-class' instance variables is not. And because our custom class is dynamically generated, there is no check for correctness of the subclass' methods signatures.These two parts are what this wrapper handles, the rest is delegated to
objc2's existing APIs.This PR also introduces safe wrappers around the
NSView's timer and notification observers, making them correctly de-register themselves when theNSViewis deallocated, while not holding theNSViewitself alive for too long.This PR also completely overhauls the
NSViewownership structure. It previously had a clunkyWindowInner > NSView > WindowState > WindowInner > NSViewownership cycle that had to be manually broken.Now the
NSViewproperly and directly owns all of its internal state and object, except for the tiny bit ofWindowSharedStatethat's needed by theWindowHandle(and now doesn't reference theNSViewat all anymore).Doing this also allowed to properly initialize the
WindowHandleronly after theNSViewwas fully initialized and parented, fixing #248.