-
Notifications
You must be signed in to change notification settings - Fork 15.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Refactor NativeWindow (Part 12): Do not use custom content view on macOS #12787
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What's the path (if any) to removing all the #if defined(TOOLKIT_VIEWS)
scattered around the place?
cl, @selector(setFrameSize:), (IMP)SetFrameSize, "v@:{_NSSize=ff}"); | ||
original_view_did_move_to_superview = | ||
class_replaceMethod(cl, @selector(viewDidMoveToSuperview), | ||
(IMP)ViewDidMoveToSuperview, "v@:"); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
is this sort of messing about with the innards of Cocoa allowed in Mac App Store apps?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There are a few uses of class_addMethod
in Chromium, Apple seems to be cool about these uses.
I'll probably replace |
The views framework relies on NSWindow to return content size of window, since we don't use the borderless window, the original result would include titlebar. We have to override the function to return correct result for frameless window.
Remove our custom content view on macOS, and rely on
views::Widget
to provide everything needed for layout.This PR would allow us to display arbitrary
views::View
on macOS.