summaryrefslogtreecommitdiffstats
path: root/src/plugins/platforms/cocoa/qcocoawindow.mm
Commit message (Collapse)AuthorAgeFilesLines
* macOS: Deduplicate QNSWindow/QNSPanel codeTor Arne Vestbø2017-08-241-2/+25
| | | | | | | | | | | | | | | | | | | | | | By sharing the implementations of the methods between QNSWindow and QNSPanel we don't need a helper, and can remove duplicated code. This duplication would expand in the future, as for each method added to the QNSWindowProtocol, we would have to add forwarding functions in both QNSWindow and QNSPanel, forwarding to QNSWindowHelper, and then two more functions in QNSWindow and QNSPanel in case we wanted to call super from the helper, similar to [QNSWindow superSendEvent]. The only snag is that calls to super are hard-coded to a specific superclass during complication, so we provide our wrapper for objc_msgSendSuper that resolves the superclass at runtime. The helper class QSendSuperHelper provides compile time implicit instantiation of the right template without having to provide the return type as a template argument, via operator T and a fallback for the case of no return type via the destructor. Change-Id: Iaf13f27675d90f884470f5005270ea0d9d0316f3 Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
* macOS: Simplify and correct style mask determinationMorten Johan Sørvig2017-08-221-43/+22
| | | | | | | | | | | | | | | | | | | | | | | | | | | | This function had accumulated a fair bit of accidental complexity over the years. - No early returns, make sure to preserve fullscreen state for all windows. - Use windowIsPopupType() directly to set borderless for Qt::Popup (but not Qt::Tool). - Handle Qt::Tool explicitly. - Deduplicate Qt::CustomizeWindowMask handling. - Remove case that used the absence of NSResizableWindowMask to remove the maximize button. Maximize is now disabled elsewhere (setWindowZoomButton). All windows now get NSResizableWindowMask by default. - Qt::ForeignWindow now gets a standard window style mask instead of NSBorderlessWindowMask. The old code did not handle this case and left the mask value unmodified. Change-Id: I56499e9f05c3f481b5a96e0507da2fb195f207fa Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
* Revert "macOS: Create NSView as initially hidden, to match QWindow behavior"Shawn Rutledge2017-08-181-9/+8
| | | | | | | | | | It seems to break the ability to grab an offscreen QQuickView. That in turn breaks the tst_qquickimage::hugeImages autotest. This reverts commit 096b56f336e5bb994d46f073d55496d36d38e6b1. Task-number: QTBUG-62548 Change-Id: I11ce452341bfc2cc3cbc832b613c7366049b31d5 Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
* Merge remote-tracking branch 'origin/5.9' into devLiang Qi2017-08-151-1/+10
|\ | | | | | | | | | | | | | | | | | | Conflicts: src/plugins/platforms/cocoa/qcocoamenu.h src/plugins/platforms/cocoa/qcocoamenu.mm src/plugins/platforms/cocoa/qcocoawindow.mm src/widgets/styles/qstylehelper_p.h Change-Id: I54247c98dd79d2b3826fc062b8b11048c9c7d9bb
| * macOS: Make alpha-based click-trough work againMorten Johan Sørvig2017-08-091-2/+12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Commit 3ea04c7d made it so that we always set the ignoresMouseEvent property on the NSWindow, based on the WindowTransparentForInput flag. However, this overwrites the magical secret initial state where click-trough is determined based on window content transparency - setting the property to false makes the window capture all events. Restore 5.6 behavior by not modifying ignoresMouseEvent if we can. Toggling WindowTransparentForInput on and off again is still broken. Task-number: QTBUG-54830 Change-Id: I5f44ce14d9a7dc1713f9efb1ef929e2969838d90 Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io> Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
* | macOS: Create NSView as initially hidden, to match QWindow behaviorTor Arne Vestbø2017-08-111-8/+9
| | | | | | | | | | Change-Id: I25af6635ea9b6aa3fcc642fa2da0553341aabda8 Reviewed-by: Morten Johan Sørvig <morten.sorvig@qt.io>
* | macOS: Modernize QCocoaBackingStore::flush()Tor Arne Vestbø2017-07-291-2/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | Instead of forwarding the flush to the view, using CoreGraphics to blit the backing store to the window, we do everything in flush(), and use higher level AppKit APIs to do the blit. This simplifies the flow and code quite a bit, and also supports blitting of individual regions in a flush instead of the whole bounding rect. Change-Id: I2173c1a7763fe652a94125c7e3ae93a655412cd3 Reviewed-by: Jake Petroules <jake.petroules@qt.io> Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
* | macOS: Send expose event at drawRect and trigger updates via setNeedsDisplayTor Arne Vestbø2017-07-251-85/+28
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This changes the drawing model on macOS from the following: 1. Sending synchronous expose events directly from callbacks such as windowDidOrderOnScreen and windowDidChangeOcclusionState 2. Waiting for a resulting flush of the backing store, and issuing setNeedsDisplay as a response 3. Waiting for the asynchronous drawRect call in response to setNeedsDisplay, where the backing store is finally drawn to the window To the following: 1. Issue setNeedsDisplay as a response to callbacks such as windowDidOrderOnScreen and windowDidChangeOcclusionState, when needed (in many cases this is automatic by AppKit) 2. Send synchronous expose events from the resulting drawRect callback 3. Draw the backing store to the window when flushed The new model matches how normal Cocoa application draw in response to drawRect, and makes the backing store flush synchronous instead of having to trigger a async setNeedsDisplay. This gives AppKit more information about how much time we're spending in drawRect, as the actual drawing and flushing all happens within the synchronous expose event. Qt applications that draw outside of drawRect, e.g. in response to timers, are still supported by manually locking focus of the view and flushing the window at the end of the backingstore flush. Task-number: QTBUG-50414 Change-Id: I2efb9ff8df51ab6e840ad20c497b71f53e21e1c2 Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
* | macOS: Improve QCocoaWindow logging a bitTor Arne Vestbø2017-07-181-17/+19
| | | | | | | | | | | | Change-Id: Ic3555445b045edda884983aa01834a4ae243d6fa Reviewed-by: Morten Johan Sørvig <morten.sorvig@qt.io> Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
* | Add QPlatformWindow::initialize() for two-step window creationTor Arne Vestbø2017-07-171-15/+25
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The QWindow::create method calls createPlatformWindow, and assigns the result to d->platformWindow. If the platform sends any sort of events synchronously during the creation, the event will be delivered to a QWindow that doesn't have a handle() yet, resulting in noop handling of the event, or crashes. To mitigate this situations, platforms should do as little a possible in the QPlatformWindow constructor, and leave initialization to the new method, where the QWindow will have a handle(). The macOS platform plugin still has a m_initialized guard, to prevent sending geometry changes during initialization, as this will result in a resize event before a show event. This forced behavior seems dubious, but is left for a followup patch. Task-number: QTBUG-61977 Change-Id: I04d32d93391e89d068752b719270438e7024ad46 Reviewed-by: Morten Johan Sørvig <morten.sorvig@qt.io> Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
* | macOS: Improve QDebug output for QNSView and QCocoaWindowTor Arne Vestbø2017-07-131-0/+17
| | | | | | | | | | | | | | | | | | | | By printing the corresponding QPlatformWindow and QWindow for a given QNSView we make it easier to track issues regardless of which of the views/windows are being logged. Change-Id: I4a42eff7f87cf3c8e722cd6ad8baccd4eeab8eb3 Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io> Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
* | macOS: Deliver screen change on window creation instead of on first exposeTor Arne Vestbø2017-07-111-10/+5
| | | | | | | | | | | | | | | | We know the resulting screen based on the geometry mappings we now do, so no need to wait until expose to deliver the screen change. Change-Id: Ibb84948ab091d8f74d31cdd2d300b381e2e1e7cc Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
* | macOS: Rename NSWindow variable in QCocoaWindow::createNSWindowTor Arne Vestbø2017-07-111-11/+11
| | | | | | | | | | | | | | To distinguish it from window(). Change-Id: I90eb5207c6d9f178f009ecf755e2be8d29149a6b Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
* | macOS: Don't special-case QTestLib when reacting to occlusion eventsTor Arne Vestbø2017-07-111-12/+4
| | | | | | | | | | | | | | | | The tests (and Qt) should be able to handle occlusion of windows. Change-Id: I5e93e032f6a5282f19a20d0e230863d2a165f4e3 Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
* | macOS: Use same naming for QPA event forwarding functionsTor Arne Vestbø2017-07-091-20/+20
| | | | | | | | | | | | | | Expose events and others will follow. Change-Id: I8e11a133381a678517b54ad1872fe302515d4104 Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
* | macOS: Simplify QCocoaWindow::handleGeometryChangeMorten Johan Sørvig2017-07-091-10/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | There are really only two cases here, where the difference is the coordinate system of the window position. 1) Child QWindow and embedded QWindow: The position is relative to parent view/window origin. 2) Top-level QWindow: The position is relative to screen origin. Change-Id: I867133a5adbbf3a690f574aec06b70c2bc64ad95 Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io> Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
* | macOS: Move geometry reporting from QNSView to QCocoaWindowTor Arne Vestbø2017-07-081-4/+53
| | | | | | | | | | | | | | | | | | | | | | There's no longer any reason to call out from QCocoaWindow to QNView for this, as the geometry events from AppKit are delivered directly to the QCocoaWindow. Most of the data used in the implementation are coming from QCocoaWindow anyways, and this enables geometry events for foreign windows in the future. Change-Id: Idd724d078e9981304dcbe6742b9ddc71640a2350 Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
* | Relieve platform plugins of having to persist geometry on WM callbacksTor Arne Vestbø2017-07-071-5/+2
| | | | | | | | | | | | | | | | | | We can offload this to QGuiApplication, just like the geometry of the QWindow is set. This ensures that all platforms behave the same, and that the documentation of QPlatformWindow::setGeometry is adhered. Change-Id: I19dbc32cb4fb146d716ec289c28030a547d3afaa Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
* | Remove requirement to call QWindow::setMask after creating windowTor Arne Vestbø2017-06-281-1/+4
| | | | | | | | | | | | | | | | | | | | | | Like other QWindow properties we can just store it, and the platform window should pick it up on creation like other properties. [ChangeLog][QtGui][QWindow] setMask() no longer requires the window to be created to have an effect; it can be set at any time. Change-Id: I55b616363801b770bd61bda5325b443013b99866 Reviewed-by: Gatis Paeglis <gatis.paeglis@qt.io>
* | macOS: Allow maximizing utility windowsTor Arne Vestbø2017-06-271-3/+3
| | | | | | | | | | | | | | | | | | They have a native maximize/zoom button in their titlebar, so there's no reason for us to prevent the same action via the API. The only states that are prevented are minimized and fullscreen. Change-Id: I84fa48b31b243fa838c90ecdeee92a2f3448ee14 Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
* | macOS: Merge QCocoaWindow::setWindowShadow into its only callerTor Arne Vestbø2017-06-261-10/+3
| | | | | | | | | | Change-Id: I14149231d12658c59e3f9f87f2943ccdfbea4d43 Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
* | macOS: Simplify recreateWindowIfNeeded debug outputTor Arne Vestbø2017-06-241-7/+3
| | | | | | | | | | Change-Id: I0e12502de544f79636ec1a67b87bc856ddfc6675 Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
* | macOS: Remove support for child NSWindowsTor Arne Vestbø2017-06-211-280/+32
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The private feature was only used by QToolBar to solve QTBUG-33082, but the solution doesn't work, and complicates the macOS platform plugin quite a bit. A better solution is likely to use Core Animation layers, which is a direction we're going in anyways. To make it easier to modernize the macOS platform plugin, including moving to using layers, we remove the child NSWindows codepaths for now. Change-Id: I4b19464be3980fd84dd7af8316d4d5e85ba813b1 Reviewed-by: Morten Johan Sørvig <morten.sorvig@qt.io> Reviewed-by: Gabriel de Dietrich <gabriel.dedietrich@qt.io>
* | macOS: Move QNSWindow implementation into separate fileTor Arne Vestbø2017-06-211-383/+1
| | | | | | | | | | Change-Id: Ie75419c7ffb7a8fdf78d53e1ea14afee63ef1656 Reviewed-by: Morten Johan Sørvig <morten.sorvig@qt.io>
* | Merge remote-tracking branch 'origin/5.9' into devLiang Qi2017-05-291-4/+92
|\| | | | | | | | | | | | | | | | | | | | | | | | | Conflicts: .qmake.conf mkspecs/common/msvc-desktop.conf mkspecs/win32-g++/qmake.conf mkspecs/win32-icc/qmake.conf src/platformsupport/fontdatabases/mac/coretext.pri src/plugins/platforms/cocoa/qcocoawindow.h src/plugins/platforms/cocoa/qcocoawindow.mm Change-Id: I74a6f7705c9547ed8bbac7260eb4645543e32655
| * macOS: Don't keep WA_MacAlwaysShowToolWindow windows always on topTor Arne Vestbø2017-05-241-2/+82
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | On macOS if an application is no longer active then it will cause any tool windows to hide until the application is active again. For applications that did not want this behavior and thus wanted the tool window to stay visible, the WA_MacAlwaysShowToolWindow flag is available. In order to ensure that this flag is respected, the tool window needs to have its level changed when the application active status changes. Once it is no longer active the window needs to be seen as a normal window, and when it is active then it needs to be set to be a window that is always on top to get the right behavior. Due to various bugs in AppKit we need to explicitly order windows in front during this process, which requires us to then iterate the windows in back-to-front order. For macOS versions < 10.12 there is no way to get an ordered list of windows, so we fall back to using the window creation order. Task-number: QTBUG-57581 Change-Id: If20b4698616707685f83b1378f87593f8169c8c6 Reviewed-by: Andy Shaw <andy.shaw@qt.io>
| * macOS: Don't create NSWindow for embedded viewsTor Arne Vestbø2017-05-161-2/+10
| | | | | | | | | | | | | | | | | | | | | | An embedded view does not have a QCocoaWindow parent, but that doesn't mean it's a top level. Improved debug logging to make issues related to this code easier to spot in the future. Change-Id: I15b5acdd8d7112600618465a3b65b64fddc306f7 Reviewed-by: Gabriel de Dietrich <gabriel.dedietrich@qt.io>
* | macOS: Remove workaround when adding view as subviewTor Arne Vestbø2017-05-221-3/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | a6b34517e introduced this code as a workaround for stale QCocoaWindow pointers during event delivery, but these days QCocoaWindow is a QObject and guarded by QPointer. Disassembly of AppKit also shows that the view is removed for us, so there's no need to do it explicitly, especially as this causes two distinct event callbacks from AppKit for what should be one atomic operation. Task-number: QTBUG-42059 Change-Id: I212c894adf6aee51256ceff03c9821a995c2a63d Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io> Reviewed-by: Gabriel de Dietrich <gabriel.dedietrich@qt.io>
* | macOS: Remove workaround when setting view as content viewTor Arne Vestbø2017-05-221-4/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | abde2a59c60 introduced this code on the basis that setContentView does not remove the view from its superview, but disassembly of AppKit shows that it does. Since commit 52767b8ee754 we also ensure that the previous NSWindow has its contentView property cleared, so this workaround is no longer needed. Task-number: QTBUG-39628 Change-Id: I21e179263d006f3af1f8a55e9e2f7e8eeab2a632 Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io> Reviewed-by: Gabriel de Dietrich <gabriel.dedietrich@qt.io>
* | macOS: Guard on platform window instead of window delegate in QNSWindowHelperTor Arne Vestbø2017-05-121-2/+2
| | | | | | | | | | | | | | | | | | The platform window is cleared in detachFromPlatformWindow, just like the delegate, but the platform window may be cleared due to other reasons as well, so use that as a guard before calling functions on the pw. Change-Id: Ie0773182073d4932b2bca8bc0fc8af24b8895a9d Reviewed-by: Gabriel de Dietrich <gabriel.dedietrich@qt.io>
* | macOS: Reduce usage of m_nsWindow to manipulate the view's NSWindowTor Arne Vestbø2017-05-091-111/+138
| | | | | | | | | | | | | | | | | | | | | | | | With the right guards for isContentView() we can use m_view.window directly. The only instances left of m_nsWindow are during window creation, which will be removed in a followup. Message send syntax for reading or writing Objective-C properties has been replaced with dot syntax where appropriate. Change-Id: I86925753612516625c93ea5bbedc98a3ddd8fec4 Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
* | macOS: Reduce usage of m_nsWindow in favor of isContentView()Tor Arne Vestbø2017-05-081-31/+33
| | | | | | | | | | | | | | | | | | | | | | The m_nsWindow member both indicates whether or not the QCocoaWindow represents the content view of a NSWindow, and provides access to that NSWindow. The former is better expressed through isContentView(), which allows us to then replace m_nsWindow entirely in a followup with access though m_view.window, removing the need to cache the NSWindow. Change-Id: I6e7de4b6d64b29fc9023222be045254f18be28cd Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
* | Merge remote-tracking branch 'origin/5.9' into devLiang Qi2017-05-071-0/+2
|\| | | | | | | | | | | | | | | Conflicts: src/network/access/qnetworkreply.cpp tests/auto/corelib/kernel/qmetaobject/tst_qmetaobject.cpp Change-Id: Iadf766269454087e69fb216fc3857d85b0ddfaad
| * macOS: Add autorelease-pool when recreating NSWindowTor Arne Vestbø2017-05-021-0/+2
| | | | | | | | | | | | | | | | Significantly reduces the number of objects left to rot in the root pool, which is only drained on application shutdown. Change-Id: Iad7520ab083715416d95413a63474b9153f22fb5 Reviewed-by: Morten Johan Sørvig <morten.sorvig@qt.io>
* | Merge remote-tracking branch 'origin/5.9' into devLiang Qi2017-04-201-2/+4
|\| | | | | | | | | | | | | | | | | | | | | | | Conflicts: src/corelib/tools/qbytearray.h src/corelib/tools/qdatetime.h src/corelib/tools/qstring.h src/corelib/tools/qversionnumber.h src/plugins/platforms/android/qandroidplatformintegration.cpp tests/auto/corelib/tools/qhashfunctions/tst_qhashfunctions.cpp Change-Id: Iefd92a435e687a76cd593099e40d9a9620a1454d
| * macOS: Initialize window geometry early on, instead of when creating NSWindowTor Arne Vestbø2017-04-191-2/+4
| | | | | | | | | | | | | | | | | | We don't need to defer to NSWindow creation before determining the initial window geometry, and we don't need to redetermine each time we re-create an NSWindow for a QCocoaWindow. Change-Id: Ie13380830b44e96670ff16513f29deef5f5ae313 Reviewed-by: Morten Johan Sørvig <morten.sorvig@qt.io>
* | Merge remote-tracking branch 'origin/5.9' into devLiang Qi2017-04-041-16/+13
|\| | | | | | | | | | | | | | | Conflicts: src/platformsupport/fontdatabases/mac/qcoretextfontdatabase_p.h src/plugins/platforms/xcb/qxcbwindow.cpp Change-Id: Ic747c3c50e68c005b425e7a1ec2a90965527c8bd
| * macOS: Remove workaround for default-sized NSViewsTor Arne Vestbø2017-03-281-7/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The workaround introduced in 38a55c7 to explicitly call viewDidChangeFrame() was not ideal for a multitude of reasons. Instead we can just initialize the NSView with a NSZeroRect frame, which will ensure that whatever geometry we set from the Qt side will result in geometry change and expose events. The only case where we will not receive an expose event is if the QWindow is requested to be 0x0 sized, but that wouldn't warrant an expose event anyways. Also, it's not possible to initialize a QWindow to 0x0 from the Qt side, as that will trigger QPlatformWindow::initialGeometry() to pick the default size (160x160 in the case of macOS). Task-number: QTBUG-58963 Change-Id: Ia84de7edcfdf26b90e4e93186fabe8b5c7382caa Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
| * Avoid expensive QHash::values() callsAnton Kudryavtsev2017-03-281-2/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | qcocoawindow.mm: we can replace QHash::values() with std::vector since CoW is needless here and std::vector is more cache-friendly. Also replace foreach with range-based for. qitemeditorfactory.cpp: QHash::values() is used as auxiliary container to create QSet. Replace it with std::vector since CoW is needless here and apply sort-unique idiom to remove duplicates. Also avoid needless allocations. Change-Id: If34c7016977ceb7fab68e9298bf2e1944af79139 Reviewed-by: Marc Mutz <marc.mutz@kdab.com>
| * QCocoaWindow - fix a compilation errorTimur Pocheptsov2017-03-281-7/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | Clang does not like Q_FALLTHROUGH in 'default' label, the diagnostics is: 'fallthrough annotation does not directly precede switch label'. Accodring to their docs: "The fallthrough (or clang::fallthrough) attribute is used to annotate intentional fall-through between switch labels. It can only be applied to a null statement placed at a point of execution between any statement and the next switch label." - obviously, there is no 'next switch label' in our case. Change-Id: Ia7dba4cb965a85d229d44b04b69633a8f07d4a0c Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
| * macOS: Disassociate NSView from contentView when switching NSWindowsTor Arne Vestbø2017-03-271-0/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When a NSView is the contentView of a NSWindow, it still has a superview, in this case an NSThemeFrame, and the theme frame is the view that retains the view, not the contentView property of the window. Unfortunately, when a view is removed from the NSThemeFrame by means of [NSView removeFromSuperview], or indirectly via [NSView addSubview:], AppKit does not update the contentView property of the corresponding NSWindow. The result is that the NSView might be deallocated while the NSWindow still is around, with a stale contentView property. To work around this we explicitly disassociate the view from the NSWindow when we know that we are going to release the NSWindow. This will take care of both resetting the property to nil, and remove the view from the NSThemeFrame superview. Task-number: QTBUG-59734 Change-Id: I1111d492f52fe5bdf86bbae071421f6a8a7a38b8 Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io> Reviewed-by: Jake Petroules <jake.petroules@qt.io>
* | Merge remote-tracking branch 'origin/5.9' into devLiang Qi2017-03-201-0/+7
|\| | | | | | | | | | | | | | | | | Conflicts: src/corelib/io/qfilesystemengine_win.cpp src/gui/text/qdistancefield.cpp src/plugins/platforms/xcb/qxcbconnection.h Change-Id: I1be4a6f440ccb7599991159e3cb9de60990e4b1e
| * QCocoaWindow: fix geometry issue when only minimumSize is setOleg Yadrov2017-03-181-0/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | When only minimumSize was set and it matched to the size NSView was created with, viewDidChangeFrame() was not called for the window and it's internal geometry value was still (0, 0) what led to unpleasant side effects such as QML content was not displayed until something caused an update. Task-number: QTBUG-58963 Change-Id: Ib12d36d405969971e7ff62b79b50c3d78928a649 Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io> Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
* | Make QWindow's windowState a QFlags of the WindowStateOlivier Goffart2017-03-161-3/+5
|/ | | | | | | | | | | | | | | | | | | | | | | | | | | | This reflects QWidget API, and restores some behavior from Qt4. Some WM can have several state at the same time. On Plasma for example, when a window is both maximized and minimized, the "maximized" checkbox is checked from the taskbar entry. The API of QPlatformWindow was changed to take a QFlag and the platform plugins were adapted. - On XCB: Always send the full state to the WM. And read the full state. - On Windows: The code was originally written with '&' in Qt4, and was changed to == when porting. Some adaptation had to be made so the states would be preserved. - On macOS: Only a single state can be set and is reported back for now, with the possibly to expand this in the future. - Other platforms: Just do as before with the effective state. Task-number: QTBUG-57882 Task-number: QTBUG-52616 Task-number: QTBUG-52555 Change-Id: I7a1f7cac64236bbd4c591f796374315639233dad Reviewed-by: Gunnar Sletta <gunnar@crimson.no> Reviewed-by: Robin Burchell <robin.burchell@crimson.no>
* macOS: Make sure NSResizableWindowMask is set when toggling fullscreenTor Arne Vestbø2017-02-221-14/+28
| | | | | | | | | | | | Instead of setting the mask in toggleFullScreen(), which is only hit when going to fullscreen via our own API, we do it in the window notification callbacks, which also includes going to full screen via the native macOS title bar buttons. This allows making customized windows without Qt::WindowMaximizeButtonHint full screen with the full geometry of the screen. Change-Id: I63c3e4582ea7c4fe8c0008265793c5f656b830b2 Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
* QWindow: Remove "_q_foreignWinId" dynamic propertyTor Arne Vestbø2017-02-221-3/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The platform plugins reading this out of the QWindow was a layering violation, and propagates the notion that a window can shape shift into representing a new native handle, while none of the platform plugins support this. A foreign QWindow is created via the factory function fromWinId(), at which point we can pass the WId all the way to the platform plugin as function arguments, where the platform will create a corresponding platform-window. The platform window can then answer the question of whether or not it's representing a foreign window, which determines a few behavioral changes here and there, as well as supplying the native window handle back for QWindow::winId(); [ChangeLog][QtGui][QWindow] The "_q_foreignWinId" dynamic property is no longer set nor read. [ChangeLog][QtGui][QPA] The function createForeignWindow() has been added to QPlatormIntegration and is now responsible for creating foreign windows. The function isForeignWindow() in QPlatformWindow has been added, and platforms should implement this to return true for windows created by createForeignWindow(). Task-number: QTBUG-58383 Change-Id: If84142f95172f62b9377eb5d2a4d792cad36010b Reviewed-by: Gabriel de Dietrich <gabriel.dedietrich@qt.io>
* macOS: Retain foreign windowsTor Arne Vestbø2017-02-201-0/+1
| | | | | | | | | | | | | Regression after 89842b97d74d1, where the retain was part of setView. We release m_view in the destructor, regardless of how the view was acquired, and the non-foreign window retains by being the one creating the view. Task-number: QTBUG-59001 Change-Id: I6d9621a63ea6ec2cee008986b0ab72ff61110ad7 Reviewed-by: René J.V. Bertin <rjvbertin@gmail.com> Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
* macOS: Move NSWindow creation properties into createNSWindow()Tor Arne Vestbø2017-02-161-56/+36
| | | | | | | | | | Allows the block in recreateWindowIfNeeded() that calls createNSWindow() to focus on how to (re)parent windows/views, while createNSWindow() takes care of how to set up the window. Dynamic properties that may change later on are handled in e.g. setWindowFlags(). Change-Id: Ice0e44d004bd2608b2b54e6dde0f404a1e07dc10 Reviewed-by: Mike Krus <mike.krus@kdab.com>
* macOS: Rewrite window state handlingTor Arne Vestbø2017-02-161-86/+188
| | | | | | | | | | | | | | | | | | | | | | | | | | | Instead of relying on specific notifications to change the window state we now evaluate the state based on the current window state. This allows us to get rid of windowShouldZoom in the window delegate, making window state handling work for foreign windows as well, and also allows us to re-evaluate the state in more places, such as when moving a window, which may bring it out of maximized state. The full screen state is tracked by a helper category that doesn't just rely on the styleFlag, but also on the full screen notifications. This is needed as macOS will complain if you try to go in or out of fullscreen while a transition is in effect. The differentiation between performFoo: and foo: has been removed, as the latter works in both cases and doesn't rely on the button being visible/enabled. These changes fixes many observed quirks in the window state handling that also resulted in making it hard to write tests that relied on the fullscreen/maximized operations always working. Change-Id: I0538c42d9223a56f20ec9156f4939288e0750552 Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io> Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
* macOS: Don't hide NSWindowZoomButton when window can go into fullscreenTor Arne Vestbø2017-02-151-1/+2
| | | | | | | | | | | | | | | The button in the title bar is used both for going into full screen and maximizing (zooming) the window. We can't hide/disable it unless both Qt::WindowFullscreenButtonHint and Qt::WindowMaximizeButtonHint are off. This means that when Qt::WindowMaximizeButtonHint is off, it's still going to be possible to Option-click the button to maximize the window, but this is less of a concern than hiding the full screen button when Qt::WindowFullscreenButtonHint is set. Change-Id: I70dbe27b3197fe22c1781277f8bf9a818d71d04d Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
generated by cgit v1.2.3 (git 2.25.1) at 2024-05-24 15:15:04 +0000