summaryrefslogtreecommitdiffstats
path: root/src/plugins/platforms/ios/qiosinputcontext.mm
Commit message (Collapse)AuthorAgeFilesLines
* Add support for Apple tvOSMike Krus2016-05-171-0/+10
| | | | | | | | | | | | | | | | | | | | | | | | | Pass -xplatform macx-tvos-clang to configure to build. Builds device and simulator by default. Added ‘uikit’ platform with the common setup. Also added QT_PLATFORM_UIKIT define (undocumented). qmake config defines tvos (but not ios). tvOS is 64bits only (QT_ARCH is arm64) and requires bitcode to be embedded in the binary. A new ‘bitcode’ configuration was added. For ReleaseDevice builds (which get archived and push to the store), bitcode is actually embedded (-fembed-bitcode passed to clang). For all other configurations, only using bitcode markers to keep file size down (-fembed-bitcode-marker). Build disables Widgets in qtbase, and qtscript (unsupported, would require fixes to JavaScriptCore source code). Qpa same as on iOS but disables device orientation, status bar, clipboard, menus, dialogs which are not supported on tvOS. Change-Id: I645804fd933be0befddeeb43095a74d2c178b2ba Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@theqtcompany.com>
* QtBase (remainder): use printf-style qWarning/qDebug where possible (I)Marc Mutz2016-03-121-18/+18
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The printf-style version of QDebug expands to a lot less code than the std::ostream-style version. Of course, you pay in type safety (but compilers warn about it these days), you cannot stream complex Qt types and streaming QStrings is awkward, but in many cases you actually improve on readability. But the main reason is that something that's not supposed to be executed under normal operation has no business bloating executable code size. This is not an attempt at converting all qWarnings() to printf-style, only the low-hanging fruit. In this first part, replace qWarning() << "" with qWarning("..."). Had to fix broken qImDebug() definition. Instead of defining it as a nullary macro in the QT_NO_DEBUG case and as a variadic macro in the other, define it in both cases, as is customary, as a non-function macro so that overload selection works without requiring variadic macro support of the compiler. Saves e.g. ~250b in text size in QtPrintSupport on optimized GCC 5.3 AMD64 builds. Change-Id: Ie30fe2f7942115d5dbf99fff1750ae0d477c379f Reviewed-by: Kai Koehne <kai.koehne@theqtcompany.com>
* Updated license headersJani Heikkinen2016-01-151-14/+20
| | | | | | | | | | | From Qt 5.7 -> LGPL v2.1 isn't an option anymore, see http://blog.qt.io/blog/2016/01/13/new-agreement-with-the-kde-free-qt-foundation/ Updated license headers to use new LGPL header instead of LGPL21 one (in those files which will be under LGPL v3) Change-Id: I046ec3e47b1876cd7b4b0353a576b352e3a946d9 Reviewed-by: Lars Knoll <lars.knoll@theqtcompany.com>
* Rename ReturnKey to EnterKeyKai Uwe Broulik2015-06-031-1/+1
| | | | | | | | | | This makes the terminology consistent with Sailfish OS and the QNX QPA. The kImePlatformDataReturnKeyType in the iOS QPA is not changed to not break compatibility. Also, improve documentation. Change-Id: I2780de5b1e9277185ae1d4d9bbc67e36682fbfba Reviewed-by: J-P Nurmi <jpnurmi@theqtcompany.com> Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@theqtcompany.com>
* qiostextresponder: Add support for ReturnKeyTypeKai Uwe Broulik2015-04-091-1/+1
| | | | | Change-Id: Ic9212468fb41d8042a345267ae69c95e0d9b4cf2 Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@theqtcompany.com>
* iOS: check if Qt has an active window before scrolling to cursorRichard Moe Gustavsen2015-04-041-0/+3
| | | | | | | | | | | In hybrid applications an external view can be first reponder. And when that is the case, Qt will have no active windows and focusView will return 0. We therefore need to protect scrollToCursor from this case, so it doesn't try to access e.g focusView().window, which will lead to a crash. Task-number: QTBUG-45182 Change-Id: I87d470631f5beda22fd64fc1f2b0f7259344f830 Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@theqtcompany.com>
* iOS: Leave it up to QIOSTextInputResponder to decide when to reconfigureTor Arne Vestbø2015-03-181-18/+18
| | | | | | | | | We need to store the IM state as part of the QIOSTextInputResponder, so that the text responder can decide at a later point if it can still be the text responder for the current (possibly changed) focus object. Change-Id: I4ec861c5479238edf6a0fc101fa8241958af2d32 Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@theqtcompany.com>
* iOS: ensure keyboard is visible, even when IM hints hasn't changedRichard Moe Gustavsen2015-03-121-17/+16
| | | | | | | | | | | | | | | | | | | | | | | | When showing a QWindow, we transfer first responder status to its QUIView. If another QWindow was active with a text responder at that point, the text responder will loose first responder status in favor of the new view, and the keyboard will hide. Now, if the new window has a focus object with the same IM state as the previous focus object (in the previous window), m_imeState will not change, and QIOSIntegration::update() will assume that nothing needs to be done to show the keyboard, even if it's actually hidden. This patch will change the logic, so that we: - show the keyboard if its supposed to be visible, even if m_imeState did not change. - Only recreate the text responder if it needs a different configuration than the one we already got (not only from changes to Qt::ImEnabled) Task-number: QTBUG-40695 Change-Id: I6f6788af4cbff5c7abe4f5a29e23a7cefea6b711 Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@theqtcompany.com>
* Fixed license headersJani Heikkinen2015-02-171-1/+1
| | | | | Change-Id: Ibebe1318d1c2de97601aa07269705c87737083ee Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@theqtcompany.com>
* Update copyright headersJani Heikkinen2015-02-111-22/+14
| | | | | | | | | | | | | | | | | | Qt copyrights are now in The Qt Company, so we could update the source code headers accordingly. In the same go we should also fix the links to point to qt.io. Outdated header.LGPL removed (use header.LGPL21 instead) Old header.LGPL3 renamed to header.LGPL3-COMM to match actual licensing combination. New header.LGPL-COMM taken in the use file which were using old header.LGPL3 (src/plugins/platforms/android/extract.cpp) Added new header.LGPL3 containing Commercial + LGPLv3 + GPLv2 license combination Change-Id: I6f49b819a8a20cc4f88b794a8f6726d975e8ffbe Reviewed-by: Matti Paaso <matti.paaso@theqtcompany.com>
* iOS: Raise window level instead of hiding statusbar during VKB scrollTor Arne Vestbø2015-01-071-1/+16
| | | | | | | | | | | | | | | | | | Hiding the statusbar using the normal iOS APIs result in QScreen reporting new availableGeometry, which is not what we want. The scroll of the screen is a purely visual effect, and shouldn't have any effect on observable Qt APIs besides the keyboard rect changing. Instead of actually hiding the statusbar, we achieve the same effect by raising the key window (and any other application windows, including the keyboard) to the level of the statusbar, effectively putting them above the statusbar. This still leaves popups and alert windows above the key window, as normal. Change-Id: Ib7694240ca86cfb9000de35bf0c49343ffb37e32 Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@theqtcompany.com> Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@theqtcompany.com>
* iOS: Remove QIOSKeyboardListener self-change assert/guardTor Arne Vestbø2015-01-061-2/+0
| | | | | | | | | We're fairly confident self won't change in that case, and the assert was causing warnings in release builds. Change-Id: I4a826579bb4cedef8423e8d43cb370e1f3b80407 Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@theqtcompany.com> Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@theqtcompany.com>
* iOS: let keyboard gesture work better with other gesturesRichard Moe Gustavsen2014-12-111-0/+12
| | | | | | | | | | | | | | | | | | | Let the keyboard gesture work better alongside other gestures by reporting that it should: 1. not prevent other gestures from triggering. This means that even if our gesture triggers (we close the keyboard), gestures attached to sub-views will still continue tracking. 2. not be prevented by other gestures. This means that if a gesture in a sub-view triggeres before our gesture, our gesture will still continue to track. In short it means that regardless of other gestures, we always close the keyboard if our text responder is first responder and the user flicks down. And we do so as "silently" as possible. Change-Id: I22386b5ef5dedbc498a2899929ddd07424e514d8 Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@theqtcompany.com>
* iOS: only clear focus object if it supports IMRichard Moe Gustavsen2014-12-111-1/+2
| | | | | | | | | | | | | | | | | | | | We try to keep a on-to-one relationship between UI controls with text input and keyboard visibility. But if the control does not use text input, then there is no reason for us to clear focus when the keyboard hides. In fact, we should avoid doing so, since that will stop e.g buttons from working correctly. The typical flow is: - a touch release targeting a button is sendt to QApplication. - QApplication transfers focus to the button. - qiosinputcontext gets notified, we refuse, and clear focus again. - QApplication enters a propagation loop where it tried to find out the receiver of the event. Since the button is now unfocused, the event will propagate up to a grandparent instead. - the button will as such not trigger. Change-Id: I70baa38299f40defc4a77f62790502e2d6ebbba9 Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@theqtcompany.com>
* iOS: Only scroll to cursor on keyboard hide gesture reset if requestedTor Arne Vestbø2014-12-111-3/+12
| | | | | | Change-Id: I15b313b5f0d57358e405f16e941fc5061028c6a7 Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@theqtcompany.com> Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@theqtcompany.com>
* iOS: Don't scroll screen on changes to input item transformTor Arne Vestbø2014-12-111-19/+3
| | | | | | | | | | | | | We auto-scroll the screen to reveal the cursor whenever the cursor rect changes or other properties of the input methods are updated, but the expected behavior when explicitly moving an item under the keyboard, such as when scrolling a view or moving an item using drag, is to not scroll the screen until typing commences. This matches how eg. Safari or the Notes app handles the same use-case. Change-Id: I6b6932d9bcbdccd8df26db982246c162f1574d86 Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@theqtcompany.com> Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@theqtcompany.com>
* iOS: Guard against UIGestureRecognizer messing with selfTor Arne Vestbø2014-12-021-0/+3
| | | | | | | | We pass in self to initWithTarget, so we need to be sure that the init doesn't return a new self. Change-Id: I90d0d10d2fd1a5d38ef1ff3f23169dcce00b28e2 Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@theqtcompany.com>
* iOS: Properly support QInputMethod's visible and animating propertiesTor Arne Vestbø2014-12-021-95/+114
| | | | | | | | | | | | | | | | | | | | | | | | We now emit and change the 'visible' and 'animating' properties of the QInputMethod according to the documentation, which means the 'visible' property will change immediately when the keyboard is about to become visible, or about to hide, and the 'animating' property will determine if the visibility-change is just starting out, or has ended. The keyboard rect will at all times reflect the currently visible area of the virtual keyboard on screen (in focus-window-coordinates), not future state after the animating completes. Getting the future state is a missing piece of the QInputMethod API, and could be solved in the future by adding arguments to the animatingChanged signal that allow platform plugins to pass on the before- and after states. The logic for determining the keyboard state has been moved into a central function, updateKeyboardState(), which allows us to change and emit property changes atomically. There is still some parts left of the old approach, but these are left in to make further changes to the code easier to diff and understand in isolation. Change-Id: Ica52718eba503165ba101f1f82c4a425e3621002 Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@theqtcompany.com>
* iOS: Simplify view management in QIOSKeyboardListenerTor Arne Vestbø2014-12-021-31/+40
| | | | | | | | | | | | | We don't need to keep track of the view-controller or add ourselves as a gesture recognizer inside QIOSKeyboardListener. In fact, leaving the call to removeGestureRecognizer in [QIOSKeyboardListener dealloc] will result in QIOSKeyboardListener never being released, as the view that we add the recognizer to will keep a strong reference to the recognizer, so dealloc is never called unless the view is also released, which is unlikely to happen. We now fully control the lifetime of the recognizer. Change-Id: I6755e8cdfcc8f1062314db51aa54a2b7ecd1b967 Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@theqtcompany.com>
* iOS: Refactor QIOSKeyboardListener implementation and usageTor Arne Vestbø2014-12-021-59/+78
| | | | | | | | | | | | | QIOSKeyboardListener takes care of both maintaining the virtual keyboard state, and acting as a gesture recognizer for the hide keyboard gesture. We make this explicit though a union in QIOSInputContext, so that we can access each 'mode' separately. This improved code readability and allows later refactoring of the state and gesture into separate classes without changing the call sites. Change-Id: Icc60f4a542983cda7ca0fd6622963d32d1e90db9 Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@theqtcompany.com>
* iOS: close keyboard by resigning first responderRichard Moe Gustavsen2014-11-131-23/+4
| | | | | | | | | | | | | | | | | | | | | Current approach of reloading input views assumes that the first responder is not a QIOSTextResponder, but a QUIView. This is not always the case, e.g if someone calls update after setting IM enabled on current focus object to false. In that case we'll try to close the keyboard by reloading input views on a quitextresponder which can fail if the text responder has an external input view attached. This patch will instead hide the keyboard by resigning first responder when it is a QIOSTextResponder. If it is not a QIOSTextResponder it means that the keyboard is already closed, or a third-party UIVIew that supports key input is first responder. In either case we then leave it as-is. Task-number: QTBUG-42523 Change-Id: I4dab648af9029941a8d5d3b00011fbd169be5482 Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@digia.com>
* iOS: Allow virtual keyboard to be hidden by QInputMethod::hide()Tor Arne Vestbø2014-11-081-3/+18
| | | | | | | | | | | | | | | | | | | Calling the function has the same effect as dismissing the keyboard using the native keyboard dismiss button or the hide-keyboard gesture, and will result in the QIOSTextInputResponder losing first-responder status and the current focus object being cleared. QtWidgets and other parts of Qt will try to hide the keyboard during focus changes between widgets, which we already take care of when the focus object changes, so we detect the situation and ignore it, by requiring that the current focus object matches the one we've brought up the text responder for. Showing the virtual keyboard is still a no-op, as there is no way to show the virtual keyboard without a focus-object. Change-Id: Iefcb403c2b6d3da8a4df3fcd53bc1244ba9c4d23 Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@digia.com>
* iOS: Make hide-keyboard gesture use normal UIGestureRecognizer flowTor Arne Vestbø2014-11-081-41/+90
| | | | | | | | Allows us to track state through the normal gesture recognizer states instead of custom variables. Change-Id: I4fe1b370a581132a9bbb8f51f7bee73381b80341 Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@digia.com>
* iOS: Detect when inputMethodAccepted() is out of sync with focus objectTor Arne Vestbø2014-11-061-0/+20
| | | | | | | | | | | | The GraphicsView stack still seems to have issues emitting focusObject change signals when the focus object changes inside the item hierarchy. To be on the safe side we use our own view of whether or not IM is enabled, and try to detect and warn if we find a case where the two are out of sync. Change-Id: I9fde896ea14ea5b65784723110887e06453edbd4 Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@digia.com>
* iOS: Make QIOSTextInputResponder a proper first-responder during text inputTor Arne Vestbø2014-11-031-7/+36
| | | | | | | | | Instead of faking it, by returning YES for isFirstResponder, which caused issues when iOS would try to dismiss the keyboard by resigning the true first-responder. Change-Id: I816c4cf9c699d72995ce7968e1f1a4aa9c9c167e Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@digia.com>
* iOS: Make sure we update hints and platform data on IM enable/disableTor Arne Vestbø2014-10-311-0/+9
| | | | | | Change-Id: If4d9c9c769b598a3194a7cd5bbe5c74e7650694b Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@digia.com> Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@digia.com>
* iOS: Fade out statusbar when scrolling view due to VKBTor Arne Vestbø2014-10-201-0/+2
| | | | | Change-Id: I86923a2b2aa2d17d79ba3a11cabf37e615eaf4cc Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@digia.com>
* iOS: ensure we have a valid focusObject before sending it IM eventsRichard Moe Gustavsen2014-10-191-1/+1
| | | | | | | | | | | Should not really happen, but since we don't store the focus object given to us, we should do a check. A crash was seen from this when running the "Application" example for widgets. Change-Id: I9c4121766d7028a4eceede7d7b15c8c53d34e16e Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@digia.com>
* QIOSInputContext: animate screen from current transformationRichard Moe Gustavsen2014-09-251-1/+2
| | | | | | | | | | | | | | | Since we assign a fromValue to the scroll animation directly, the UIViewAnimationOptionBeginFromCurrentState flag does not have any effect. So we need to set the fromValue based on the current presentation state explicit. The reason why we need to ensure that we scroll from the current state is to avoid screen 'jumping' as a result of the scroll function being called many times during the same event loop cycle during after a focus change (focus object/window change, cursor rect change etc). Change-Id: Id98f43d60ec5d028b113361dab953569accf9b3f Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@digia.com>
* QIOSInputContext: change keyboard rect when focus window changesRichard Moe Gustavsen2014-09-251-0/+1
| | | | | | | | Since keyboard rect should be in window coordinates, it needs to change when focus window changes. Change-Id: I052aa5cadf182841d7c4eb114ebd1ea5317ff39c Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@digia.com>
* QIOSInputContext: report keyboard rect relative to focus windowRichard Moe Gustavsen2014-09-251-31/+27
| | | | | | | | After changes to how we scroll the screen, we need to change the implementation for calculating the keyboard rect as well. Change-Id: I7f468d55f6e29604b9c276deccd9926e071552a9 Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@digia.com>
* iOS: Scroll root view when keyboard is visible using sublayerTransformTor Arne Vestbø2014-09-241-7/+28
| | | | | | | | | We opt to use sublayerTransform instead of changing the root view's bounds, so that we can keep the root view at the same position and size regardless of statusbar height and visibility. Change-Id: I3f04a4587f1108084208aefa990f91a130fb47b8 Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@digia.com>
* iOS: Allow settings custom input and accessory views through ImPlatformDataTor Arne Vestbø2014-09-201-2/+2
| | | | | Change-Id: Ib802c73f9c9e27853fa0dd25c304d77df570309e Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@digia.com>
* iOS: Refactor text input handling to standalone responderTor Arne Vestbø2014-09-201-60/+117
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Instead of coupling the visibility of the virtual keyboard to the first-responder status of the currently active QUIView, we now treat first-responder as a separate state, tied directly to QWindow activation. This fits better with the concept of first-responders in iOS, as a UIView can become first-responder without dealing with text input, eg when dealing with touch events or menu actions. The decision point on whether or not to show the virtual keyboard is then handled by implementing the conformsToProtocol method and selectively returning YES for the UIKeyInput protocol. iOS internally calls _requiresKeyboardWhenFirstResponder on the UIResponder to determine this, but since we can't override a private method (like WKContentView in WebKit does) we have to rely on the fact that the implementation of the method uses the protocol conformance to make its decision. Once the virtual keyboard is up, we then need to react to changes to its configuration, such as keyboard type or the type of return key. Normally this would be a simple call to [view reloadInputViews], but iOS will not reload the built-in keyboards unless the UIResponder returns YES for _requiresKeyboardResetOnReload. Since we again can't override this private method (like WebKit does), we work around it by taking advantage of the fact that iOS will treat any change to the first-responder as a reason to do a keyboard reset. By using a stand-alone UIResponder for text input we can init and destroy these responders as needed, so that every call to reloadInputViews will trigger a reset, as the responder has not been seen before. We keep track of changes to the input-method-query, and detect whether or not we need to bring up a new UIResponder for text handling. As part of this refactoring we now tie the visibility of the virtual keyboard to the presence of a focus object that has input-methods enabled. This means that we automatically will track changes to input-elements through the focus changes, and reconfigure or hide the keyboard as appropriate. As a result the hide() method of QInputMethod becomes a no-op on iOS. Change-Id: I4c4834df490bc8b0bac32aeedbd819780bd5aaba Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@digia.com>
* iOS: Don't store UIViewAnimationOptions value as UIViewAnimationCurveTor Arne Vestbø2014-09-021-2/+2
| | | | | | | | | | We pull out the magic UIViewAnimationCurve of the keyboard animation when the keyboard is about to show, but we need to defer the shifting of the value 16 bits, as that turns it into a UIViewAnimationOptions, which we can't store in a UIViewAnimationCurve member. Change-Id: Id35dae1ec487951df749dfffb6118b572c28b103 Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@digia.com>
* iOS: delay callbacks to UITextInput to avoid recursionRichard Moe Gustavsen2014-06-061-8/+2
| | | | | | | | | | | | | | | | | | | | | | If the application calls "reset" or "commit" on the input method (or forces active focus on some other item) from a text changed or key pressed handler, iOS will sometimes throw an exception. It does so because we try to change the state of UITextInput (by calling textDidChange) while processing a callback from the same place (insertText). Optimally this should not happen since we would normally post such events to Qt, not send them directly. But with text input we cannot do this since UITextInput expects us to update immediately upon receiving text input callbacks. If not, word completion and spell checking will stop working. This change will guard against recursive callbacks by delaying callbacks to UITextInput when text/selection/first responder changes. Change-Id: I099f30adf1c5aba241fc833a45b423016f4ed8d0 Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@digia.com>
* iOS: scroll screen after hiding keyboard programaticallyRichard Moe Gustavsen2014-04-291-0/+7
| | | | | | | | | | | When the keyboard is told to hide, we resign first responder. If this is done programatically on touch press, this will make the "hide keyboard gesture" receive a touchesCancelled instead of a touchesEnded. Since we didn't catch this from before, the gesture was left in a mixed state causing the screen not to scroll when later showing the keyboard. Change-Id: I70ed59710128a912097cd5bfbdd8f49b20b7934c Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@digia.com>
* iOS: don't scroll towards cursor during touch pressRichard Moe Gustavsen2014-03-291-0/+19
| | | | | | | | | | While the user is touching the screen, postpone scrolling until we get a touch release. Scrolling in the middle of a touch sequence will change the coordinates under the touch, and cause some artefacts. Change-Id: I02ef420abaab780a459f014d4b4cfb75c8fbb725 Reviewed-by: Morten Johan Sørvig <morten.sorvig@digia.com>
* iOS: stop keyboard from reopending after the gesture finishesRichard Moe Gustavsen2014-03-291-2/+38
| | | | | | | | | | | | | | | | | | | On iOS we have set the style hint 'SetFocusOnTouchRelease'. This is in conflict with the 'hide keyboard' gesture, since a control can try to regain focus (and open the keyboard) if the gesture ends on top of it. So we need some extra work-around code to prevent this from happening. The correct way would probably be to cancel the touch sequence once the gesture triggers, but this is not well implemented in Qt yet, especially in combination with widgets and mouse synthesis. Since usage of the gesture behaves really bad in some cases (e.g if using the TextEdit example) we need to apply this for now. Change-Id: Ib3327c0bd94d722b4c4793bc6d152d6d19810e4b Reviewed-by: Morten Johan Sørvig <morten.sorvig@digia.com> Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@digia.com>
* iOS: animate screen from current in-flight geometryRichard Moe Gustavsen2014-03-291-1/+1
| | | | | | | | | | | | If you show/hide the keyboard quickly while we scroll the screen, the scroll will appear to jump. The reason is that the screen animation will start from where the model layer is at, and not the presentation layer. So specify that the animation should start from the current state of the presentation layer. Change-Id: I3db87ab11aab583eb50784b0c0a03a9a07c8b822 Reviewed-by: Morten Johan Sørvig <morten.sorvig@digia.com>
* iOS: keep keyboard rect in syncRichard Moe Gustavsen2014-03-291-3/+0
| | | | | | | | | | | | | | If you resign/become first responder several times while the keyboard is animating (e.g changing focus between focus objects while the keyboard is animating), iOS will short-cut the whole animation, and jump directly to keyboard end-state. For that reason, we always need to handle keyboardRectChanged, and not bail out early. This is fine, since the guard we had was really only meant for keyboardWillShow/Hide in the first place. Change-Id: I3a3d1e7061962286c538360029ed38410dc0f347 Reviewed-by: Morten Johan Sørvig <morten.sorvig@digia.com>
* iOS: implement 'close keyboard' gestureRichard Moe Gustavsen2014-03-211-3/+27
| | | | | | | | | | | | | | | | | | | | | | Before this patch there were no way for the user to hide the keyboard on iPhone for multi-line edit fields unless the app had a separate button added for it. And even that would be problematic since we scroll the screen (and perhaps the button) to track the cursor. This patch implements a gesture that resembles the 'hide keyboard' gesture that UIScrollView implements on iOS 7. Note that if you start the gesture inside the edit field, you will start selecting text as well. This will also cause the cursor to move and the screen to scroll. After some testing and failing, it seems like we need to live with such artifacts until we do get around to do the only sensible thing; fix up how we do text selection on touch platforms. Working around it becomes just to messy. Change-Id: I1c0d9c88ff1f5430587a49591f165b9708e5dc60 Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@digia.com>
* iOS: update keyboard rectangle when scrolling the screenRichard Moe Gustavsen2014-03-151-8/+24
| | | | | | | | | | When we scroll, the keyboard will change position relative to QScreen, even if it appears to stay put. For that reason we also need to update the keyboard rect after doing a scroll. Change-Id: I9bda2ab5b5e4970f488d3e69e44cf58e273f8fcd Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@digia.com>
* iOS: prevent crash on iOS 5Richard Moe Gustavsen2014-03-041-3/+3
| | | | | | | | | | For some reason, the [] access into NSDictionary causes a crash on iOS 5. So instead use the API as listed in the documentation: objectForKey. Task-number: QTBUG-36532 Change-Id: I19fdf0f4ba1aebaf9477e2bd45040c389923605d Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@digia.com>
* iOS: don't store reference to focus objectRichard Moe Gustavsen2014-02-141-4/+1
| | | | | | | | | | | Sometimes focus object is updated after we get a callback that the cursor rectangle has changed. And there is no reason to keep a local reference to it. Since we also send events to the qApp->focusObject from UIView_textInput, we now end up more consistent. Change-Id: I3976175aae4e3f346be9bc5b771ac0fdefc03ae6 Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@digia.com>
* iOS: implement support for input methodsRichard Moe Gustavsen2014-02-061-15/+23
| | | | | | | | This change will add support for input methods, word completion, spell checking and related functionality. Change-Id: I41d4de1cab521c679d414cfc7c1a2d0f9c1fcaaf Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@digia.com>
* iOS: change logic for when to scroll screenRichard Moe Gustavsen2014-02-061-46/+72
| | | | | | | | | | | | | | | | | | | The current implementation will stop scrolling the screen to reveal the cursor if the input item changes transformation. This to not interfere with flicking etc. This strategy turns out to be too strict, as some qml apps/games can easily have small animations applied (e.g qtquick cork board example) that moves or scales the text areas (or their parents) upon focus. So instead of relying on input item transformation, we now scroll whenever the cursor changes position inside the input item (in addition to orientation changes etc). We also refactor scrollRootView into two functions, since we in many cases know if the keyboard should scroll up or down already when the call is made. Change-Id: If5bf349139eed69823cfc8986bb4b32c93bdf91b Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@digia.com>
* iOS: Fix C++11 buildTor Arne Vestbø2013-12-211-1/+1
| | | | | Change-Id: Ib7dc8dcbeca7e85d97b8c7fb04d2cf42e5245298 Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@digia.com>
* iOS: fix crash when focusWindow changes while keyboard is openRichard Moe Gustavsen2013-12-041-1/+1
| | | | | | | | | | | | | | | It turns out we cannot rely on QGuiApplication::focusWindow() to be non-zero at all times (e.g when pop-ups are closing etc). So instead use m_focusView.qwindow which points to a valid QWindow. This window is the same as QGuiApplication::focusWindow most of the time, except when a focus window closes. For those cases we get a new call to scrollRootView immediately after with m_focusView updated to reflect the new focusWindow. Task-number: QTBUG-35339 Change-Id: Icb3a8d3140af1f1904495a9289c8c26ab79e70f6 Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@digia.com>
* iOS: update keyboard layout upon focus transferRichard Moe Gustavsen2013-11-251-2/+18
| | | | | | | | | | | | | | | | | | | | When iOS transfers focus from one view to another, it asks the new view for its UIKeyInput properties before deciding how the keyboard should be configured. For Qt, the same QUIView is used for the whole QWindow which means that UIKit will not change the keyboard configuration just because we change the focus object in Qt, since the UIView does not change. There seems to be no way to tell UIKit that the keyboard needs to change becuse the UIKeyInput properties has changed. To work around this, we briefly resign first responder status, and grabs it again, for the same QUIView. Change-Id: I2d15cc0c928deb023e7da58ad4669b7099dce2cf Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@digia.com>
generated by cgit v1.2.3 (git 2.25.1) at 2024-05-07 18:14:22 +0000