| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
|
|
|
|
| |
We'd transfer or clear first-responder in a lot more cases than just
when transferring to a new Qt window, such as when presenting a new
view-controller on top to send an e-mail or take a picture using the
camera.
Change-Id: I6b2a8a6d9fd99910b96a86cf9847b7ff0128f20a
Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@digia.com>
|
|
|
|
|
|
|
|
|
| |
The result of pressing the key is still a Qt::Key_Return press/release
sequence, which needs to be handled manually.
Change-Id: I72c7b0067bd3ec1bc315ab2c84361800b7be0943
Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@digia.com>
Reviewed-by: Marius Bugge Monsen <marius@cutehacks.com>
|
|
|
|
|
|
|
|
|
| |
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>
|
|
|
|
|
| |
Change-Id: Ib802c73f9c9e27853fa0dd25c304d77df570309e
Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@digia.com>
|
|
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>
|