path: root/src/plugins/platforms/ios/qiostextresponder.h
Commit message (Collapse)AuthorAgeFilesLines
* Updated license headersJani Heikkinen2016-01-151-14/+20
| | | | | | | | | | | From Qt 5.7 -> LGPL v2.1 isn't an option anymore, see 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 <>
* iOS: Leave it up to QIOSTextInputResponder to decide when to reconfigureTor Arne Vestbø2015-03-181-0/+4
| | | | | | | | | 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 <>
* Fixed license headersJani Heikkinen2015-02-171-1/+1
| | | | | Change-Id: Ibebe1318d1c2de97601aa07269705c87737083ee Reviewed-by: Oswald Buddenhagen <>
* 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 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 <>
* iOS: guard text responder from clearing selectionRichard Moe Gustavsen2015-01-151-0/+1
| | | | | | | | | | | | | | | | | | | When programatically setting a text selection on iOS, we call [UITextInputDelegate selectionWillChange] to report the change. If auto correction is enabled, UIKit will then reset the current tracking, and for some reason tell us to clear the selection. This is contradictory to us saying the the selection is about to change, and will cause an unwanted recursion back to Qt. Since there seems to be no way to stop UIKit from doing this, this patch will instead add a guard that refuses to change the selection recursively while processing a selection change from Qt. Task-number: QTBUG-43716 Change-Id: Id487a57cdda55d7e2d09c3efc14c7f03f566f15a Reviewed-by: Tor Arne Vestbø <>
* iOS: Make a few member variables of QIOSTextInputResponder privateTor Arne Vestbø2014-10-281-4/+2
| | | | | | Change-Id: I269b1b5ab802c391a12bcdc8cfe0c4d3e52f9cba Reviewed-by: Richard Moe Gustavsen <> Reviewed-by: Tor Arne Vestbø <>
* iOS: Allow settings custom input and accessory views through ImPlatformDataTor Arne Vestbø2014-09-201-0/+3
| | | | | Change-Id: Ib802c73f9c9e27853fa0dd25c304d77df570309e Reviewed-by: Richard Moe Gustavsen <>
* iOS: Refactor text input handling to standalone responderTor Arne Vestbø2014-09-201-0/+74
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 <>