| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
| |
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>
|
|
|
|
|
|
|
|
|
|
|
| |
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>
|
|
|
|
|
|
|
|
| |
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>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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>
|
|
|
|
|
|
|
|
|
|
|
|
| |
If the inputItem moves, it typically means that the user
scrolls or flicks the focus item around. In that case
we should avoid scrolling the screen, otherwise they
will "cancel out" each other. Besides, when the user
flicks, he takes control over the whereabouts
on the screen anyway.
Change-Id: Iad0762965f9dcdbcca934ce6d90a8c1413ce3ca2
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@digia.com>
|
|
|
|
|
|
|
|
|
| |
This change will let QIOSInputContext scroll the root
view when the virtual keyboard is open, so that the input cursor
is not obscured.
Change-Id: If0758f4bf04c2b8e554e0196451154def7e3cb86
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@digia.com>
|
|
|
|
|
| |
Change-Id: I85dda6fc0c6d2d11709b8bcdc0de6c0cef42d40f
Reviewed-by: Lars Knoll <lars.knoll@digia.com>
|
|
|
|
|
|
|
|
|
|
|
|
| |
When the user is tranferring input focus between line edits
(or similar controls), the edit that lost focus will close
the input panel, just to see that the input that gained
focus will open it again. This will cause the input panel
to "jump", and can also trigger other input panel related
code/signals unnecessary.
Change-Id: Iac0a103e8d2f0f7cdcc04b8ec5b10e07587d1ad6
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@digia.com>
|
|
|
|
|
|
|
|
|
|
| |
This to ensure that the keyboard does not close prematurly.
This can happen if the user opens up the keyboard while typing
inside one window, then switch window, continue typing while
the other window gets deleted.
Change-Id: I5cfb1673ccbe4d5aaa14167b7aa53451031089a1
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@digia.com>
|
|
|
|
|
|
|
|
|
| |
QInputContext expects us to report whenever the
input panel changes geometry. This patch implements
this.
Change-Id: I9162f0d48da6925274a7489c9bcb6adab9afae82
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@digia.com>
|
|
This change will add an initial implementation of the
QPlatformInputContext for dealing with the keyboard.
Change-Id: I29c1cfbbebb8456977b8a1db0e966973cd2c24a5
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@digia.com>
|