summaryrefslogtreecommitdiffstats
path: root/src/plugins/platforms/ios/quiview.mm
Commit message (Collapse)AuthorAgeFilesLines
* iOS: Move QUIWindow implementation out of qiosscreen.mmTor Arne Vestbø2024-04-181-0/+1
| | | | | | | | Task-number: QTBUG-121781 Change-Id: Iaa4388908d0d59022ec05b63696147a0d1d01ae1 Reviewed-by: Amr Elsayed <amr.elsayed@qt.io> Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io> Reviewed-by: Assam Boudjelthia <assam.boudjelthia@qt.io>
* Add preliminary support for Qt for visionOSTor Arne Vestbø2024-04-181-4/+6
| | | | | | | | | | | | | | | | | | | | | | Qt already runs on Vision Pro as "Designed for iPad", using Qt for iOS. This change enables building Qt for visionOS directly, which opens the door to visionOS specific APIs and use-cases such as volumes and immersive spaces. The platform removes some APIs we depend on, notably UIScreen, so some code paths have been disabled or mocked to get something up and running. As our current window management approach on UIKit platforms depends on UIWindow and UIScreen there is currently no way to bring up QWindows. This will improve once we refactor our window management to use window scenes. To configure for visionOS, pass -platform macx-visionos-clang, and optionally add -sdk xrsimulator to build for the simulator. Change-Id: I4eda55fc3fd06e12d30a188928487cf68940ee07 Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
* iOS: Remove NSView.safeAreaInsets wrapperTor Arne Vestbø2024-03-191-5/+0
| | | | | | | | | The API is available on all iOS versions we support nowadays. Pick-to: 6.7 6.6 6.5 Change-Id: Ia58c5ad1649e7e6b22f9c56a809e2455586a8e5a Reviewed-by: Amr Elsayed <amr.elsayed@qt.io> Reviewed-by: Doris Verria <doris.verria@qt.io>
* iOS: Guard against displayLayer after platform window is goneTor Arne Vestbø2024-02-051-0/+3
| | | | | | | | | | During shutdown the UIView might outlive its QIOSWindow platform window. If we receive displayLayer calls, we need to bail out, to avoid crashing when trying to send the expose event. Pick-to: 6.7 6.6 6.5 Change-Id: I2f36a4dd825e91b348bc57a06e6aa6b1a12fd249 Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@qt.io>
* iOS: Avoid category method name clash for UIResponderPaul Heimann2024-01-111-3/+3
| | | | | | | | | | | | | | As described in Apples documentation, own methods which are added to existing classes should be prefixed to avoid category method name clashes. This prefix was missing from the function currentFirstResponder() which caused issues when closing the virtual keyboard on some iOS devices. (see https://developer.apple.com/library/archive/qa/qa1908/_index.html) Pick-to: 6.7 6.6 6.5 Task-number: QTBUG-119601 Change-Id: I82fb8a8beeb0a3234594357f1e1db67b0ae3da36 Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
* Rename QWSI::handleWindowActivated to QWSI::handleFocusWindowChangedTor Arne Vestbø2023-11-231-2/+2
| | | | | | | | | | | | | | | | | | | A single QWindow is QGuiApplication::focusWindow() at a time, and this window is typically also QWindow::isActive(), but other windows may also be QWindow::isActive(). For example, we treat any sibling or ancestor of the focusWindow as being QWindow::isActive() as well. In addition, in the case of non-QWindow child windows, we may have to query the platform for the activation state, which means we also need a way for the platform to reflect changes in this state through QWSI. The current API for this, QWSI::handleWindowActivated, is in practice a focus window change API, so as a first step let's rename it to better reflect what it's doing. Task-number: QTBUG-119287 Change-Id: I381baf8505dd13a4a829c961095a8d2ed120092b Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@qt.io>
* iOS: Make nextTouchId static, unsigned and let it overflowShawn Rutledge2023-11-091-6/+4
| | | | | | | | | | | | | | | | | | | | | | | | If an application has two windows, and the user tries to do multi-touch gestures with different fingers in each window at the same time, we want the touchpoint IDs to be unique. m_nextTouchId was a per-window variable before; the result was that the QEventPoint delivered to the second window was replacing values (including QEventPointPrivate::window) in the persistent QEventPoint that was still being held in the first window; then when the release of the first point occurred, QGuiApplicationPrivate::processTouchEvent() saw its destination window pointer as null because the second touchpoint had already been released. QEventPoint::id is of type int, with negative values being invalid. nextTouchId is of type quint16 so that it will always be positive, and we can let it eventually overflow (wrap back to 0) rather than resetting it to 0 after each touch gesture. The only requirement is that the IDs need to be unique and positive (and typically they are sequential: that makes debug output easier to understand). Task-number: QTBUG-118909 Change-Id: Ia0f1edc9a5e2b362028bed4418fed228814cddb6 Pick-to: 6.5 6.6 Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
* iOS: Respect QSurfaceFormat::colorSpace() when using MetalTor Arne Vestbø2023-03-021-0/+11
| | | | | | | | | | | | | | Unlike on macOS, there's no colorSpace property on UIWindow or UIView, but CAMetalLayer has one, which allows us to tell Core Animation that the layer targets a specific color space, and Core Animation will then do the rest of the color matching to the target display. Now that we use Metal to flush raster content, this is even more useful. Task-number: QTBUG-108094 Pick-to: 6.5 Change-Id: Ib04b42d9baa296b608983db38faf0398430db093 Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
* iOS: Fix build with -no-openglTor Arne Vestbø2023-02-011-0/+5
| | | | | | Pick-to: 6.5 Change-Id: I014fa1772f629ef4224ac98bfc30eb5a86f38fde Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
* iOS: send control keys to Qt, even if IM is enabledRichard Moe Gustavsen2022-09-241-22/+31
| | | | | | | | | | | | | | | | | Perhaps dating as far back as 829e421ddcd5e8f (Qt 5.8), using the arrow keys on a bluetooth keyboard to navigate the cursor around in a TextArea/QTextEdit has been broken. Some work was done to remedy this with 15576c9610 (Qt 6.1) it seems, but still, using the arrow keys is broken in 5.15, 6.2 and dev. This patch will ensure that we send control key events, such as Qt::Key_Up and Qt::Key_Down, to Qt, also when the focus object accepts Input Methods. Fixes: QTBUG-101339 Pick-to: 6.4 6.2 5.15 Change-Id: I2d12438a822a607646080ab2edb17de8ea6d337c Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
* iOS: use NSProcessInfo to resolve timestamps in simulator buildsRichard Moe Gustavsen2022-08-181-5/+31
| | | | | | | | | | | | | | | | | | | | | | | | | We currently build Qt for simulator using X86_64, even on ARM based macs. This results in the simulator running on ARM, while the app is running inside it using Rosetta. And with this combination, the event.timestamp, which is documented to be in seconds, looks to be something else, and is not progressing in sync with a normal clock. Sending out mouse events with a timestamp that doesn't follow normal clock time will cause problems for mouse-, and pointer handlers that uses them to e.g calculate the time between a press and release, and to decide if the user is performing a tap or a drag. For that reason, we choose to ignore UIEvent.timestamp under the mentioned condition, and instead rely on NSProcessInfo. Note that if we force the whole simulator to use Rosetta (and not only the Qt app), the timestamps will progress normally. Fixes: QTBUG-105810 Pick-to: 6.4 6.3 6.2 Change-Id: Ib4e60593cac3230567ebc53d634f434fcefc98d0 Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
* Remove unneeded @available check for macOS <= 10.14 and iOS <= 13Tor Arne Vestbø2022-08-051-8/+0
| | | | | | | | All versions down to Qt 6.2 require macOS 10.14 or iOS 13. Pick-to: 6.2 6.3 6.4 Change-Id: I5048921ea5a149346a0fa84228227d9156004675 Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
* darwin: Remove unneeded SDK version checks for older versionsTor Arne Vestbø2022-08-051-8/+0
| | | | | | | | | All versions down to 6.2 require at least Xcode 12, which ships with the macOS 11 SDK, and iOS 14 SDK. Pick-to: 6.4 6.3 6.2 Change-Id: I128321ec9e97b670b7c027f1233978e1b8856f88 Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
* iOS plugin: Add support for wheel eventsDoris Verria2022-07-051-0/+81
| | | | | | | | Use UIPanGestureRecognizer to handle mouse and trackpad scroll. Task-number: QTBUG-99795 Change-Id: I5db7fabf55b6f2e6f7ba90a0b90ecb08734e2329 Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
* iOS: Send touch events asynchronously to avoid deadlocking UIKit event loopTor Arne Vestbø2022-07-011-2/+10
| | | | | | | | | | | | | | | | | | | | | | Although CFRunLoop is documented to support nesting, the UIKit event delivery machinery is not prepared to handle nested event loops. If the user starts a nested event loop in response to e.g. a button press/release, it will deadlock the entire UIKit event machinery, stopping processing of both screen updates (CATransactions) as well as other events. This became an issue on iPhone hardware device in iOS 15, but can not be reproduces on iPads or in the simulator. To be on the safe side, we deliver all touch events asynchronously, even if that means the application code will always be one step behind the event delivered by the operating system. Fixes: QTBUG-98651 Pick-to: 6.4 6.3 6.2 5.15 Change-Id: Id0a9fa60b7bb7aa98606d46257e99eac144a1080 Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io> Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@qt.io> Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
* Replace QT_NO_ACCESSIBILITY with QT_CONFIG(accessibility)Allan Sandfeld Jensen2022-06-151-1/+1
| | | | | | | Pick-to: 6.4 Change-Id: Iee4bd8970810be1b23bdba65a74de912401dca65 Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Marc Mutz <marc.mutz@qt.io>
* Use SPDX license identifiersLucie Gérard2022-05-161-38/+2
| | | | | | | | | | | | | Replace the current license disclaimer in files by a SPDX-License-Identifier. Files that have to be modified by hand are modified. License files are organized under LICENSES directory. Task-number: QTBUG-67283 Change-Id: Id880c92784c40f3bbde861c0d93f58151c18b9f1 Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Lars Knoll <lars.knoll@qt.io> Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
* QIOSTextInputResponder: factor out the "read-only" part to a ↵Richard Moe Gustavsen2021-11-111-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | QIOSTextResponder base class QIOSTextInputResponder has two responsibilities; It takes care of handling text input from UIKit, and to implement first responder actions related to the edit menu, like copy and paste. Currently the responder offers both writable (paste) and readable (select, copy) actions. Because of the former, it means that it can only be used for focus objects that accepts text input. Since we also want to be able to show an edit menu for selections done on a read-only input field, this patch will factor out the read-only actions we want for that case into a QIOSTextResponder base class. An instance of this class can be used as first responder for a focus object that has read-only text, but otherwise doesn't support text input. This part is implemented in a subsequent patch. The remaining set of writeable actions, together with input method handling, will continue to be in the QIOSTextInputResponder subclass. Task-number: QTBUG-91545 Change-Id: I1c215bb509eb7820c6c60f7ad806f61a5de02ded Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
* Use qmath.h's conversions between degrees and radiansEdward Welbourne2021-09-101-3/+4
| | | | | | | | The make the semantics overt and avoid the joys of yet another approximation to pi/180 hard-coded in our source-code. Change-Id: I9dcbaada2e7de119e385fc7056bc601ecd59311a Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
* iOS: Pass the text to handleExtendedKeyEvent when knownAndy Shaw2021-02-231-4/+7
| | | | | | | | | This will ensure that the QKeyEvent also has this information passed on as appropriate. Pick-to: 6.1 Change-Id: I52436404115b453664b9b3414f8ec4e715dd6a28 Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
* macOS: don't let windows that are transparent for input become key windowVolker Hilsheimer2021-02-191-1/+2
| | | | | | | | | | | | Such windows are typically used as mostly transparent overlays on top of other windows underneath. Letting such an overlay become the key window breaks cursor updates and focus handling. Pick-to: 6.0 6.1 5.15 Fixes: QTBUG-83632 Change-Id: I192d419a5bdb8dfa0e9223e9fbbd7876c62fe743 Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@qt.io> Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
* iOS: Disable three-finger-tap editing interaction menu when there's no focus ↵Tor Arne Vestbø2021-02-111-0/+13
| | | | | | | | | | | | | | | | | | | | | | | | | object A typical Qt application, such as a QML application, is a single full screen QUIView, containing all of the granular controls of the UI. The view accepts first responder status, so that we can pass on text input to a possible text field inside the UI. That however triggers iOS to bring up the editing interaction menu whenever the user taps with three fingers, as iOS can't know that only parts of our view is suitable for interaction. To mitigate that we override the editingInteractionConfiguration getter of the view, as documented, and dynamically report the correct enablement based on whether we have an active focus object that accepts input. This works because iOS queries the getter from the three finger tap gesture recognizer, before showing the menu. Change-Id: I0874340c42e437e1d7251896993f2eafe122f09e Fixes: QTBUG-89735 Pick-to: 6.0 6.1 5.15 Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@qt.io>
* iOS: Handle keyboard events when using an external keyboardAndy Shaw2021-01-201-8/+39
| | | | | | | | | | | | | | | | | | This enables the two possible approaches for handling external keyboard events. While support still exists for before 13.4 then both approaches are needed. This ensures that all external keyboard events are handled as key events and passed on accordingly. Additionally, this accounts for possible shortcuts too, therefore a new function is added to QShortcutMap to aid that. As a result, code has now moved from QCocoaKeyMapper to be part of the gui/platforms/darwin part to make it easier to reuse this code elsewhere. Fixes: QTBUG-85727 Change-Id: I349af43468b03fd8dcb16adba02669974affe154 Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
* Fix warning: don't compare Qt::TouchPointReleased and QEventPoint::StateShawn Rutledge2020-09-021-1/+1
| | | | | | | | They are actually equivalent, but from different enums. Change-Id: Ic5f148e2e6bb260c226026b3f89333626a6020ec Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io> Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
* Refactor pointer event hierarchyShawn Rutledge2020-07-101-6/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Some goals that have hopefully been achieved are: - make QPointerEvent and QEventPoint resemble their Qt Quick counterparts to such an extent that we can remove those wrappers and go back to delivering the original events in Qt Quick - make QEventPoint much smaller than QTouchEvent::TouchPoint, with no pimpl - remove most public setters - reduce the usage of complex constructors that take many arguments - don't repeat ourselves: move accessors and storage upwards rather than having redundant ones in subclasses - standardize the set of accessors in QPointerEvent - maintain source compatibility as much as possible: do not require modifying event-handling code in any QWidget subclass To avoid public setters we now introduce a few QMutable* subclasses. This is a bit like the Builder pattern except that it doesn't involve constructing a separate disposable object: the main event type can be cast to the mutable type at any time to enable modifications, iff the code is linked with gui-private. Therefore event classes can have less-"complete" constructors, because internal Qt code can use setters the same way it could use the ones in QTouchEvent before; and the event classes don't need many friends. Even some read-accessors can be kept private unless we are sure we want to expose them. Task-number: QTBUG-46266 Fixes: QTBUG-72173 Change-Id: I740e4e40165b7bc41223d38b200bbc2b403e07b6 Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
* Add ; to Q_UNUSEDLars Schmertmann2020-07-071-3/+3
| | | | | | | | This is required to remove the ; from the macro with Qt 6. Task-number: QTBUG-82978 Change-Id: I3f0b6717956ca8fa486bed9817b89dfa19f5e0e1 Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io>
* Fix UITouch event handling on tvOSMike Krus2020-06-291-9/+23
| | | | | | | | | | | | | | | | | | | | | On tvOS touchesEnded: occasionally gets called with touches that have not been passed via the touchesBegan:. When this happens previously cached touch event (that HAVE been passed to touchesBegan:) are no longer valid. This causes a crash when testing if new touches contain old ones (since NSSet dereferences the needle which is no longer valid). Fix uses the unique (unsigned int) hash that UIKIT assigns to the UITouch instance so cached copies are never accessed. Furthermore, tvOS only supports single touch so now just clearing cache when touch has ended. Task-number: QTBUG-84383 Pick-to: 5.15 Pick-to: 5.12 Change-Id: I7592cdde74ce834285e7b14196171f6b57736cc8 Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
* Introduce QInputDevice hierarchy; replace QTouchDeviceShawn Rutledge2020-06-161-11/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | We have seen during the Qt 5 series that QMouseEvent::source() does not provide enough information: if it is synthesized, it could have come from any device for which mouse events are synthesized, not only from a touchscreen. By providing in every QInputEvent as complete information about the actual source device as possible, we will enable very fine-tuned behavior in the object that handles each event. Further, we would like to support multiple keyboards, pointing devices, and named groups of devices that are known as "seats" in Wayland. In Qt 5, QPA plugins registered each touchscreen as it was discovered. Now we extend this pattern to all input devices. This new requirement can be implemented gradually; for now, if a QTWSI input event is received wtihout a device pointer, a default "core" device will be created on-the-fly, and a warning emitted. In Qt 5, QTouchEvent::TouchPoint::id() was forced to be unique even when multiple devices were in use simultaneously. Now that each event identifies the device it came from, this hack is no longer needed. A stub of the new QPointerEvent is added; it will be developed further in subsequent patches. [ChangeLog][QtGui][QInputEvent] Every QInputEvent now carries a pointer to an instance of QInputDevice, or the subclass QPointingDevice in case of mouse, touch and tablet events. Each platform plugin is expected to create the device instances, register them, and provide valid pointers with all input events. If this is not done, warnings are emitted and default devices are created as necessary. When the device has accurate information, it provides the opportunity to fine-tune behavior depending on device type and capabilities: for example if a QMouseEvent is synthesized from a touchscreen, the recipient can see which touchscreen it came from. Each device also has a seatName to distinguish users on multi-user windowing systems. Touchpoint IDs are no longer unique on their own, but the combination of ID and device is. Fixes: QTBUG-46412 Fixes: QTBUG-72167 Task-number: QTBUG-69433 Task-number: QTBUG-52430 Change-Id: I933fb2b86182efa722037b7a33e404c5daf5292a Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
* macOS/iOS: set focus reason when handling window deactivationVolker Hilsheimer2020-04-291-2/+2
| | | | | | | | | Otherwise, the focusOutEvent to e.g. a QQuickItem losting focus will be OtherFocusReason when the window it's becomes inactive. Task-number: QTBUG-70319 Change-Id: Ic3762e68d92a88becd2b35612b14f6af64ee934e Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
* Initial cleanup of qevent.h for Qt6Allan Sandfeld Jensen2020-03-051-0/+1
| | | | | | | | | | | | Takes care of the first round of todos and deprecations for Qt6 in qevent. Not touching anything that might interfere with changing the class hierarchy as the file also suggest. Change-Id: If72d63d8932f1af588785bf77b34532358639a63 Reviewed-by: Allan Sandfeld Jensen <allan.jensen@qt.io> Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
* Enable QRhi Metal backend on iOSLaszlo Agocs2019-11-271-7/+28
| | | | | | | | | | While we are at it, remove the Border and MirrorOnce wrap modes that have not been supported on OpenGL, because they are unsupported with Metal+iOS as well. Task-number: QTBUG-78580 Change-Id: I0db94b9d3a6125b3bb5d7b1db5d02a42cd94d2c2 Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
* iOS: Account for UITextInteraction when building against 12.x or lowerAndy Shaw2019-11-071-6/+2
| | | | | | | | | In iOS 13.0 we can handle UITextInteraction as normal, but in lower versions it is not available to utilize at compile time. So we have to check for the other types instead and return if it is not one of those. Change-Id: Icbc5558e677ed40c03f30a174e2d79b87f489f68 Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
* Revert "iOS: Account for when the older SDK is used when building"v5.13.2Andy Shaw2019-10-251-0/+2
| | | | | | | | | This reverts commit 631efee29371246ba1a1d9d007b23ca08b867191. Reason for revert: This causes a problem when running on iOS 11 devices. Change-Id: If5194989b8d7a9f4cf2d72e770fdaad754d7e236 Reviewed-by: Jani Heikkinen <jani.heikkinen@qt.io>
* iOS: Account for when the older SDK is used when buildingAndy Shaw2019-10-171-2/+0
| | | | | | | | | | Since the pre-built versions of Qt at this point are still built against the iOS 12.x SDKs, then we need to account for this in order to have the workaround implemented in e00d888daefbfbd5f17e0772421773f8e295087b still working when deployed to an iOS 13 based device. Change-Id: I649a453c549ee272de64624d68f9382276fcba64 Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
* iOS: Prevent UIKit from adding UITextInteraction to our viewTor Arne Vestbø2019-10-041-0/+12
| | | | | | | | | | | | | | | | | | | It's added automatically when some languages such as Japanese are the active input language/keyboard, which results in UIKit triggering the edit menu for any tap in the UI, regardless of whether it hits the focus object or not. Adopting the protocol is a much larger effort and needs to be coordinated so that we still support text interaction on iOS versions pre 13.0. Even with this patch the UITextSelectionView will still blink its own cursor, which doesn't seem to sync up with the UITextInput protocol's view of where the cursor is. Fixes: QTBUG-78496 Change-Id: I61500ad7ab9c8577f71188c0c99ead39465e3839 Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
* Remove codepaths and checks for unsupported Apple platformsTor Arne Vestbø2018-08-311-31/+14
| | | | | | | We no longer support macOS 10.11, iOS/tvOS 10, or watchOS 3. Change-Id: Ide03d8fac06185ef4162ba75ee54a0adf6916905 Reviewed-by: Morten Johan Sørvig <morten.sorvig@qt.io>
* iOS: Don't assume our UIWindow is a QUIWindowTor Arne Vestbø2018-04-171-1/+2
| | | | | Change-Id: I6494e4a476273b131aedcf409abdb1ffffa5b62e Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@qt.io>
* Merge remote-tracking branch 'origin/5.11' into devLiang Qi2018-04-111-1/+1
|\ | | | | | | | | | | | | Conflicts: src/plugins/platforms/ios/quiview.mm Change-Id: I0fd0adeca1590fffddd577873172f6d987a60412
| * iOS: Remove sending of duplicate touch events after broken mergeTor Arne Vestbø2018-04-101-1/+1
| | | | | | | | | | | | | | | | | | | | | | The merge in 0f315adf9199ef resulted in keeping both code paths, in effect sending two touch events for each native touch event, and also re-introduced the bug fixed by sending the touch events asynchronously in some cases. Change-Id: Id81f02d9597f4e0baeaddbdf9057fa32b6c31b2f Reviewed-by: Frederik Gladhorn <frederik.gladhorn@qt.io> Reviewed-by: Lars Knoll <lars.knoll@qt.io>
* | Clean up our Objective-C usageJake Petroules2018-02-201-34/+40
|/ | | | | | | | | | | | | | | | - Move ivars into @implementation - Use instancetype where applicable - Use dot notation for property access - Use subscript operator for dictionaries and arrays - Format selectors consistently - Use proper style for init methods - Use generics instead of void pointers where possible - Use "range for" loops instead of indexing - Replace or replace IBAction/IBOutlet with void Change-Id: I1667812a51d4dfe44ae80fe337cb1f4bc9699d92 Reviewed-by: Jake Petroules <jake.petroules@qt.io> Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
* Merge remote-tracking branch 'origin/5.10' into 5.11Liang Qi2018-02-151-12/+23
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Conflicts: src/corelib/corelib.pro src/corelib/global/qrandom.cpp src/network/access/qhttpnetworkrequest_p.h src/plugins/platforms/cocoa/qcocoamenu.mm src/plugins/platforms/cocoa/qcocoansmenu.mm src/plugins/platforms/cocoa/qcocoawindow.mm src/plugins/platforms/cocoa/qnsview.mm src/plugins/platforms/offscreen/qoffscreenintegration.h src/widgets/kernel/qaction.cpp src/widgets/widgets.pro Done-with: Andy Shaw <andy.shaw@qt.io> Change-Id: Ib01547cf4184023f19858ccf0ce7fb824fed2a8d
| * iOS: Simplify logging of QUIView/QIOSWindowTor Arne Vestbø2018-02-051-12/+23
| | | | | | | | | | | | | | | | | | | | Automatically printing the relationship between the view, platform window, and window, makes it easier to track each object across events. Change-Id: I9fbfaa5c304849ed99dba3b5cd8e7449105d0307 Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@qt.io> Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
* | Merge remote-tracking branch 'origin/5.10' into devLiang Qi2018-01-041-0/+2
|\| | | | | | | Change-Id: I644cd82b0d952b7d139e0228bf5017f147db77e7
| * Merge remote-tracking branch 'origin/5.9' into 5.10Liang Qi2018-01-041-0/+2
| |\ | | | | | | | | | Change-Id: I3fa5c9e216201bdf7da260c395f65d7fb95cba0b
| | * Fix the iOS/tvOS platform plugin build on tvOSJake Petroules2018-01-041-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | This fixes a regression from ba44cdae38406c429c7fb43863a6883bd0f79cf5. Task-number: QTBUG-65516 Change-Id: I989b075d3f96170660042349437e4a6a4a115cf9 Reviewed-by: Liang Qi <liang.qi@qt.io>
* | | Merge remote-tracking branch 'origin/5.10' into devLars Knoll2018-01-021-8/+80
|\| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Conflicts: .qmake.conf sc/corelib/io/qfsfileengine_p.h src/corelib/io/qstorageinfo_unix.cpp src/platformsupport/eglconvenience/qeglpbuffer_p.h src/platformsupport/input/libinput/qlibinputkeyboard.cpp src/platformsupport/input/libinput/qlibinputpointer.cpp src/plugins/platforms/cocoa/qcocoamenu.mm src/plugins/platforms/ios/qiosscreen.h src/plugins/platforms/ios/qioswindow.h src/plugins/platforms/ios/quiview.mm src/printsupport/dialogs/qpagesetupdialog_unix_p.h src/printsupport/dialogs/qprintpreviewdialog.cpp src/printsupport/widgets/qcupsjobwidget_p.h src/widgets/widgets/qmenu.cpp tests/auto/corelib/tools/qdatetime/tst_qdatetime.cpp tests/auto/widgets/itemviews/qtreeview/tst_qtreeview.cpp Change-Id: Iecb4883122efe97ef0ed850271e6c51bab568e9c
| * | Merge remote-tracking branch 'origin/5.9' into 5.10Lars Knoll2017-12-301-1/+71
| |\| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Conflicts: .qmake.conf mkspecs/win32-g++/qmake.conf src/corelib/global/qglobal_p.h src/corelib/global/qoperatingsystemversion_p.h src/corelib/io/qfilesystemengine_win.cpp src/network/bearer/qbearerengine.cpp src/platformsupport/input/libinput/qlibinputpointer.cpp src/sql/doc/snippets/code/doc_src_sql-driver.cpp src/widgets/kernel/qwidget_p.h src/widgets/kernel/qwidgetwindow.cpp src/widgets/styles/qfusionstyle.cpp tests/auto/corelib/io/qfileinfo/tst_qfileinfo.cpp Change-Id: I80e2722f481b12fff5d967c28f89208c0e9a1dd8
| | * Teach QPlatformWindow about safe area margins and implement for iOSTor Arne Vestbø2017-12-131-0/+39
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The safe area margins of a window represent the area that is safe to place content within, without intersecting areas of the screen where system UI is placed, or where a screen bezel may cover the content. QWidget will incorporate the safe area margins into its contents margins, so that they are are never smaller than the safe area margins. This can be disabled by unsetting the Qt::WA_ContentsMarginsRespectsSafeArea widget attribute, which is set by default. QLayouts will automatically use the contents area of a widget for their layout, unless the Qt::WA_LayoutOnEntireRect attribute has been set. This can be used, along with a contents margin of 0 on the actual layout, to allow e.g. a background image to underlay the status bar and other system areas on an iOS device, while still allowing child widgets of that background to be inset based on the safe area. [ChangeLog][iOS/tvOS] Qt will now take the safe area margins of the device into account when computing layouts for QtWidgets. Change-Id: Ife3827ab663f0625c1451e75b14fb8eeffb00754 Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@qt.io>
| | * iOS: Try to detect and deal with delayed touch delivery due to gesturesTor Arne Vestbø2017-12-061-1/+16
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | A UIGestureRecognizer may have its delaysTouchesBegan or delaysTouchesEnded properties set, which causes iOS to not deliver touch events to the view until the recognizer has failed recognition of its gesture. In that case, the touch event is not delivered via [UIWindow sendEvent:] as usual, but via _UIGestureEnvironmentSortAndSendDelayedTouches. The latter function is apparently not reentrant, as opening a native alert dialog in response to the touch delivery will result in the dialogs's buttons to stop working, probably because they themselves use gestures. Unfortunately iOS maintains two internal gesture recognizers on iPad, of type _UISystemGestureGateGestureRecognizer, probably related to the swipe-from-bottom gesture used for multitasking. Without any workaround, these two recognizers will result in any tap on the bottom part of the screen to be delivered delayed, which may introduce stuck alert dialogs as described above. UITouch has a gestureRecognizers property, but unfortunately this property does not give us any information in the cases where we need it, so we have to use an heuristic involving a UIWindow subclass to detect the case where event delivery is delayed. As there is no way to prevent the user from recursing into an event loop when delivering the event, our only hope is to deliver the event asynchronously. Task-number: QTBUG-64577 Change-Id: I11d9caa8c4542dc80426a9e58ea555914bed433e Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@qt.io>
| | * iOS: Compute screen available geometry based on safe area insetsTor Arne Vestbø2017-11-301-0/+16
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In addition to the (deprecated) applicationFrame property, we base the available geometry on the root view's safe area, which also takes into account system-reserved areas on iPhone X, and the screen's bezel in the case of tvOS. Change-Id: I252d960a0e486dd0c7e30843f88c0bf5684feb24 Reviewed-by: Jake Petroules <jake.petroules@qt.io>
generated by cgit v1.2.3 (git 2.25.1) at 2024-05-09 14:46:39 +0000