summaryrefslogtreecommitdiffstats
path: root/src/plugins/platforms/ios
Commit message (Collapse)AuthorAgeFilesLines
* Use SPDX license identifiersLucie Gérard2022-05-1655-2090/+110
| | | | | | | | | | | | | 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>
* QIOSTextResponder: recreate responder upon resetRichard Moe Gustavsen2022-05-101-3/+16
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | Apple introduced UITextInteraction in iOS 13, which caused issues with our text handling, and resulted in e00d888daefb. This, again, seems to be the reason why UIKit in some cases simply removes the input delegate from our text responder. This typically happens after a QPlatformInputContext::reset(), and then when the next character is typed on the input panel (and hence, leaves no informative stack trace). The result of removing the input delegate, which is the interface that let's Qt communicate IM changes back to UIKit, leads Qt and the UIKit out of IM sync. E.g for a japanese keyboard, after a QPlatformInputContext::reset(), the Qt input field would remove the marked text, but UIKit would still show japanese characters based on what used to be marked text. To work around this issue, this patch will therefore recreate the text responder when Qt tells us to reset. This will cause the first responder to change, which will apparently also reset the UIKit IM state. Fixes: QTBUG-102960 Pick-to: 6.3 6.2 5.15 Change-Id: I00901e980874fae819cc7d89a68fa34ae44808c2 Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
* Plugins: replace remaining uses of QLatin1String with QLatin1StringViewSona Kurazyan2022-05-043-4/+4
| | | | | | | Task-number: QTBUG-98434 Change-Id: If64c294033c114ae46dfc327c40da7f3c7a598f5 Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Marc Mutz <marc.mutz@qt.io>
* Plugins: use _L1 for for creating Latin-1 string literalsSona Kurazyan2022-05-047-19/+31
| | | | | | | | | As a drive-by, fix qsizetype -> int narrowing conversion warnings for the touched lines. Task-number: QTBUG-98434 Change-Id: I7fadd3cf27ad099028d70f05956303e3af62c0f5 Reviewed-by: Marc Mutz <marc.mutz@qt.io>
* QIOSTextResponder: restore reset/commit logicRichard Moe Gustavsen2022-04-282-0/+14
| | | | | | | | | | | After 2211092aa5, parts of the reset/commit logic was left out by a mistake. This patch will add the missing lines back into the text responder. Task-number: QTBUG-102960 Pick-to: 6.3 Change-Id: Ib339eae2af69ce088e251fe8571bed97bbd64fc3 Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
* Send ThemeChange event to all windows when system theme changesTor Arne Vestbø2022-04-221-1/+1
| | | | | | | | | | | | | | | | | | | The QWSI event for theme change has an optional window parameter to specify the window affected, but most platform react to global theme changes, and end up passing nullptr into the event. The reasonable thing to do in QGuiApplication in that case is send a theme change event to every QWindow, so that they are all notified about the situation. This approach is what the Windows platform plugin was doing already, but did so by iterating manually over the windows, resulting in multiple calls to QGuiApplicationPrivate::handleThemeChanged -- one for each QWSI event. Change-Id: Ifb27b6c31231377c0df389a592cafd0075d3d8bb Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io> Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
* iOS: Handle changes in user font preferences by invalidating font databaseTor Arne Vestbø2022-03-302-0/+9
| | | | | | | | | | | | | | | | | | | | The user may tweak the appearance of text rendering on iOS to aid a11y, by making the text larger or smaller, or bold. This feature, known as Dynamic Type, will be reflected in the preferred content size category of the application. When we detect changes in this preferred content size category we respond by invalidating the font database, which will trigger the application to re-evaluate the sizes and weights of the theme fonts. Unfortunately we do not currently pick up or propagate the scaled font metrics when an explicit point or pixel size has been set on a QFont, but this problem exists regardless of whether we dynamically handle changes to dynamic types or only pick them up after an application restart. Change-Id: I8c722d0bfb4b76eade47ebfb6512e6676a910d6a Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
* CoreText: Make population of theme fonts explicitTor Arne Vestbø2022-03-301-1/+1
| | | | | | Pick-to: 6.2 6.3 Change-Id: I95e6b535e8ec98ca13c9a58f1e4ae4358ed9f028 Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
* Implement QPlatformTheme::appearance() for iOSDoris Verria2022-03-292-0/+15
| | | | | | | | | | | Implement support for detecting Light/Dark mode on iOS. This is needed by the QQuickIOSStyle in order to display the proper image assets according to the theme. A further improvement would be to react to theme changes dynamically. Change-Id: I95e11c4a4b647614bdd78d734941d2b11546687a Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
* iOS A11Y: Do not add children of invisible parentMike Achtelik2022-03-281-1/+1
| | | | | | | | | | Prevent children from invisible parents from showing up in the a11y hierarchy. This fixes a problem on iOS which e.g. always adds hyperlink children of QML Text items, even if the Item itself is invisible. Pick-to: 6.3 6.2 Change-Id: I88a6f08956b5fe78cb789a08f2078f96d7aa263c Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
* iOS A11Y: Set more accessibilityTraitsMike Achtelik2022-03-251-0/+11
| | | | | | | | | | Set traits for roles that have a direct mapping between QAccessible::Role and UIAccessibilityTraits. This allows the screen reader to pick up on them and give additional info e.g. for links. Pick-to: 6.3 6.2 5.15 Change-Id: I0f85e525fef390dcdf1ea664a0d325ce54f5b25b Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
* CoreText: Maintain theme fonts in the font database instead of themesTor Arne Vestbø2022-03-232-9/+3
| | | | | | | | | | | | | | | | | | The ownership of the fonts were handled in the iOS and macOS themes, but the CoreText font database also kept a reference to these fonts. As there was no way for the themes to reset the font database references we could potentially end up in a situation where the font database had stale references. And as the font database would not rebuild the theme fonts once populated the themes then would not be able to build a new list of theme fonts. Moving the ownership to the font database makes semantics and management of the fonts clearer. Pick-to: 6.3 6.2 Change-Id: I61756abaf5487f28d520dfa1cf7a8ee2d716cce6 Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
* Misc: Do not depend on transitive includesFabian Kosmale2022-03-171-0/+1
| | | | | | | | As a drive-by, remove superfluous includes from qnetworkmanagerservice.h and obey the coding conventions for includes in a few more places. Change-Id: I65b68c0cef7598d06a125e97637040392d4be9ff Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* Compose render-to-texture widgets through QRhiLaszlo Agocs2022-03-115-161/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | QPlatformTextureList holds a QRhiTexture instead of GLuint. A QPlatformBackingStore now optionally can own a QRhi and a QRhiSwapChain for the associated window. Non-GL rendering must use this QRhi everywhere, whereas GL (QOpenGLWidget) can choose to still rely on resource sharing between contexts. A widget tells that it wants QRhi and the desired configuration in a new virtual function in QWidgetPrivate returning a QPlatformBackingStoreRhiConfig. This is evaluated (among a top-level's all children) upon create() before creating the repaint manager and the QWidgetWindow. In QOpenGLWidget what do request is obvious: it will request an OpenGL-based QRhi. QQuickWidget (or a potential future QRhiWidget) will be more interesting: it needs to honor the standard Qt Quick env.vars. and QQuickWindow APIs (or, in whatever way the user configured the QRhiWidget), and so will set up the config struct accordingly. In addition, the rhiconfig and surface type is (re)evaluated when (re)parenting a widget to a new tlw. If needed, this will now trigger a destroy - create on the tlw. This should be be safe to do in setParent. When multiple child widgets report an enabled rhiconfig, the first one (the first child encountered) wins. So e.g. attempting to have a QOpenGLWidget and a Vulkan-based QQuickWidget in the same top-level window will fail one of the widgets (it likely won't render). RasterGLSurface is no longer used by widgets. Rather, the appropriate surface type is chosen. The rhi support in the backingstore is usable without widgets as well. To make rhiFlush() functional, one needs to call setRhiConfig() after creating the QBackingStore. (like QWidget does to top-level windows) Most of the QT_NO_OPENGL ifdefs are eliminated all over the place. Everything with QRhi is unconditional code at compile time, except the actual initialization. Having to plumb the widget tlw's shareContext (or, now, the QRhi) through QWindowPrivate is no longer needed. The old approach does not scale: to implement composeAndFlush (now rhiFlush) we need more than just a QRhi object, and this way we no longer pollute everything starting from the widget level (QWidget's topextra -> QWidgetWindow -> QWindowPrivate) just to send data around. The BackingStoreOpenGLSupport interface and the QtGui - QtOpenGL split is all gone. Instead, there is a QBackingStoreDefaultCompositor in QtGui which is what the default implementations of composeAndFlush and toTexture call. (overriding composeAndFlush and co. f.ex. in eglfs should continue working mostly as-is, apart from adapting to the texture list changes and getting the native OpenGL texture id out of the QRhiTexture) As QQuickWidget is way too complicated to just port as-is, an rhi manual test (rhiwidget) is introduced as a first step, in ordewr to exercise a simple, custom render-to-texture widget that does something using a (not necessarily OpenGL-backed) QRhi and acts as fully functional QWidget (modeled after QOpenGLWidget). This can also form the foundation of a potential future QRhiWidget. It is also possible to force the QRhi-based flushing always, regardless of the presence of render-to-texture widgets. To exercise this, set the env.var. QT_WIDGETS_RHI=1. This picks a platform-specific default, and can be overridden with QT_WIDGETS_RHI_BACKEND. (in sync with Qt Quick) This can eventually be extended to query the platform plugin as well to check if the platform plugin prefers to always do flushes with a 3D API. QOpenGLWidget should work like before from the user's perspective, while internally it has to do some things differently to play nice and prevent regressions with the new rendering architecture. To exercise this better, the qopenglwidget example gets a new tab-based view (that could perhaps replace the example's main window later on?). The openglwidget manual test is made compatible with Qt 6, and gets a counterpart in form of the dockedopenglwidget manual test, which is a modified version of the cube example that features dock widgets. This is relevant in particular because render-to-texture widgets within a QDockWidget has its own specific quirks, with logic taking this into account, hence testing is essential. For existing applications there are two important consequences with this patch in place: - Once the rhi-based composition is enabled, it stays active for the lifetime of the top-level window. - Dynamically creating and parenting the first render-to-texture widget to an already created tlw will destroy and recreate the tlw (and the underlying window). The visible effects of this depend on the platform. (e.g. the window may disappear and reappear on some, whereas with other windowing systems it is not noticeable at all - this is not really different from similar situtions with reparenting or when moving windows between screens, so should be acceptable in practice) - On iOS raster windows are flushed with Metal (and rhi) from now on (previously this was through OpenGL by making flush() call composeAndFlush(). Change-Id: Id05bd0f7a26fa845f8b7ad8eedda3b0e78ab7a4e Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
* QIOSFileDialog/QIOSDocumentPickerController - handle dismissed view controllerTimur Pocheptsov2022-03-052-1/+18
| | | | | | | | | | | | | | | | | | When we use a native view controller for selecting documents, we have two methods to implement from UIDocumentPickerDelegate (a file was selected or the selection was cancelled). Unfortunately, swiping a view away was not handled, so neither 'accept' nor 'reject' was called. Depending on the classes using QIOSFileDialog, this may leave them in some incorrect state, not knowing that they are 'closed' anyway. As suggested by Tor Arne, the solution is to implement UIAdaptivePresentationControllerDelegate's method, namely -presentationControllerDidDismiss:, which never gets called if the controller was dismissed programatically (the case of accept/reject). Pick-to: 6.3 6.2 5.15 Fixes: QTBUG-93505 Change-Id: I28404aa280465ef8eb0f5c26c8c2e4e4a6c66641 Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
* QAbstractFileEngine: Add permission argument to open()Ievgenii Meshcheriakov2021-12-042-2/+5
| | | | | | | | | The new argument allows atomic creation of files with non-default permissions. Task-number: QTBUG-79750 Change-Id: I4c49455b41f924ba87148302c8d0f77f5de0832b Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
* QIOSTextInputOverlay: listen for selection changes, also for Qt::ImReadOnlyRichard Moe Gustavsen2021-11-111-4/+28
| | | | | | | | | | | | | The focus object can emit selection updates (e.g from mouse drag), and accept modifying it through IM when dragging on the handles, even if it doesn't accept text input and IM in general (and hence return false from inputMethodAccepted()). This is typically the case for read-only text fields. So we should listen for selection changes and enable handles also for this case (unless the IM hints tells us explicitly not to use handles/edit menu). Fixes: QTBUG-91545 Change-Id: I2855505fc229e954b2c43f5e11374e64bba7eb4e Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
* QIOSInputContext: use QIOSResponder when the focus object is Qt::ImReadOnlyRichard Moe Gustavsen2021-11-111-4/+11
| | | | | | | | | | | | | | | | | | | | | | | | | | In Qt, Qt::ImEnabled means that the focus object accepts text input from input method (IM) events. But the IM API also contains API for dealing with text selections. Text input and text selections are logically two different operations, but since IM makes use of selections to implement text input (like selecting a word to suggest a spelling correction), it's understandable that they are combined into to same API. So when a focus object reports Qt::ImEnabled to be false, it only means that it doesn't accept input. E.g a TextArea in QML with "readOnly:true" will set Qt::ImEnabled to false. At the same time, it can have "selectByMouse:true", which lets you select text with the mouse. This behavior is consistent in Qt, for both Quick, Controls 2 and Widgets. Since we want to support any selections done in controls/widgets on iOS with selection handles and edit menus, regardless if the focus object accepts input or not, this patch will set the QIOSResponder (with read-only actions) as first responder when we detect a focus object with Qt::ImReadOnly. This means that if a query for Qt::ImReadOnly returns "true", we take that to mean that it implements the IM API, but without accepting input. Task-number: QTBUG-91545 Change-Id: I07349909a3bca81f484a2e9af9672428dca62c49 Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
* QIOSTextInputResponder: factor out the "read-only" part to a ↵Richard Moe Gustavsen2021-11-115-136/+223
| | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* iOS: Hide UIWindow before restoring mirror modeTor Arne Vestbø2021-11-041-1/+1
| | | | | | | | | | Doing it the opposite way, by associating the new screen first, will result in the external screen not going back to mirroring the main display. Pick-to: 6.2 5.15 Change-Id: I63970380fc4f0902af5032043809a9c1b1f9f95b Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
* iOS: Defer restoring screen mirroring until next runloop passTor Arne Vestbø2021-11-041-3/+7
| | | | | | | | | | | | | | | Associating the UIWindow with a different screen will trigger layout of the child views of the window, including the view that we're in the process of removing, which doesn't have a platform window anymore. Instead of protecting every possible code path in the view code with checks for a platform window we defer the restoring of mirror mode until after the view has been removed. Pick-to: 6.2 5.15 Task-number: QTBUG-94530 Change-Id: I8c66106cafa67e06721e621c019b2d10acf02326 Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
* iOS: Don't try to initialize a11y for views that have no platform windowTor Arne Vestbø2021-11-041-0/+5
| | | | | | | | | | The window may have been destroyed, but the UIView may still be be referenced and kept alive by the a11y subsystem. Pick-to: 6.2 5.15 Task-number: QTBUG-94530 Change-Id: I24f1c9d45e80c1bb4c92536e7f91533a94fd077f Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
* QAbstractFileEngine: Remove useless method overridesIevgenii Meshcheriakov2021-11-032-6/+0
| | | | | | | | | | | | Remove useless overrides of QAbstractFileEngine methods from the derived classes. Also remove "This virtual function must be reimplemented by all subclasses" passages from the QAbstractFileEngine's documentation. There are pure virtual methods for such use cases. QAbstractFileEngine already contains useful defaults for classes not supporting all the functionality. Change-Id: Ia25965854f3809b15d7502da3749cc2f3414bbc3 Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
* QFactoryLoader: continue the port from JSON to CBORThiago Macieira2021-10-202-2/+4
| | | | | | | | | | | | | | This continues the effort from the previous commit, by not passing through the JSON conversion at all, and simply using CBOR directly. The port in qtbase is complete, but in order to support the conversion in other modules without introducing breakages, there's a temporary class used for converting to QPluginParsedMetaData from QJsonObject. It'll be removed once all other modules have finished converting. Change-Id: I2de1b4dfacd443148279fffd16a3ed4ddaf34afc Reviewed-by: Lars Knoll <lars.knoll@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>
* Adapt the implementation of QDesktopService on iOS to AndroidLars Schmertmann2021-09-101-6/+4
| | | | | Change-Id: I8c2048155c5c065b5cdf7ad4cef9d8a446a0561d Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
* CMake: Fix plugin target names to end in Plugin suffixAlexandru Croitor2021-08-121-2/+3
| | | | | | | Pick-to: 6.2 Task-number: QTBUG-95731 Change-Id: I56a34dd26656613c95fbc8f081d39561cb691852 Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
* CMake: Rename qt6_add_plugin TYPE option to PLUGIN_TYPEAlexandru Croitor2021-08-062-2/+2
| | | | | | | | | | | | | The intention is to remove TYPE as a keyword completely before 6.2.0 release, but in case if that's not possible due to the large amount of repositories and examples, just print a deprecation warning for now and handle both TYPE and PLUGIN_TYPE. Task-number: QTBUG-95170 Pick-to: 6.2 Change-Id: If0c18345483b9254b0fc21120229fcc2a2fbfbf5 Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
* Shift iOS a11y translations into C++ fileMike Achtelik2021-08-044-1/+122
| | | | | | | | | | | lupdate cannot parse .mm files. Therefore tr markup must be inside of C++ files. This copies the same approach qtconnectivity uses, see 6b2fd04b7be4494767b6092a030607010d91310c Pick-to: 6.2 Change-Id: I9853864b4b81b48da763a387c78c102857f23047 Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io> Reviewed-by: Kai Koehne <kai.koehne@qt.io>
* iOS: cleanup connection when a screen disconnectsRichard Moe Gustavsen2021-06-161-1/+3
| | | | | | | | | | | | | | | | The iOS port creates one QIOSViewController per connected screen. And each view controller listens for changes to the application state. The problem is that we never disconnect this connection again. So if a screen is removed, and the corresponing view controller is deallocated, the connection is still kept alive. This will cause crashes to occur when the signal emits, since the slot will then be accessing deleted memory. Fixes: QTBUG-76948 Pick-to: 6.2 6.1 5.15 Change-Id: I758e51af9297cd62de193aae825f4475a2c7c3e5 Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
* iOS: Accessibility: Set the correct traits for EditableTextAndy Shaw2021-05-141-1/+9
| | | | | | | | | | | | Since the correct accessibility traits for EditableText are not available as a direct enum value, then we depend on the defaults for a UITextField to give us this information. Done-with: Tor Arne Vestbø <tor.arne.vestbo@qt.io> Fixes: QTBUG-93494 Pick-to: 6.1 5.15 5.12 Change-Id: If428414aec5ce571f0f8c0ecccffdbaf1c908120 Reviewed-by: Morten Johan Sørvig <morten.sorvig@qt.io>
* iOS: Accessibility: Don't cut off the last character from the text valueAndy Shaw2021-05-071-2/+1
| | | | | | | | | | | The second parameter is the position of the first character not to be returned when calling text(). So it needs to be passed the length of the text, otherwise the last character is cut off. Task-number: QTBUG-93494 Pick-to: 6.1 5.15 5.12 Change-Id: I7dd8324b3939220de125ba819b7b77588b21bd4b Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
* iOS: Keep undo/redo widgets enabled on the undo shortcut bar after undoTamás Martinec2021-05-051-1/+14
| | | | | | | | | | | Having two undo/redo operations on the rebuilt undo stack always enables the undo/redo widgets on the shorcut bar. This might be more desirable than the current behavior that only allows one undo from the shortcut bar. Pick-to: 6.1 6.0 5.15 Fixes: QTBUG-63393 Change-Id: I2c99f27895def47b58534035461ceb7b4e5c3057 Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@qt.io>
* iOS: Implement QIOSScreen::logicalBaseDpi()Morten Sørvig2021-05-032-2/+2
| | | | | | | | | | | | | | | logicalDpi() and logicalBaseDpi() should return the same DPI on iOS, in order to make Qt not apply a scale factor. Accomplish this by overriding logicalBaseDpi() instead of logicalDpi(). The default QPlatformScreen::logicalDpi() implementation will then call logicalBaseDpi(). Pick-to: 6.1 Fixes: QTBUG-92579 Change-Id: I7a27cf61f0154cef32098069ab3dfb29ad6acf27 Reviewed-by: Morten Johan Sørvig <morten.sorvig@qt.io>
* iOS: Protect against a possible crash after the window is deletedAndy Shaw2021-03-292-1/+3
| | | | | | | | | | | | | | | | | If we are in a case where the original window is deleted before a new one is shown then we need to make sure that we are not still expecting that the original one has the focus. So we protect against the crash by only outputting the address of the object that previously had focus. A follow-up patch will be done for inclusion from 6.2 that will fix the root cause of the pointer being invalid when the only window is deleted before a new one is shown. Fixes: QTBUG-92173 Pick-to: 6.1 6.0 5.15 Change-Id: Ifdb3fd6b6cb8fb8e8b79d2c325a30c27b298d8a9 Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
* Include minus sign in ImhFormattedNumbersOnly's available keysEdward Welbourne2021-03-161-3/+1
| | | | | | | | | | | | | | UIKeyboardTypeDecimalPad only provides digits and decimal point, no minus sign, but ImhFormattedNumbersOnly is documented to provide a minus sign as well. UIKeyboardTypeNumbersAndPunctuation includes punctuation, which should cover signs as well as decimal separator, so use that - same as for ImhPreferNumbers. A little more permissive than we want here, but that's better than more restrictive ! Fixes: QTBUG-91455 Pick-to: 6.1 6.0 5.15 Change-Id: I0418946014e0a66d503e61704154fd7798a0b785 Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
* cmake: Don't give plugins PUBLIC usage requirementsCraig Scott2021-02-242-4/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | The pro2cmake.py conversion script faithfully reproduced the .pro files for the plugins, which specified the libraries as public. But in CMake, the implications of this are that public usage requirements should then be propagated to consumers. We don't expect any consumers, since a plugin is created as a MODULE library in CMake, so for Windows we don't even have an import library to link with. The only exception to this is for static builds where plugins are created as STATIC libraries instead, but only in certain controlled situations do we then link to plugins. Even then, usage requirements are not expected to propagate to the consumers, so these relationships should always be specified as private. This change warns on any PUBLIC usage requirements specified for a plugin. This check is disabled by default to avoid spamming CI builds for repos that haven't been fixed yet. The check can be enabled by a CMake cache option, which is intended for developers to use locally when fixing this issue in other repos (all plugins in qtbase should not trigger this warning as a result of changes in this commit). Task-number: QTBUG-90819 Pick-to: 6.1 Change-Id: I09f2c8da77db1193ad3370f85d367dfc6ab7b9a6 Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Joerg Bornemann <joerg.bornemann@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: close edit menu upon focus transferRichard Moe Gustavsen2021-02-051-0/+3
| | | | | | | | | | | | | | | | If you select text, the edit menu will show. But if you tap directly inside another input field, and as such, transfer focus, the menu will continue to stay visible. This patch will ensure that we hide the edit menu when the input field that it was requested for looses focus. Pick-to: 6.0 6.1 5.15 Fixes: QTBUG-90937 Change-Id: I1d97bd57fc793826a3170404795b06a1e058d1b7 Reviewed-by: Morten Johan Sørvig <morten.sorvig@qt.io>
* iOS: don't report selection changed if it didn't changeRichard Moe Gustavsen2021-02-041-1/+5
| | | | | | | | | | | | | | | | | | Be more careful about reporting a new selection to Qt. The code for handling IM selection events in QQuickTextArea is quite complex and need to take pre-edit text into account. The latter means that when the pre-edit text changes, as a result of the user composing a word, the width of the pre-edit text will also change (and as such, the cursor rectangle). But the cursor position itself stays the same. And for this reason, it emits cursorRectChanged more often than strictly needed. But rather than trying to clean that up, we do some extra checking before we send the IM event from QPA in the first place. Pick-to: 6.0 6.1 5.15 Fixes: QTBUG-63018 Change-Id: I689d989c3fe5d61ef2b1dbee7a70418b7790bce9 Reviewed-by: Andy Shaw <andy.shaw@qt.io>
* iOS: hide edit menu if typing on the input panelRichard Moe Gustavsen2021-02-041-4/+8
| | | | | | | | | | | | | | | | On iOS, if you select some text, the edit menu will show on top of it. And if you tap on the screen (or inside the menu) it will hide. But if you type on the input panel, it will stay open. This is wrong. This patch will keep better track of whether or not the edit menu was opened by us, and if it was, ensure we close it also if the cursor moves by typing on the input panel. Pick-to: 6.0 6.1 5.15 Fixes: QTBUG-90860 Change-Id: I0a51382030560182e7925c8b694b42e50943514e Reviewed-by: Morten Johan Sørvig <morten.sorvig@qt.io>
* iOS: Use new QPlatformInputContext geometry APIMorten Sørvig2021-02-013-25/+22
| | | | | | | | This enables support for QT_SCALE_FACTOR on iOS. Fixes: QTBUG-74978 Change-Id: Ibcf0741c178e44802065e472e096a5f4c7d6f3cf Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@qt.io>
* iOS: always hide edit menu when showing the magnifier glassRichard Moe Gustavsen2021-02-011-6/+1
| | | | | | | | | | | | | | | | | | | Bug: If you do a press and hold on a line edit, the edit menu will show to let you select a word etc. If you now do another press and hold to bring back the magnifier glass, the edit menu will stay open while you move the magnifier glass. This patch will ensure that we always hide the edit menu when we show the magnifier. There is never a case where both of them should show at the same time. By hiding the menu from the place where we show the magnifier means that we can remove code from the QIOSSelectionRecognizer that used to do this for one of the cases from before. Pick-to: 6.0 5.15 Fixes: QTBUG-90743 Change-Id: If2a92f94422c730c2b223129d96f5bc3bf3deeee Reviewed-by: Morten Johan Sørvig <morten.sorvig@qt.io>
* iOS: ensure we close the edit menu when the user taps outside the input areaRichard Moe Gustavsen2021-01-201-32/+50
| | | | | | | | | | | | | | | | | | | | | | | iOS used to close the edit menu automatically when the user tapped on the screen (even for menus shown explicitly using the UIMenuController API). Apperently this has now changed (probably as a part of [UIMenuController setMenuVisible:] being deprecated in iOS 13). So we now need to hide it explicitly. Because of this, we no longer close the edit menu if the user taps outside the input area. This patch will fix this by updating the logic in QIOSTapRecognizer to close the menu explicitly. There are some more details around when to show or hide the menu, which is commented on at the relevant places directly in the patch. Pick-to: 6.0 5.15 Fixes: QTBUG-90332 Change-Id: I336e3f4003817b39c7abf63f963fde1f3ef87c20 Reviewed-by: Morten Johan Sørvig <morten.sorvig@qt.io>
* iOS: ensure we hide the edit menu while dragging on the selection handlesRichard Moe Gustavsen2021-01-201-0/+9
| | | | | | | | | | | | | | | | | | | | iOS used to close the edit menu automatically when the user tapped on the screen (even for menus shown explicitly using the UIMenuController API). Apperently this has now changed (probably as a part of [UIMenuController setMenuVisible:] being deprecated in iOS 13). So we now need to hide it explicitly instead. Because of this, the edit menu would be showing together with the magnifier class while the user was dragging on any of the handles. This patch will fix this, so that we close the edit menu explicitly whenever the user starts dragging on a handle. Pick-to: 6.0 5.15 Fixes: QTBUG-80298 Change-Id: Iff2032d64db1b582fa7f048c6a1f37ec8a1528af Reviewed-by: Morten Johan Sørvig <morten.sorvig@qt.io>
* iOS: Handle keyboard events when using an external keyboardAndy Shaw2021-01-204-8/+75
| | | | | | | | | | | | | | | | | | 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>
* Remove .prev_CMakeLists.txt filesJoerg Bornemann2021-01-122-94/+0
| | | | | | | | | | Those serve no purpose anymore, now that the .pro files are gone. Task-number: QTBUG-88742 Change-Id: I39943327b8c9871785b58e9973e4e7602371793e Reviewed-by: Cristian Adam <cristian.adam@qt.io> Reviewed-by: Edward Welbourne <edward.welbourne@qt.io> Reviewed-by: Kai Koehne <kai.koehne@qt.io>
* Remove the qmake project filesJoerg Bornemann2021-01-074-109/+0
| | | | | | | | | | | | | | | | Remove the qmake project files for most of Qt. Leave the qmake project files for examples, because we still test those in the CI to ensure qmake does not regress. Also leave the qmake project files for utils and other minor parts that lack CMake project files. Task-number: QTBUG-88742 Change-Id: I6cdf059e6204816f617f9624f3ea9822703f73cc Reviewed-by: Edward Welbourne <edward.welbourne@qt.io> Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Kai Koehne <kai.koehne@qt.io>
generated by cgit v1.2.3 (git 2.25.1) at 2024-06-25 12:25:59 +0000