2022-05-10 10:06:48 +00:00
|
|
|
// Copyright (C) 2016 The Qt Company Ltd.
|
2024-02-02 13:36:10 +00:00
|
|
|
// SPDX-License-Identifier: LicenseRef-Qt-Commercial OR GPL-3.0-only
|
2011-12-06 11:59:21 +00:00
|
|
|
|
2015-01-27 13:13:39 +00:00
|
|
|
#include "rasterwindow.h"
|
2011-12-06 11:59:21 +00:00
|
|
|
|
2015-01-27 13:13:39 +00:00
|
|
|
#include <QtGui>
|
2011-12-06 11:59:21 +00:00
|
|
|
#include <QtWidgets/QtWidgets>
|
|
|
|
|
2015-08-26 08:48:34 +00:00
|
|
|
#include <AppKit/AppKit.h>
|
2011-12-06 11:59:21 +00:00
|
|
|
|
2017-08-30 17:05:39 +00:00
|
|
|
|
|
|
|
@interface ContentView : NSView
|
|
|
|
@end
|
|
|
|
|
|
|
|
@implementation ContentView
|
|
|
|
- (void)drawRect:(NSRect)dirtyRect {
|
|
|
|
[[NSColor whiteColor] setFill];
|
|
|
|
NSRectFill(dirtyRect);
|
|
|
|
}
|
macOS: Respect responder chain when setting cursor
There's no need for us to walk our own ancestor chain to figure out which
cursor to set. AppKit will automatically call cursorUpdate: on the view
that would be the hitTest target of the current mouse position, and by
falling back to super when no cursor is set for the current view, we
automatically get the behavior that effectiveWindowCursor tried to solve.
In addition, it solves the case of applyEffectiveWindowCursor applying
the arrowCursor when no cursor was set, which would mean that if any
native parent view of our view _did_ have a cursor set, we would not
fall back to the native view's cursor, but instead override it with
the arrow cursor. Following the responder chain gives the correct
behavior in this case.
Unfortunately, due to rdar://34183708, if a subview of one of our
views uses the legacy cursorRect approach to cursor management, the
cursor will not be reset back to our cursor via cursorUpdate: when
leaving the child and entering the parent view (our view). Moving
our implementation over to the legacy API would solve this problem,
but just propagate it to native parent views of our views, which
could potentially use NSTrackingAreas, and would not have _their_
cursors re-set.
Change-Id: Id20cc03136f0b1d4b9120750fe63ddc455363aaf
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
2017-08-30 17:48:26 +00:00
|
|
|
|
|
|
|
- (void)cursorUpdate:(NSEvent *)theEvent
|
|
|
|
{
|
|
|
|
Q_UNUSED(theEvent);
|
|
|
|
[[NSCursor pointingHandCursor] set];
|
|
|
|
}
|
2017-08-30 17:05:39 +00:00
|
|
|
@end
|
|
|
|
|
2018-02-01 18:32:07 +00:00
|
|
|
@interface AppDelegate : NSObject <NSApplicationDelegate>
|
|
|
|
@end
|
|
|
|
|
|
|
|
@implementation AppDelegate {
|
2015-01-27 13:13:39 +00:00
|
|
|
QGuiApplication *m_app;
|
|
|
|
QWindow *m_window;
|
2011-12-06 11:59:21 +00:00
|
|
|
}
|
|
|
|
|
2018-02-01 18:32:07 +00:00
|
|
|
- (instancetype)initWithArgc:(int)argc argv:(const char **)argv
|
2011-12-06 11:59:21 +00:00
|
|
|
{
|
2018-02-01 18:32:07 +00:00
|
|
|
if ((self = [self init])) {
|
|
|
|
m_app = new QGuiApplication(argc, const_cast<char **>(argv));
|
|
|
|
}
|
2011-12-06 11:59:21 +00:00
|
|
|
return self;
|
|
|
|
}
|
|
|
|
|
2018-02-01 18:32:07 +00:00
|
|
|
- (void)applicationWillFinishLaunching:(NSNotification *)notification
|
2011-12-06 11:59:21 +00:00
|
|
|
{
|
2015-01-27 13:13:39 +00:00
|
|
|
Q_UNUSED(notification);
|
2011-12-06 11:59:21 +00:00
|
|
|
|
2015-01-27 13:13:39 +00:00
|
|
|
// Create the NSWindow
|
2011-12-06 11:59:21 +00:00
|
|
|
NSRect frame = NSMakeRect(500, 500, 500, 500);
|
2018-02-01 18:32:07 +00:00
|
|
|
NSWindow *window = [[NSWindow alloc] initWithContentRect:frame
|
|
|
|
styleMask:NSTitledWindowMask | NSClosableWindowMask | NSMiniaturizableWindowMask | NSResizableWindowMask
|
2011-12-06 11:59:21 +00:00
|
|
|
backing:NSBackingStoreBuffered
|
|
|
|
defer:NO];
|
|
|
|
|
|
|
|
NSString *title = @"This the NSWindow window";
|
|
|
|
[window setTitle:title];
|
|
|
|
[window setBackgroundColor:[NSColor blueColor]];
|
|
|
|
|
macOS: Respect responder chain when setting cursor
There's no need for us to walk our own ancestor chain to figure out which
cursor to set. AppKit will automatically call cursorUpdate: on the view
that would be the hitTest target of the current mouse position, and by
falling back to super when no cursor is set for the current view, we
automatically get the behavior that effectiveWindowCursor tried to solve.
In addition, it solves the case of applyEffectiveWindowCursor applying
the arrowCursor when no cursor was set, which would mean that if any
native parent view of our view _did_ have a cursor set, we would not
fall back to the native view's cursor, but instead override it with
the arrow cursor. Following the responder chain gives the correct
behavior in this case.
Unfortunately, due to rdar://34183708, if a subview of one of our
views uses the legacy cursorRect approach to cursor management, the
cursor will not be reset back to our cursor via cursorUpdate: when
leaving the child and entering the parent view (our view). Moving
our implementation over to the legacy API would solve this problem,
but just propagate it to native parent views of our views, which
could potentially use NSTrackingAreas, and would not have _their_
cursors re-set.
Change-Id: Id20cc03136f0b1d4b9120750fe63ddc455363aaf
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
2017-08-30 17:48:26 +00:00
|
|
|
NSView *contentView = [[[ContentView alloc] initWithFrame:frame] autorelease];
|
|
|
|
[contentView addTrackingArea:[[NSTrackingArea alloc] initWithRect:[contentView frame]
|
|
|
|
options:NSTrackingActiveInActiveApp | NSTrackingInVisibleRect | NSTrackingCursorUpdate
|
|
|
|
owner:contentView userInfo:nil]];
|
|
|
|
|
2017-08-30 17:05:39 +00:00
|
|
|
// Create the QWindow, add its NSView to the content view
|
|
|
|
m_window = new RasterWindow;
|
|
|
|
m_window->setObjectName("RasterWindow");
|
macOS: Respect responder chain when setting cursor
There's no need for us to walk our own ancestor chain to figure out which
cursor to set. AppKit will automatically call cursorUpdate: on the view
that would be the hitTest target of the current mouse position, and by
falling back to super when no cursor is set for the current view, we
automatically get the behavior that effectiveWindowCursor tried to solve.
In addition, it solves the case of applyEffectiveWindowCursor applying
the arrowCursor when no cursor was set, which would mean that if any
native parent view of our view _did_ have a cursor set, we would not
fall back to the native view's cursor, but instead override it with
the arrow cursor. Following the responder chain gives the correct
behavior in this case.
Unfortunately, due to rdar://34183708, if a subview of one of our
views uses the legacy cursorRect approach to cursor management, the
cursor will not be reset back to our cursor via cursorUpdate: when
leaving the child and entering the parent view (our view). Moving
our implementation over to the legacy API would solve this problem,
but just propagate it to native parent views of our views, which
could potentially use NSTrackingAreas, and would not have _their_
cursors re-set.
Change-Id: Id20cc03136f0b1d4b9120750fe63ddc455363aaf
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
2017-08-30 17:48:26 +00:00
|
|
|
m_window->setCursor(Qt::CrossCursor);
|
2017-08-30 17:05:39 +00:00
|
|
|
m_window->setGeometry(QRect(0, 0, 300, 300));
|
|
|
|
|
|
|
|
QWindow *childWindow = new RasterWindow;
|
|
|
|
childWindow->setObjectName("RasterWindowChild");
|
|
|
|
childWindow->setParent(m_window);
|
macOS: Respect responder chain when setting cursor
There's no need for us to walk our own ancestor chain to figure out which
cursor to set. AppKit will automatically call cursorUpdate: on the view
that would be the hitTest target of the current mouse position, and by
falling back to super when no cursor is set for the current view, we
automatically get the behavior that effectiveWindowCursor tried to solve.
In addition, it solves the case of applyEffectiveWindowCursor applying
the arrowCursor when no cursor was set, which would mean that if any
native parent view of our view _did_ have a cursor set, we would not
fall back to the native view's cursor, but instead override it with
the arrow cursor. Following the responder chain gives the correct
behavior in this case.
Unfortunately, due to rdar://34183708, if a subview of one of our
views uses the legacy cursorRect approach to cursor management, the
cursor will not be reset back to our cursor via cursorUpdate: when
leaving the child and entering the parent view (our view). Moving
our implementation over to the legacy API would solve this problem,
but just propagate it to native parent views of our views, which
could potentially use NSTrackingAreas, and would not have _their_
cursors re-set.
Change-Id: Id20cc03136f0b1d4b9120750fe63ddc455363aaf
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
2017-08-30 17:48:26 +00:00
|
|
|
childWindow->setCursor(Qt::BusyCursor);
|
2017-08-30 17:05:39 +00:00
|
|
|
childWindow->setGeometry(50, 50, 100, 100);
|
|
|
|
|
macOS: Respect responder chain when setting cursor
There's no need for us to walk our own ancestor chain to figure out which
cursor to set. AppKit will automatically call cursorUpdate: on the view
that would be the hitTest target of the current mouse position, and by
falling back to super when no cursor is set for the current view, we
automatically get the behavior that effectiveWindowCursor tried to solve.
In addition, it solves the case of applyEffectiveWindowCursor applying
the arrowCursor when no cursor was set, which would mean that if any
native parent view of our view _did_ have a cursor set, we would not
fall back to the native view's cursor, but instead override it with
the arrow cursor. Following the responder chain gives the correct
behavior in this case.
Unfortunately, due to rdar://34183708, if a subview of one of our
views uses the legacy cursorRect approach to cursor management, the
cursor will not be reset back to our cursor via cursorUpdate: when
leaving the child and entering the parent view (our view). Moving
our implementation over to the legacy API would solve this problem,
but just propagate it to native parent views of our views, which
could potentially use NSTrackingAreas, and would not have _their_
cursors re-set.
Change-Id: Id20cc03136f0b1d4b9120750fe63ddc455363aaf
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
2017-08-30 17:48:26 +00:00
|
|
|
NSTextField *textField = [[NSTextField alloc] initWithFrame:NSMakeRect(10, 10, 80, 25)];
|
2018-02-01 18:32:07 +00:00
|
|
|
[reinterpret_cast<NSView *>(childWindow->winId()) addSubview:textField];
|
macOS: Respect responder chain when setting cursor
There's no need for us to walk our own ancestor chain to figure out which
cursor to set. AppKit will automatically call cursorUpdate: on the view
that would be the hitTest target of the current mouse position, and by
falling back to super when no cursor is set for the current view, we
automatically get the behavior that effectiveWindowCursor tried to solve.
In addition, it solves the case of applyEffectiveWindowCursor applying
the arrowCursor when no cursor was set, which would mean that if any
native parent view of our view _did_ have a cursor set, we would not
fall back to the native view's cursor, but instead override it with
the arrow cursor. Following the responder chain gives the correct
behavior in this case.
Unfortunately, due to rdar://34183708, if a subview of one of our
views uses the legacy cursorRect approach to cursor management, the
cursor will not be reset back to our cursor via cursorUpdate: when
leaving the child and entering the parent view (our view). Moving
our implementation over to the legacy API would solve this problem,
but just propagate it to native parent views of our views, which
could potentially use NSTrackingAreas, and would not have _their_
cursors re-set.
Change-Id: Id20cc03136f0b1d4b9120750fe63ddc455363aaf
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
2017-08-30 17:48:26 +00:00
|
|
|
|
2017-09-11 12:04:51 +00:00
|
|
|
[contentView addSubview:reinterpret_cast<NSView *>(m_window->winId())];
|
|
|
|
|
|
|
|
window.contentView = contentView;
|
2015-01-27 13:13:39 +00:00
|
|
|
|
2017-09-11 12:04:51 +00:00
|
|
|
// Show the NSWindow delayed, so that we can verify that Qt picks up the right
|
|
|
|
// notifications to expose the window when it does become visible.
|
|
|
|
dispatch_async(dispatch_get_main_queue(), ^{
|
|
|
|
[window makeKeyAndOrderFront:NSApp];
|
|
|
|
});
|
2011-12-06 11:59:21 +00:00
|
|
|
}
|
|
|
|
|
2015-01-27 13:13:39 +00:00
|
|
|
- (void)applicationWillTerminate:(NSNotification *)notification
|
2011-12-06 11:59:21 +00:00
|
|
|
{
|
2015-01-27 13:13:39 +00:00
|
|
|
Q_UNUSED(notification);
|
|
|
|
delete m_window;
|
|
|
|
delete m_app;
|
|
|
|
}
|
2011-12-06 11:59:21 +00:00
|
|
|
|
2015-01-27 13:13:39 +00:00
|
|
|
@end
|
2011-12-06 11:59:21 +00:00
|
|
|
|
2015-01-27 13:13:39 +00:00
|
|
|
int main(int argc, const char *argv[])
|
|
|
|
{
|
|
|
|
// Create NSApplicaiton with delgate
|
2018-02-01 18:32:07 +00:00
|
|
|
NSApplication *app = [NSApplication sharedApplication];
|
2015-01-27 13:13:39 +00:00
|
|
|
app.delegate = [[AppDelegate alloc] initWithArgc:argc argv:argv];
|
2018-02-01 18:32:07 +00:00
|
|
|
return NSApplicationMain(argc, argv);
|
2011-12-06 11:59:21 +00:00
|
|
|
}
|