summaryrefslogtreecommitdiffstats
path: root/src/plugins/platforms/ios
Commit message (Collapse)AuthorAgeFilesLines
...
* iOS: Ignore next touch event if keyboard has lost focus during touchAxel Spoerl2023-06-081-1/+5
| | | | | | | | | | | | | | | | If the iOS virtual keyboard as lost focus because it was slided down, the next touch event on an inactive screen area will be mapped to the keyboard. This kicks an assertion, because the keyboard is expected to be visible. The case that the keyboard has been deactivated by sliding it down is not covered. This patch replaces the assertion by setting self.enabled to NO, which reflects the keyboard deactivation. Fixes: QTBUG-112246 Pick-to: 6.6 6.5 6.2 Change-Id: I4873b7a702178acfd3cb8c988134facc050d642a Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
* iOS: Don't invalidate a11y whenever UI elements are added or removedTor Arne Vestbø2023-06-073-5/+14
| | | | | | | | | | | | | | | | | | | | | | | | | | | | The UIAccessibilityScreenChangedNotification will result in iOS resetting its state, focusing the first a11y element on the screen. We shouldn't tie clearing the a11y cache to this notification, as those are two separate actions. In the case of adding or removing individual elements, we still likely need to clear the cache, but can inform the system of the more granular UIAccessibilityLayoutChangedNotification to have it re-read the a11y tree. We still handle additions and removal of a11y elements with Window or Dialog roles as UIAccessibilityScreenChangedNotification, as these likely involve major UI changes. The implicit UIAccessibilityScreenChangedNotification on QIOSWindow destruction has been removed, as it's assumed iOS will automatically refresh its a11y tree when a UIWindow is destroyed, and in any case it's up to the individual clients of QAccessible to send the relevant QAccessibleEvent to inform about the situation. Pick-to: 6.6 6.5 Fixes: QTBUG-100094 Change-Id: If7d5cb961743e5ca97d45553b05ae5e92f82d275 Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@qt.io> Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
* Ignore removed/changed screens if no QIOSIntegration instance existsJan Moeller2023-04-181-0/+6
| | | | | | | | | | | | | | | | | | | | | | | QIOSTracker registers itself as handlers for system notifications about changes of the screen environment. If no QIOSIntegration instance exists, newly detected screens are not added to the list of known screens (see screenConnected()). This, in turn, will result in a crash if a screen is disconnected and removed in screenDisconnected() as it is not known to qtPlatformScreenFor() and the function returns a nullptr. Consider the QIOSIntegration also whenever a screen is "changed". This is more of a safety measure do avoid crashes for unknown screens. This situation occurs if an iOS device is used to mirror the display via AirPlay and no actual QGuiApplication exists, e.g. Qt is only embedded in a Framework. Pick-to: 6.5 6.2 Fixes: QTBUG-106701 Change-Id: Id778fc5afa7c284b0536ee02b1ba2c10321cc5b1 Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io> Reviewed-by: Lars Schmertmann <lars.schmertmann@governikus.de>
* Fix crash in QIOSTextResponderChristian Strømme2023-04-041-2/+6
| | | | | | | | | | | | | When a window that has focus is destroyed we can end up calling into nextResponder where the focus window is in the process of being destroyed, so make sure we have a window with a valid platform window before calling winId() Fixes: QTBUG-110019 Pick-to: 6.5 6.4 Change-Id: I704c3597b46e465ddf2605bdb71a21cb36cb2a26 Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@qt.io> Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
* QIOSFileEngineAssetsLibrary: bail out early on non-existing dirsTimur Pocheptsov2023-04-021-0/+12
| | | | | | | | | | | | | | | | | | | | QFileSelector::selectionHelper walks through the list of selectors (on iOS, on my phone it's ("ios", "iOS", "en_NO", "unix", "darwin")), creating paths and testing QDir::exists. This ends up in asset file engine trying to load asset for something like: "assets-library://assets/+iOS" etc. ALAssetsLibrary -assetForUrl: returns nil for such url and we start iterating through the assets library. On my phone (e.g.) this takes about ~6 seconds (to iterate through pictures/videos I have), so the image picker is dismissed ~30 seconds after an image was actually selected in a picker view, making an impression it's completely broken. Bail out early on such url, we know we'll fail (with AssetsLibrary giving a warning about invalid asset with UUID(null). Pick-to: 6.5 Fixes: QTBUG-109120 Change-Id: Ia302f4151e3aade830e647a8a260479df2b29d4b Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@qt.io>
* iOS: request authorization before presenting image-pickerTimur Pocheptsov2023-03-283-3/+43
| | | | | | | | | | | | | | | | | | | | | | | Right now, image picker view is shown first (it does not require access to photos, since it's essentially Photos app getting access to photos ...). Then, we use AssetsLibrary to get asset for an url (using ALAssetsLibrarie's -assetForURL method). This may trigger a permission-related alert, asking to: a. Select more photos or ... b. Allow access to all photos or ... c. Deny access. Showing this alert _after_ picker has selected an image makes little sense (and probably was never intended this way anyway). Instead, we now use Photos.framework to check the authorization and, if needed, we request an authorization (when the current status is 'Nondetermined'). If authorization is 'Granted' as a result, we show picker view and proceed as normal/before. Pick-to: 6.5 Task-number: QTBUG-109120 Change-Id: I0acfd7b0476346360d75a5e37f5845aaf2d6e3e0 Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@qt.io> Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
* Plumb QMessageBox::setCheckBox() through QPlatformMessageDialogHelperTor Arne Vestbø2023-03-091-1/+1
| | | | | | | | | | | | | | | | | | | | | | | Without this plumbing we have no way of knowing if the QMessageBox has a checkbox set, and can't decide to skip the native dialog, leaving the user without the expected checkbox. As the suppression checkbox on macOS can be customized, we can use this plumbing to actually provide native dialog support for generic check boxes. This mechanism can also be used by QErrorMessage, which now matches behavior between native and non-native dialogs in terms of the label of the checkbox and its initial state. We might want to tweak this in the future, since user's might expect the suppression label and state to match the system default, but that's something we can expose from the platform theme if so, and should apply equally to the non-native dialog. Fixes: QTBUG-111803 Pick-to: 6.5.0 6.5 Change-Id: Ied9fc34383fe79fbd8437592ad1c1993b9396178 Reviewed-by: Volker Hilsheimer <volker.hilsheimer@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>
* QIosFileDialog - properly handle QUrl for assets-libraryTimur Pocheptsov2023-02-151-3/+7
| | | | | | | | | | | | | | | For QT_PLATFORM_UIKIT 'PicturesLocation' manually appended by "assets-library://". When converted to QUrl, such a path becomes a valid url, having empty path and scheme "assets-library". Later in QIOSFileDialog we convert this path (options()->initialDirectory()) calling QUrl::toLocalPath, which gives us an empty string and thus we erroneusly select document picker dialog, not an image picker. So let's also check a scheme, not path only. Pick-to: 6.5 6.4 6.2 Fixes: QTBUG-107844 Change-Id: If4dd453549b37933cba07b5d7af6e45f2504dd29 Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@qt.io>
* Rename Qt::Appearance to Qt::ColorSchemeTor Arne Vestbø2023-02-133-8/+8
| | | | | | | | | | | | Based on discussions in the 6.5 API review, where we concluded that 'appearance' is too general. Instead, we follow the CSS standard and use the term 'color scheme'. Pick-to: 6.5 Change-Id: I8ceaf4138ecadff5ccd962480e8e5beb39b556ec Reviewed-by: Axel Spoerl <axel.spoerl@qt.io> Reviewed-by: Jonas Kvinge <jonas@jkvinge.net> Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
* src: Remove remains of qmake conversion from CMakeLists.txt filesFriedemann Kleint2023-02-103-23/+1
| | | | | | Pick-to: 6.5 Change-Id: Id644d322a602038403bb7f46c532744575fbf6d3 Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
* Clean up QUtiMimeConverter APIVolker Hilsheimer2023-02-081-3/+3
| | | | | | | | | | | | | Based on header review comments, make the internal constructor private and declare classes that need it as friends. QFlag-ify the HandlerScope enum, as it is a list of flags, and adjust code accordingly. Pick-to: 6.5 Change-Id: I1d8843265e49e696d463e9eea8306f4dbae75c78 Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
* iOS: Fix build with -no-openglTor Arne Vestbø2023-02-016-5/+27
| | | | | | Pick-to: 6.5 Change-Id: I014fa1772f629ef4224ac98bfc30eb5a86f38fde Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
* Enable shared library build of Qt for iOSTor Arne Vestbø2023-01-102-0/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | As of f68e2c92cc0ed2c1929140402c061359bc2363a5, and its follow up changes, we can now link individual plugins statically, even if the Qt build is generally a shared build. This allows us to build Qt for iOS as shared libraries, while still keeping the platform plugin as a static library, since this is harder to port over to a shared library. This gives the benefit of faster turnaround during development, as well as binary compatibility promises for the main Qt libraries, without having to go fully shared for all of Qt. Static builds are still the default, due to the downsides of larger application bundles and slower load times for shared builds. For now the user has to manually tick the "Embed & Sign" check box in Xcode for each Qt library, which is only available with Xcode projects generated by the qmake Xcode generator. Task-number: QTBUG-85974 Change-Id: Id2b7bd2823c8e7c79068dda95295b574ada8d7f2 Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io> Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
* iOS File Dialog: Allow picking files if name filter is '*' (all files)Doris Verria2022-12-201-1/+6
| | | | | | | | | | Name filters may be not empty and include all files ('*'). We should not add any file type limitations in this case. Ammends commit ce20b81070c8283a7895e46dd79d560fb0b81462 Pick-to: 6.5 Change-Id: I3983e576a0ada4b7b40837c5c797359114b1ae02 Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
* iOS: Don't assume screens will not be connected before QIOSIntegrationTor Arne Vestbø2022-12-161-2/+2
| | | | | | | | | | | | | | | | | | When an external screen is connected to an iPad, and the application is starting up on that screen, we will get a connection notification about that screen as part of the initial bootstrap of UIApplicationMain, before we call the user's main(). Since we initialize and add all available screen on QIOSIntegration creation, we can just ignore the early connection notification. This avoids a crash, but the window will not show anything on the external screen, which is a separate issue. Pick-to: 6.5 6.4 6.2 Fixes: QTBUG-106701 Change-Id: I9e0a9736bf602277316bd004e0d01c640feaf319 Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
* iOS File Dialog: Support setting name filtersDoris Verria2022-12-151-13/+45
| | | | | | | Fixes: QTBUG-93624 Pick-to: 6.5 Change-Id: I2e1b522d572fd36f58a3de90f0a685f5d22dfeeb Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
* iOS a11y: Ensure parent elements are stacked below their childrenTor Arne Vestbø2022-12-151-1/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | The accessibility system on iOS does not support elements that are both accessible themselves, and act as a container for other elements. You either return YES from isAccessibilityElement, which allows you to report accessible properties for the element, or NO, in which case you can implement the informal UIAccessibilityContainer protocol to report child elements. This was confirmed in Apple Q&A session on accessibility December 14. As Qt's accessibility system allow elements that are both containers and have properties of their own, we can't build a hierarchy of elements and containers, with only the leaf elements being accessible. Instead, we let each UIView act as a UIAccessibilityContainer, and report the entire child hierarchy as a single level of sibling accessible elements. In doing so, we include elements such as the Window or Dialog that root all the accessible elements. And apparently the order that we report these elements back to iOS determine the z-order of the elements, so we need to ensure "container" elements are behind their children. Otherwise assistive technologies such as Voice Control, or the Accessibility Inspector, will not be able to target the child elements. Fixes: QTBUG-108848 Pick-to: 6.2 6.4 6.5 5.15 Change-Id: I5234bab2f14d5f368ae8c2672b051efcb80aa77d Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
* iOS: initialize font traitsVolker Hilsheimer2022-12-121-1/+1
| | | | | | | | | Silences build-breaking compiler warning and probably fixes a bug. Pick-to: 6.4 6.2 Change-Id: Ice48657831ac1f8406f33ca7e3afa70556831274 Reviewed-by: Oliver Eftevaag <oliver.eftevaag@qt.io> Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
* Teach QErrorMessage to use native dialog helper if availableTor Arne Vestbø2022-12-041-0/+3
| | | | | | | | | | | And implement for macOS. The default modality of the QErrorMessage on macOS now depends on whether the dialog has a parent or not. The QErrorMessage must be hidden and re-shown again after each message, so that the native dialog has a chance to recreate itself. Change-Id: I474ed35d6271118834fac8e97f6f540a6fb89b8c Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
* Add QGuiApplication API to set a number-badge in the Dock/task barTor Arne Vestbø2022-12-022-0/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The API is supported on macOS, iOS, and Windows. On Android no official API exists for badging the application icon, and we don't want to take on dependencies like ShortcutBadger [1]. The macOS and iOS implementations are trivial. The same goes for the WinRT based implementation on Windows, but this API is only available for applications that have a so called "package identity", and does not seem to be stable for Windows 10. To cover the cases where this API is not available we fall back to drawing the badge manually, and set it as an overlay icon on the task bar using ITaskbarList3. The look of this badge has been tweaked to match the Windows 11/10 styles, and will pick up the user's choice of dark/light mode and accent color if available. [1] https://github.com/leolin310148/ShortcutBadger/ [ChangeLog][QtGui] Added QGuiApplication::setBadgeNumber() to inform the user about e.g. the number of unread e-mail or queued tasks. The badge will be overlaid on the application's icon in the Dock on macOS, the home screen icon on iOS, or the task bar on Windows. Task-number: QTBUG-94009 Change-Id: I6447d55177f9987b0dfcd93caf63c6167f7224c7 Reviewed-by: Axel Spoerl <axel.spoerl@qt.io> Reviewed-by: Oliver Wolff <oliver.wolff@qt.io> Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
* iOS plugin: Support picking folders for native file dialogDoris Verria2022-12-024-16/+12
| | | | | | Fixes: QTBUG-104375 Change-Id: Idbc9eb44abed5e3cd0dd768a08bf8132aba58f43 Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
* iOS plugin: Add native font dialogDoris Verria2022-12-024-0/+237
| | | | | | | | [ChangeLog][iOS] Added native font dialog support for iOS. Task-number: QTBUG-109059 Change-Id: If38e990e1c5e9fc1a303fce3e79c09c2d45daaa0 Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
* iOS plugin: Add native color dialogDoris Verria2022-11-304-0/+203
| | | | | | | | [ChangeLog][iOS] Added native color dialog support for iOS. Task-number: QTBUG-109042 Change-Id: I04187315d396d2f07b15eb4bd66b50253d873477 Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
* Reintroduce converter APIs for supporting native clipboard formatsVolker Hilsheimer2022-11-162-7/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In Qt 5, QWin(dows)Mime and QMacMime lived in the respective Extras modules, which were removed and partially folded into the relevant modules in Qt. QWindowsMime and QMacMime continued to provide the abstraction for implementing built-in support for native clipboard formats and UTIs within Qt, but only as private APIs. After the recent clean up of those APIs and respective infrastructure, we can now bring them back as public converter interfaces. Application developers can subclass those and instantiate an instance of their implementation to add support for platform or application specific data formats. These interfaces are not in the QNativeInterface namespace, as applications don't call into Windows or macOS using those interfaces. I.e. there is no class on which an application would call auto *converter= nativeInterface<QWindowsMimeConverter>(); Also, since applications override those converter types, we do want to guarantee binary and source compatibility. [ChangeLog][QtGui][QWindowsMimeConverter] Reintroduced to allow applications to add support for conversion from and to Windows-native clipboard formats to MIME-encoded data. [ChangeLog][QtGui][QUtiMimeConverter] Reintroduced to allow applications to add support for conversion from and to clipboard data on macOS and iOS to MIME-encoded data. Fixes: QTBUG-93632 Change-Id: Iebd909c3970015d203f59d5ab15e306b3d312f6e Reviewed-by: Yuhang Zhao <2546789017@qq.com> Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
* Make QMacMime::canConvert a non-virtual helper for other virtualsVolker Hilsheimer2022-11-091-8/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | Implementors are expected to return whether the converter can convert both ways between a mime and a uti. However, this is implied in the mimeForUti and utiForMime functions, and almost all converter implemented canConvert by returning mimeForUti(uti) == mime. A notable exception is the QMacMimeTypeName implementation, which can only convert from from mime to uti using hard-coded special format names and dummy data to provide place holders for drag'n'drop operations that originate in Qt. That converter returned always false from canConvert, but mapped the special "application/x-qt-mime-type-name" mime type to the special "com.trolltech.qt.MimeTypeName" uti. Since nobody ever requests data as "com.trolltech.qt.MimeTypeName", we still always ignore that converter. The uti is then special-cased in the QMacClipboard code. Lower-level code where only mime type or UTI are known can still call the virtuals directly and check whether the returned string is empty, which indicates that the converter does not support the conversion. As a drive-by, fix coding style and variable naming. Change-Id: I3d5d60faa82f8b31d9873c9da0097a308b9eeb50 Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@qt.io> Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
* QMacMime API cleanup: use uti instead of flavorVolker Hilsheimer2022-11-071-2/+2
| | | | | | | | Update documentation. Task-number: QTBUG-93632 Change-Id: I69a57608ba2a06211e89fcf511bc582509c00dc4 Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
* Standardize QMacMime and QWindowsMimeVolker Hilsheimer2022-11-071-2/+2
| | | | | | | | | Make name of virtual functions explicit, following the QWindowsMime API. Task-number: QTBUG-93632 Change-Id: I7ada2b1aa86bc6e28b47383a32ab9cbaf9ad93e5 Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
* macOS: Make QMacMime's handler scope type-safeVolker Hilsheimer2022-11-071-3/+3
| | | | | | | | | | | | | | | | | | The value indicates for which systems the handler is relevant, e.g. clipboard and/or drag'n'drop. Rename the enum from "MimeType", which is something else already, to "HandlerScope". Make the enum a scoped enum to avoid implicit conversion to uchar, and to allow for better value names. Use the type in APIs and only convert to uchar when needed. Make respective arguments default to both DnD and clipboard implicitly, instead of explicitly interpreting an invalid zero-value as a default value. Task-number: QTBUG-93632 Change-Id: I85ab982f6c9fe78ea4d030dd0b0791c8ab866f67 Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
* Rename QMacInternalPasteboardMime to QMacMimeVolker Hilsheimer2022-11-072-6/+5
| | | | | | | | | | | | | | | We want to make it public, and there is no need for "pasteboard" since it also coveres drag'n'drop. Add a default constructor that defaults to supporting both clipboard and drag'n'drop, and clean up the code by using that constructor where applicable. Historical note: the converter interface was called QMacMime up to Qt 4.2, when due to macOS changes it had to be replaced by QMacPasteboardMime. Task-number: QTBUG-93632 Change-Id: Id9712300039375aa6394598b104827e6f5d6c948 Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
* Refactor: split QMacMime registry and virtual interfaceVolker Hilsheimer2022-11-032-5/+7
| | | | | | | | | | | | | | | | The logic for registration of converter implementations is only used internally through static functions. Move those, and related global functions, to a QMacMimeRegistry namespace. Reduce the QMacInternalPasteboardMime to the abstract interface for converting between native and Qt clipboard data. Historically, mime converters can have different "types"; make that API type-safe. Task-number: QTBUG-93632 Change-Id: I0e16fefa350398b693486199fe10357fd84abcd6 Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
* QIOSMessageDialog::exec - work around 'windowsless' execTimur Pocheptsov2022-10-191-0/+20
| | | | | | | | | | | | | | | While the need for such scenario is arguable, we can imagine that some app first shows some message box (by calling QDialog::exec()), and then creates and shows the main UI/window/widget. Without such a widget, app's keyWindow is nil, its rootViewController is also nil and no alert is presented at all. To save the situation, we try hard and check the primary screen's uiWindow (using QIOSScreen::uiWindow) searching for any window and using its root view controller. Pick-to: 6.4 6.2 5.15 Fixes: QTBUG-79977 Change-Id: I9bf38bdf540f1f1dbe42b86df94d6a1b4694e9f2 Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
* QIosScreen: retain the right windowTimur Pocheptsov2022-10-181-1/+1
| | | | | | | | | | When initializing m_uiWindow (instead of trying to retain this window itself, which is harmless, since it's nil, but useless, since it's not the right window). Pick-to: 6.4 6.2 5.15 Change-Id: I7855fd7c24ebfc28fbb912966f8010caba914fe7 Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
* QIosTextResponder: stop using deprecated constants and typeTimur Pocheptsov2022-10-171-4/+4
| | | | | | | | Use NSWritingDirection and corresponding enumerators instead. Pick-to: 6.4 6.2 5.15 Change-Id: Ie76ec2b8d07ab70288c7071182f215412d3e133c Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
* QIosMenu - do not check -undo: and -redo: selectorsTimur Pocheptsov2022-10-171-2/+2
| | | | | | | | | | | | | With the latest Xcode 14 an attempt to 'Archive' and distribute an app to the App Store Connect ends with a strange warning: "App Store Connect operation Error The app references non-public selectors in Payload/appname.app/appname: redo:, undo:". Googling finds many similar reports and complains (with a bunch of different selectors suddenly reported as non-public). We filter out undo/redo instead, the selectors without parameters. Change-Id: I9667dc61f650f6b6ec42c64a9aa6fbff57fe5049 Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@qt.io>
* QIOSTheme: Set appearance based on UIScreen if no windows created yetDoris Verria2022-10-102-6/+19
| | | | | | | | | | | | | | | | | | | Set the theme's appearance based on the UIScreen's, which follows the app's or system's configuration, if no UIWindows are created yet. The UIWindow and UIScreen will have the same appearance (the traitCollection change is propagated hierarchically from screen to window) unless UIWindow's overrideUserStyleInterface is explicitly set to differ from that of the screen. In that case, traitCollectionDidChange will be called for the window (but not the screen) and when we update the palette calling the UIColor API, the colors will be resolved based on UITraitCollection.currentTraitCollection property, which follows the window's appearance. That is why we need to set the theme's appearance based on the window's. Change-Id: I43207f351559fb82efc2f281eafb3cd1c96bbf75 Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
* QIOSTheme: Get the appearance mode from the UIWindow's traitCollectionDoris Verria2022-09-291-1/+1
| | | | | | | | | | | | | | We were getting the appearance (light/dark) through the traitCollection of the UIWindow's rootViewController. It looks like this does not report the correct value when the appearance changes through System Settings. If we get it directly from the UIWindow's traitCollection property, it works as it should. Also, in traitCollectionDidChange: we are checking for changes in the traitCollection of the UIWindow's, not of the viewController's. Change-Id: I437e6922b268fd0069d80557a1034391ed52644b Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@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, input panel: be more careful before enabling QIOSKeyboardListenerRichard Moe Gustavsen2022-09-231-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The current implementation would assume that if we get a UIKeyboardWillShowNotification, the keyboard is about to show, and we should therefore enable the gesture. This is problematic on an iPad with a hardware keyboard connected, because we do actually get get a UIKeyboardWillShowNotification on startup, even when the standard input panel is not showing. From speculation, this is probably because there is a little floating menu at the bottom of the screen that lets you start dictation mode. And in UIKit, this is probably implemented as a UIKeyboard. This new input panel has a zero size, according to the UIKeyboardFrameEndUserInfoKey key in the notification. This means that we can still trust our own implementation of QIOSInputContext::isInputPanelVisible() to be false when a hardware keyboard is connected. This patch will therefore only enable the gesture if we understand the input panel to be visible, rather than automatically assume that it is based on the UIKeyboardWillShowNotification alone. This will also stop the assert inside touchesBegan from triggering. Fixes: QTBUG-106387 Pick-to: 6.4 6.2 5.15 Change-Id: Ia3d27864325b6efb49f03fb20b711979f2d07fbf Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
* Replace QPlatformTheme::Appearance by Qt:AppearanceAxel Spoerl2022-09-202-5/+5
| | | | | | | | | | | | | With the introduction of Qt:Appearance, its predecessor in QPlatformTheme has become redundant. This patch replaces all occurrences of QPlatformTheme::Appearance with the new enum class. Task-number: QTBUG-106381 Change-Id: I5406f1b7c19f68571f074617c681318c96a6517e Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io> Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
* Apply Q_CONSTINIT where beneficialSona Kurazyan2022-09-011-1/+1
| | | | | | | | | | Applied Q_CONSTINIT to variables with static storage duration, but skipped the POD types with core constant initializers. Task-number: QTBUG-100486 Change-Id: Iaabf824e9cb0f29a405a149912200d4e4b3573c1 Reviewed-by: Thiago Macieira <thiago.macieira@intel.com> Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
* Change the license of all CMakeLists.txt and *.cmake files to BSDLucie Gérard2022-08-233-3/+3
| | | | | | | Task-number: QTBUG-105718 Change-Id: I5d3ef70a31235868b9be6cb479b7621bf2a8ba39 Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Jörg Bornemann <joerg.bornemann@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>
* Rename QPlatformFontDatabase::handleAvailableFontsChanged()Tor Arne Vestbø2022-08-161-1/+1
| | | | | | | | | | | The function name was easy to mistake for a function you should call after adding fonts via e.g. registerFont or registerFontFamily, but in reality it's meant to be used when the platform font database knows that fonts have changed in a way that needs a full populate. Pick-to: 6.4 Change-Id: I4a897944aaa5df891562f729440b5d98b54f61e0 Reviewed-by: Eskil Abrahamsen Blomfeldt <eskil.abrahamsen-blomfeldt@qt.io>
* iOS: ensure we close inputpanel after clearing focusobjectRichard Moe Gustavsen2022-08-081-0/+9
| | | | | | | | | | | | | | | | Change 7f72622c0f caused a regression where the input panel would not close automatically when the focus object was cleared. The reason is that it's apparently not enough to just release the first responder, we also need to explicitly tell it to release it's first responder status. Before the failing patch, we did this from within update(). This patch will instead/in addition do an extra check from inside reset(). Fixes: QTBUG-105323 Pick-to: 6.4 6.3 6.2 5.15 Change-Id: I00bdd44fe54db69f44232226291e3c5715935749 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-054-40/+22
| | | | | | | | 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>
* Fix several more improperly placed #include mocThiago Macieira2022-08-044-8/+8
| | | | | | | | | | | | | Like commit qtbase/638893bea083b619b73b33a7dd5589fb2c4c4242. Script to find them: git grep -l '#include.*moc' \*.cpp \*.mm | \ xargs awk '/QT_BEGIN_NAMESPACE/ { i=1 } /QT_END_NAMESPACE/ { i=0 } /#include.*moc/ && i { print ARGV[ARGIND], $0 }' Pick-to: 6.4 Change-Id: I6f936da6f6e84d649f70fffd17058fd05cfc5c6d Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
* Add license headers to cmake filesLucie Gérard2022-08-033-0/+9
| | | | | | | | | | | | CMakeLists.txt and .cmake files of significant size (more than 2 lines according to our check in tst_license.pl) now have the copyright and license header. Existing copyright statements remain intact Task-number: QTBUG-88621 Change-Id: I3b98cdc55ead806ec81ce09af9271f9b95af97fa Reviewed-by: Jörg Bornemann <joerg.bornemann@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>
generated by cgit v1.2.3 (git 2.25.1) at 2024-04-19 15:49:14 +0000