summaryrefslogtreecommitdiffstats
path: root/src/plugins/platforms/ios
Commit message (Collapse)AuthorAgeFilesLines
* iOS: Report correct physical DPI for iPhone 7 PlusTor Arne Vestbø2016-10-141-2/+2
| | | | | | Task-number: QTBUG-56509 Change-Id: Ibae94262c2a4c917aeca00cb1a1c28e5ae60f0c4 Reviewed-by: Jake Petroules <jake.petroules@qt.io>
* iOS: (crash fix) ensure we don't clear focus object in a text responder ↵Richard Moe Gustavsen2016-09-301-1/+1
| | | | | | | | | | | | | | transition (Backport of 5.7/8586ccc). The original patch was implemented to handle crashes after e78ca787ae459f. But the former was pushed to 5.7, and the latter to 5.6. So we need to backport it, otherwise the same crashes will still happen in 5.6 (e.g when transferring focus from a text edit to a (picker) menu). Change-Id: I13037735dc316bceadb571e67f38a310c8a1bfae Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@theqtcompany.com>
* iOS: hide shortcuts bar on iPad when showing menusRichard Moe Gustavsen2016-09-303-0/+13
| | | | | | | | | | | | | | On iPad, a shortcuts bar with extra controls are shown on top of the keyboard with opertions like cut and copy. This is unwanted when using the keyboard to show menus. This patch will add extra private information to IM platform data when using menus, so that we hide the shorcuts menu when showing the custom input panel. Task-number: QTBUG-49893 Change-Id: Iaa8e1ff18acebec8be69699b3fd9470c69ab34d7 Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@theqtcompany.com>
* iOS: open menu on popup regardless of visibilityRichard Moe Gustavsen2016-09-191-2/+5
| | | | | | | | | | It should be possible to show a menu by calling showPopup, even if visible is set to false. After all, it's only logical that visibility is false before showing it. And whether or not the menu is enabled should not matter as well. Change-Id: I9a2b453c8c6e88c47812c652d99e4b4a9c7524a7 Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@theqtcompany.com>
* iOS: explicit synthesize properties as readwriteRichard Moe Gustavsen2016-09-191-0/+4
| | | | | | | | | | | | | | | | | | | | | | | The synthesized properties were defined as (read only) methods in the UIViewController API in iOS9, and we extended them into readwrite properties in our own sub class to enable some local bookkeeping in addition to normal overriding. But in iOS10, Apple has changed the methods into being readonly properties instead. The difference then is that automatic property synthesizing will ignore our local readwrite declarations, and use the declarations in the super class instead. And this will lead to a runtime crash on iOS10 since no setter methods are generated. This patch will instead explicit synthesize the affected properties to ensure that both getters and setters will be generated. Change-Id: Iac330e991b8a0fe335e383e1f7d9ff30c0ce1559 Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@theqtcompany.com>
* iOS: let quiview conform to API signature changes in iOS 10Richard Moe Gustavsen2016-09-192-2/+3
| | | | | | | | | | | | | | In the iOS 10 SDK, method signatures has been annotated with NS_ASSUME_NONNULL macros and 'nullable' keywords. This means that certain methods should not be called with argumens that can be null, or in this case, set to 0 explicitly. The result will be compiler warnings. This patch will rewrite the explicit call we do to touchesCancelled so that we send an empty set instead of 0. Change-Id: I50aa80b91312397d17e0e380815adff87cee852b Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@theqtcompany.com>
* Fix warning: 'UITextInputTextFontKey' is deprecatedJake Petroules2016-08-241-1/+1
| | | | | | | first deprecated in iOS 8.0 - Use NSFontAttributeName instead Change-Id: I763efc498644ac234a712ebcefd07111b4444c98 Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@qt.io>
* UIKit: Treat windows as exposed only during Qt::ApplicationStateActiveTor Arne Vestbø2016-06-212-21/+6
| | | | | | | | | | | | | We previously treated Qt::ApplicationStateInactive as a valid state to expose windows in, to prevent a visible flash of black screen at app startup between iOS hiding the launch screen and Qt drawing it's first frame, but this lag is no longer an issue, so we can apply the best practice of only rendering during Qt::ApplicationStateActive. This may prevent crashes during application suspension. Task-number: QTBUG-52493 Change-Id: I271281ed6fb857e6849cdb88cc2d8251d1bba1df Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@qt.io>
* UIKit: Detect swapBuffers on non-exposed windows and skip flushTor Arne Vestbø2016-06-171-0/+5
| | | | | | | | | | | When using threaded rendering the render-thread might be half-way into rendering a frame when the application is backgrounded, resulting in the following swap happening on a non-exposed window. This may result in the system killing the application, as rendering is not supposed to happen when an application is backgrounded, so we skip the flush. Change-Id: I9ab8f2c4617391fd827558af9fb473f1734b3688 Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@qt.io>
* UIKit: Ensure that Qt's application state is initialized at startupTor Arne Vestbø2016-06-172-95/+46
| | | | | | | | | | | | | | | Using dispatch_async to deliver the initial application state at startup was broken, as that would leave the application in the default application state, inactive, until the next runloop pass. This became a problem when an application was started backgrounded, eg. in response to location updates or a Bluetooth accessory waking it up, as it would have a small window of time at startup where it would think it was able to render content (since the window was exposed), while in fact the application was running in the background. iOS will in these situations kill the app for doing background rendering. Change-Id: I1ab4a6af08a154d8625c6451b4b5c8f4453e6b43 Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@qt.io>
* UIKit: Don't reallocate renderbuffer on QIOSContext::swapBuffers()Tor Arne Vestbø2016-06-174-67/+100
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | During device rotation, the backing CEAGLLayer of our custom UIView is resized by the system. Normally this is the time where we would then reconfigure the corresponding renderbuffer that we render to, which shares memory with the CEAGLLayer, but we chose a lazy approach where we'd defer the reconfigure until client code actually called makeCurrent. This caused problems because not only did we implement the lazy reconfig in makeCurrent, but in every QIOSContext function that operated on the default FBO, including swapBuffers(). When using threaded rendering, such as in Qt Quick, the render thread may be half way in rendering a new frame when the system resizes the CEAGLLayer, and we pick up that resize on the swapBuffer call and allocate a new renderbuffer, before flushing the queued up GL commands that were operating on another renderbuffer of a different size. This resulted in the following crash: 0 - gpus_ReturnObjectErrorKillClient() 1 - gpusSubmitDataBuffers() 2 - glrFlushContextToken() 3 - flush(__GLIContextRec*)() 4 - QIOSContext::swapBuffers(QPlatformSurface*) ... We solve this by still being lazy in how we reconfigure, but limit the reconfigure to makeCurrent(). If the CEAGLLayer is resized in between two frames, we skip the half-drawn frame. The old frame will then be scaled to match the new size by the system, but this is preferable to flushing a new frame that may have been drawn with two conflicting window geometries. Task-number: QTBUG-50017 Change-Id: Ie229f26d156dfbfc7ed8d9efd0eb5e992eee73f1 Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@qt.io>
* uikit: Deliver update requests via CADisplayLink callbackTor Arne Vestbø2016-06-174-0/+70
| | | | | | | | Improves performance over the default timer-implementation, and allows us to control the rate and paused state of the display link. Change-Id: I05761b6eb48f5e91af35735e2faa477427cd8440 Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@qt.io>
* uikit: Call base class implementation of rotation callbacksTor Arne Vestbø2016-06-101-5/+4
| | | | | | | | | The Apple documentation explicitly says that you should call super when implementing these methods. Change-Id: I584bb140a4a5bde88927b379ab19158a78c6fea9 Reviewed-by: Jake Petroules <jake.petroules@qt.io> Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@theqtcompany.com>
* iOS: Return correct QLocale from QIOSInputContextRichard Moe Gustavsen2016-05-272-0/+45
| | | | | | | | | | | | Ensure we return a correct QLocale on iOS by overriding QPlatformInputContext::locale(). A broader implementation involving subclassing QSystemLocale will be done in dev. Task-number: QTBUG-48772 Change-Id: I5250bdad320cbe66d63456926f6eab6fc2865424 Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@theqtcompany.com>
* iOS: ensure we don't break UIKit IM state when sending key eventsRichard Moe Gustavsen2016-05-241-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | We need to be careful about calling textDidChange on the input delegate, since that will reset the internal IM state in UIKit and stop any ongoing text composition or spell checking. For that reason we set m_inSendEventToFocusObject to true whenever we send an IM event to Qt, to not call the abovementioned method when callbacks from UIKit is the reason for changing the text. But until now we never applied the same protection for key events. This lead to ligatures not working correctly (e.g when using Korean IM), since UIKit composes ligatures by first selecting the characters that can be truncated, then do a deleteBackwards, then insert the ligature. And deleteBackwards leads us to send backspace key events, which ends up in a textDidChange call, which confuses UIKit. This patch will ensure we don't call textDidChange as a result of sending key events. Task-number: QTBUG-52486 Change-Id: Ida268edae517f55a5b5f975340a5d3821f7b8f52 Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@theqtcompany.com>
* iOS: Report correct physicalSize and physicalDotsPerInch for iPhone6+Tor Arne Vestbø2016-05-022-7/+22
| | | | | | | | | | On iPhone 6(s) Plus devices, or when display zoom is enabled in an iPhone 6, the render buffer is scaled before being output on the physical display. We have to take this into account when computing the physical size. Task-number: QTBUG-50941 Change-Id: I318f3a866d039fccf0ba08f381fc9d8bcd676acd Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@theqtcompany.com>
* consistently put {qt,qml}_{module,plugin} at the end of project filesOswald Buddenhagen2016-03-071-5/+5
| | | | | | | | this fixes static builds by ensuring that all dependencies are exported. Task-number: QTBUG-51071 Change-Id: Icbce502dcbcb4d4b4d922c42679f44e2cc930bf3 Reviewed-by: Joerg Bornemann <joerg.bornemann@theqtcompany.com>
* iOS: fix crash on iOS 8 due to unsupported selectorRichard Moe Gustavsen2016-01-112-5/+9
| | | | | | | | | | | | It turns out that f558bde was not enough to stop a crash when trying to access forceTouchCapability of traitCollection. The reason is that traitCollection is available on UIScreen starting from iOS 8, while forceTouchCapability is available on UITraitCollection starting from iOS 9. So only checking the former will cause a crash when running on iOS 8. Change-Id: I44f9fb785349694004fbf2f48fe3b85bb01d9a5a Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@theqtcompany.com>
* Fixed crash on iOS devices due to unsupported selector.Harald Meyer2016-01-061-2/+4
| | | | | | | | Added check for traiCollection selector. Task-number: QTBUG-50159 Change-Id: Ie3efafe9e22e59aef862a681ad733f2bb0a5ba49 Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@theqtcompany.com>
* iOS: Clear focusObject if first responder is set to nullMarkus Goetz2015-12-171-1/+5
| | | | | | | | In certain cases we were still showing a cursor in a TextInput even though the keyboard was hidden programmatically. Change-Id: I48ebb6b8bc0382236b1ea5835e68eae48ece2b4f Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@theqtcompany.com>
* iOS: Don't hide keyboard on "Done" button when focus object has changedMarkus Goetz2015-12-171-0/+8
| | | | | | | | | | If the focus object changed programmatically for example to the next input field in a window, we want to keep the keyboard open. This strangely only worked if the inputs had different IM hints because this made the keyboard appear again. Change-Id: I52e66bb7d2ff97ae7084173769d9b5c2d0c549b5 Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@theqtcompany.com>
* iOS: notify application when edit menu is closedRichard Moe Gustavsen2015-12-171-0/+17
| | | | | | | | | The edit menu will also close if the user taps outside it, not only when selecting a menu item. But we never caught this case, which left QMenu to belive that it was still open. Change-Id: Iae071b4fc5fdc44d7d05b4dd767042907e337957 Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@theqtcompany.com>
* iOS: include marked text when reporting IM textInRange and endOfDocumentRichard Moe Gustavsen2015-12-171-2/+12
| | | | | | | | | | | | | | | | | | | | | [UITextInput textInRange] is sparsely documented, but it turns out that unconfirmed marked text should be seen as a part of the text document. This is different from Qt IM (ImSurroundingText), which handles marked text on the side. The reason we can assume this is that the range we are given as argument to textInRange exceeds the documents length when having marked text appended to the end, suggesting that it tries to read / verify the current marked text. In addition, keyboards like Japanese-Kana will not update and function correctly unless marked text is included. Note that the docs seems to imply that you cannot have marked text and text selection at the same time, unless the selection is contained within the marked text (using the dedicated selectedRange argument to setMarkedText). If this turns out to be incorrect, we might need to adjust the methods dealing with selection to also include marked text as well. Task-number: QTBUG-49946 Change-Id: Ifedd792ec66db435806f57fca157e1abbbf121a8 Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@theqtcompany.com>
* Fix broken QIOSContext setup due to missing 0-initialization of EAGLContextTor Arne Vestbø2015-12-101-3/+4
| | | | | | Change-Id: Ia4dbb2e3b055a7899c4a3e02698c5776ea7f73ea Reviewed-by: Mike Krus <mike.krus@kdab.com> Reviewed-by: Laszlo Agocs <laszlo.agocs@theqtcompany.com>
* iOS: filter edit menu actions depending on selection stateRichard Moe Gustavsen2015-12-091-0/+26
| | | | | | | | | | | | When showing an edit menu on iOS, UIKit will always populate the menu with actions according to what the current first responder supports. But it doesn't make sense to show all the actions every time the menu opens, so introduce some filtering depending on selection state. Change-Id: I943a09928233a3a10de003fe15ed8fd8b6fc1e18 Reviewed-by: Markus Goetz (Woboq GmbH) <markus@woboq.com> Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@theqtcompany.com>
* iOS: support edit action 'select'Richard Moe Gustavsen2015-12-091-0/+7
| | | | | | | | | Now that we don't populate the edit menu from qtquickcontrols anymore (because of shortcut issues), report to UIKit that we support select so that the action shows in the menu. Change-Id: I92508da4e1789c361d778cc6c1c77c86308f4c73 Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@theqtcompany.com>
* Favor OpenGLES 3 on iOS if availableMike Krus2015-12-091-3/+5
| | | | | | | | | | | | First tries OpenGLES 3 context since it’s strictly compatible with OpenGLES 2. If it fails, then try 2. This is required to use QOpenGLFramebufferObject::blitFramebuffer without having to look at using an Apple-specific extension. Change-Id: I01f8f058fa82e7f2c90d1b894ad36f3d3939c994 Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@theqtcompany.com> Reviewed-by: Laszlo Agocs <laszlo.agocs@theqtcompany.com>
* Respond with a sound for certain message boxes on windowsJan Arve Saether2015-12-041-0/+2
| | | | | | | | | | | | | | | This was a regression (it worked in 4.8) that was probably introduced by the refactoring of the accessibility framework in Qt 5. Now, QPlatformAccessibility::notifyAccessibilityUpdate() is called regardless of isActive(), so its the responsibility of each implementation of notifyAccessibilityUpdate() to check for isActive() where it matters. Task-number: QTBUG-33303 Change-Id: I0d18f8c1890ef679460408b05e704712b886bf7c Reviewed-by: Friedemann Kleint <Friedemann.Kleint@theqtcompany.com> Reviewed-by: Andy Shaw <andy.shaw@theqtcompany.com>
* Merge remote-tracking branch 'origin/5.5' into 5.6Liang Qi2015-11-271-1/+1
|\ | | | | | | | | | | | | | | | | | | Conflicts: src/network/socket/qnativesocketengine_p.h src/network/ssl/qsslsocket_mac.cpp src/network/ssl/qsslsocket_mac_p.h src/widgets/kernel/qwidget.cpp Change-Id: I39592cb37d710dfaf8640769ba3c1b637927d7f4
| * iOS: always flush spontaneous key press eventsRichard Moe Gustavsen2015-11-231-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When we changed sending key events through QPA instead of directly to the focus object, we only flushed from deleteBackward (06be9f026). The reason was to avoid unnecessary flushes, as this in general can be a source to recursion problems. It turns out that this is also needed when sending Qt::Key_Return. The reason is that we sometimes resign first responder when the return key is pressed, which will also change the focus object in Qt. And without flushing the key event first, it will be processed after the change and therefore end up at the wrong object. It seems like the most sensible thing is to always flush upon receiving spontaneous key/text events from iOS, which is also how it was before. Task-number: QTBUG-49021 Change-Id: I44885a11275dee5039ef6a8abbcbdadc092695e7 Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@theqtcompany.com>
* | iOS: Add support for delivering touch pressure on iPhone 6s/6s+ devicesTor Arne Vestbø2015-11-262-6/+33
| | | | | | | | | | | | | | | | | | | | | | | | | | | | As 3D touch can be disabled/enabled at runtime on those devices, we need to watch for changes to the relevant settings and update the touch device capabilities that we report to the user. Note that iOS will deliver touchesBegan with a touch force of 0, which we will reflect/propagate as a 0 pressure, but there is no clear alternative, as we don't want to wait for a touchedMoved before sending a touch press event to Qt, just to have a valid pressure. Change-Id: I47fb8a9f98ab3244e16a337bbfcf1fe24e4c7aa2 Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@theqtcompany.com>
* | iOS: Update pixel density (PPI) logic to detect new iOS devicesTor Arne Vestbø2015-11-192-11/+16
| | | | | | | | | | | | | | | | | | | | | | Since the iPhone 6(S) Plus devices have a PPI of 401, we change the logic from storing the unscaled PPI to storing the scaled PPI, and applying that to a scaled geometry when computing the physical size. Task-number: QTBUG-49467 Change-Id: I1741ff075749a301d2434cd35f642fcc9ea4b581 Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@theqtcompany.com> Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@theqtcompany.com>
* | iOS: only force-finish start-up from file engine when on main threadRichard Moe Gustavsen2015-11-091-14/+26
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The authorization dialog that grants the application access to the assets will only show after returning back from applicationDidFinishLaunching. Therefore, trying to load an asset from main before qApp->exec() would normally fail. To remedy that, we added a path that starts a QEventLoop for a split second to force the application init process to finish. But this can only work if we start it from the main thread. A bug with this is seen in QML FileDialog, since it (clumsy enough) starts to iterate, in a separate thread, all the files in its currently set directory upon start-up construction (which should be fixed as well). The result is that the application gets dead-locked on start-up. Change-Id: I0047272d53314752903960b33f88b33dc0d7e78d Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@theqtcompany.com>
* | Move QEventDispatcherCoreFoundation to QtCoreMorten Johan Sørvig2015-10-161-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Export it for use by the iOS platform plugin. Also move QCFSocketNotifier, and export for use by the Cocoa platform plugin. This is a pure code move with no intended behavior changes, in anticipation of using the Core Foundation event dispatcher as the default Qt Core event dispatcher on OS X. Change-Id: I43677d2f6f3c1d0ed0415c964225aa97d2f13078 Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@theqtcompany.com>
* | Make the CoreFoundation event dispatcher depend on QtCore onlyMorten Johan Sørvig2015-10-132-0/+22
| | | | | | | | | | | | | | | | | | | | In anticipation of moving it to QtCore. The call to QWindowSystemInterface::sendWindowSystemEvents() has been moved to QIOSEventDispatcher by making processPostedEvents() virtual. Change-Id: I9e03be4153a9f5f34e9a0ac942cdff572a44c318 Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@theqtcompany.com>
* | Merge remote-tracking branch 'origin/5.5' into 5.6Liang Qi2015-10-025-17/+224
|\| | | | | | | | | | | | | | | | | | | | | | | | | Conflicts: qmake/doc/src/qmake-manual.qdoc src/corelib/tools/qstring.h src/gui/image/qimagereader.cpp src/network/access/qnetworkaccessmanager.cpp src/tools/qdoc/doc/examples/examples.qdoc src/widgets/accessible/qaccessiblewidgetfactory_p.h src/widgets/doc/qtwidgets.qdocconf Change-Id: I8fae62283aebefe24e5ca4b4abd97386560c0fcb
| * iOS: silence compiler warning about unimplemented 'selectionRectsForRange'Richard Moe Gustavsen2015-09-101-0/+9
| | | | | | | | | | | | | | | | | | | | | | Implement a dummy method to silence the compiler. After testing, this method seems to never be called. Which is good, since the current IM API in Qt have little to offer to resolve what is being asked. Until a need arise, we just return an empty array. Change-Id: I573eb8205a7e635a46d487ae175fb46e3a602001 Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@theqtcompany.com>
| * iOS: filter responder actions from menu syncRichard Moe Gustavsen2015-09-041-1/+1
| | | | | | | | | | | | | | | | | | Follow up from b494d85. We need to filter the responder actions after a sync as well, otherwise they will be added back if a menu item e.g changes text. Change-Id: I2ecbcc292400ada97a8e29d4b97f087349d8a061 Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@theqtcompany.com>
| * iOS: compose key events from QKeySequencesRichard Moe Gustavsen2015-09-041-10/+18
| | | | | | | | | | | | | | | | | | Instead of hard-coding the key and modifier that should trigger a shortcut, we read it out from the QKeySequence that corresponds to a StandardKey instead. Change-Id: I6325534d3ff91c788d7e660d9009954e437b8534 Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@theqtcompany.com>
| * iOS: handle all directions when calculating positionFromPositionRichard Moe Gustavsen2015-09-011-1/+11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The method is currently a bit buggy, since it does not take UITextLayoutDirectionUp and UITextLayoutDirectionDown into account. This patch is mostly for fixing something "just in case", since we so far have not seen UIKit calling this method for those directions unless a hardware keyboard is connected. And in that case, we anyway override IM navigation by dealing with the arrow keys explicit. Since IM in Qt does not support getting the position above or below the current position, we just return the current position, making it a no-op. Change-Id: I4bcb9e2a00ab4e3d785058d7ff7f4855142dabbc Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@theqtcompany.com>
| * iOS: filter first responder actions from edit menuRichard Moe Gustavsen2015-09-012-1/+32
| | | | | | | | | | | | | | | | | | | | | | | | UIResponderStandardEditActions found in first responder will be prepended to the edit menu automatically (or e.g made available as buttons on the virtual keyboard). So we filter them out to avoid duplicates, and let first responder handle the actions instead. In case of QIOSTextResponder, edit actions will be converted to key events that ends up triggering the shortcuts of the filtered menu items. Change-Id: I046c6cc5b358d8a6f7623e10579e2dcd92f75139 Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@theqtcompany.com>
| * iOS: store shortcut sequence in menu itemRichard Moe Gustavsen2015-09-012-1/+7
| | | | | | | | | | Change-Id: I4c99516fb98ce0da84b8690cc4c1fd71c0db9dca Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@theqtcompany.com>
| * iOS: add undo/redo supportRichard Moe Gustavsen2015-09-011-0/+53
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Enable the undo/redo buttons on the keyboard, as well as the Cmd-Z/Cmd-Shift-Z shortcuts. For UIKit to support this, we need to add undo actions to first responders undo manager. Since we don't know if Qt has anything to undo/redo, we just enable the shortcuts all the time. To do that, we trick NSUndoManager to always have both an undo operation and a redo operation in the stack. Change-Id: I3294a962cc24f56585e7e515856142f3dda56d0a Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@theqtcompany.com>
| * iOS: listen for standard text edit shortcutsRichard Moe Gustavsen2015-09-011-0/+18
| | | | | | | | | | | | | | | | | | Catch the missing shortcuts sent by UIKit, and forward them to Qt as key events so that the app can respond to them. Change-Id: If63c4b05466e64843982fce32fbd594d2a0ef312 Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@theqtcompany.com> Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@theqtcompany.com>
| * iOS: send arrow keys to Qt to handle cursor movementRichard Moe Gustavsen2015-09-012-0/+67
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Controlling cursor position through input methods in Qt is very limited. You cannot e.g move the cursor vertically, or select text that spans several paragraphs. The reason for the latter is that Qt works with input methods on a per-paragraph basis, which effectively locks UIKit to only being able to move the cursor and select text within a single paragraph. Fixing up input methods to support more advanced navigation means changing the whole design (working on a whole document, instead of per paragraph), and is out of scope. Instead we choose to listen for arrow keys and forward them to Qt in the same fashing as we already do for backspace and enter. This will make the iOS port on-par with the other platforms, which also sends control characters like these on the side of IM events. Note that registering shortcuts and overriding default IM navigation behavior will only take effect when a hardware keyboard is connected. Only then will [UIresponder keyCommands] be called from UIKit. Change-Id: I634205e0578447c4aa6e9fdff342ee3b281901ea Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@theqtcompany.com>
| * iOS: send key events through QPARichard Moe Gustavsen2015-09-011-7/+5
| | | | | | | | | | | | | | | | | | | | | | | | So far we have chosen to send key events directly to the focus object since we do already do that for IM events. But Qt expects key events (especially control keys) to be sendt through QPA. This means that key events can end up somewhere else than at the focus object, which is expected and needed if shortcut propagation is to work. Change-Id: I160bf3309572719eda352cdb11b46c4b5a455e0d Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@theqtcompany.com>
| * iOS: Make setFrame in desktop view take superview transforms into accountTor Arne Vestbø2015-08-281-1/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | An assumption we do for the QIOSDesktopManagerView is that it should always cover the whole UIWindow. To achieve that, we override setFrame to be stop any attempt from UIKit to make our view smaller, e.g. when the statusbar changes height. In case the view is not a direct child of the window, we need to take any transformations into account when computing the new frame. This happens e.g. during presentation of other view-controllers, where our view is temporarily reparented into a UITransitionView that may have a transform set. Task-number: QTBUG-47506 Change-Id: I388143f2cbb566541ffb1068443ce21e62ea2b42 Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@theqtcompany.com> Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@theqtcompany.com>
* | iOS: Restore mirror mode using [UIScreen mainScreen] instead of nilTor Arne Vestbø2015-09-091-1/+1
| | | | | | | | | | | | | | | | | | The latter had the same effect, but is an invalid assignment for a value that is documented to be non-nil. Change-Id: Ice00482138481556ad839bc3721e577dafcb26fe Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@theqtcompany.com> Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@theqtcompany.com>
* | Merge remote-tracking branch 'origin/5.5' into 5.6Liang Qi2015-08-262-10/+45
|\| | | | | | | | | | | | | | | | | | | | | | | | | | | Conflicts: qmake/doc/snippets/code/doc_src_qmake-manual.pro qmake/doc/src/qmake-manual.qdoc src/corelib/io/qstorageinfo_unix.cpp src/corelib/tools/qbytearray.cpp src/widgets/kernel/qwidgetwindow.cpp tests/auto/corelib/io/qprocess/tst_qprocess.cpp tests/auto/corelib/mimetypes/qmimedatabase/tst_qmimedatabase.cpp tests/auto/network/access/qnetworkreply/BLACKLIST Change-Id: I9efcd7e1cce1c394eed425c43aa6fce7d2edf31c
| * iOS: calculate bounds in desktop view using transformed window bounds for ↵Richard Moe Gustavsen2015-08-251-1/+2
| | | | | | | | | | | | | | | | | | | | | | | | both width and height Depending on the orientation, UIKit might shrink either the width or the height of the view to fit the status bar. Since we anyway want the view to fill the whole window, we simply ignore this, and use the bounds of the whole window directly. Task-number: QTBUG-47506 Change-Id: I73294e5792f8d98fb0c0b0a42198207baca08e3c Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@theqtcompany.com>
generated by cgit v1.2.3 (git 2.25.1) at 2024-06-08 02:09:51 +0000