2011-12-06 11:59:21 +00:00
|
|
|
/****************************************************************************
|
|
|
|
**
|
2016-01-15 12:36:27 +00:00
|
|
|
** Copyright (C) 2016 The Qt Company Ltd.
|
|
|
|
** Contact: https://www.qt.io/licensing/
|
2011-12-06 11:59:21 +00:00
|
|
|
**
|
|
|
|
** This file is part of the test suite of the Qt Toolkit.
|
|
|
|
**
|
2016-01-15 12:36:27 +00:00
|
|
|
** $QT_BEGIN_LICENSE:GPL-EXCEPT$
|
2012-09-19 12:28:29 +00:00
|
|
|
** Commercial License Usage
|
|
|
|
** Licensees holding valid commercial Qt licenses may use this file in
|
|
|
|
** accordance with the commercial license agreement provided with the
|
|
|
|
** Software or, alternatively, in accordance with the terms contained in
|
2015-01-28 08:44:43 +00:00
|
|
|
** a written agreement between you and The Qt Company. For licensing terms
|
2016-01-15 12:36:27 +00:00
|
|
|
** and conditions see https://www.qt.io/terms-conditions. For further
|
|
|
|
** information use the contact form at https://www.qt.io/contact-us.
|
2012-09-19 12:28:29 +00:00
|
|
|
**
|
2016-01-15 12:36:27 +00:00
|
|
|
** GNU General Public License Usage
|
|
|
|
** Alternatively, this file may be used under the terms of the GNU
|
|
|
|
** General Public License version 3 as published by the Free Software
|
|
|
|
** Foundation with exceptions as appearing in the file LICENSE.GPL3-EXCEPT
|
|
|
|
** included in the packaging of this file. Please review the following
|
|
|
|
** information to ensure the GNU General Public License requirements will
|
|
|
|
** be met: https://www.gnu.org/licenses/gpl-3.0.html.
|
2011-12-06 11:59:21 +00:00
|
|
|
**
|
|
|
|
** $QT_END_LICENSE$
|
|
|
|
**
|
|
|
|
****************************************************************************/
|
|
|
|
|
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
|
|
|
}
|