| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
| |
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>
|
|
|
|
|
|
|
|
|
| |
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>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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>
|
|
|
|
|
| |
Change-Id: Ibebe1318d1c2de97601aa07269705c87737083ee
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@theqtcompany.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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>
|
|
|
|
|
|
|
|
|
| |
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>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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>
|
|
|
|
|
|
| |
Change-Id: I15b313b5f0d57358e405f16e941fc5061028c6a7
Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@theqtcompany.com>
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@theqtcompany.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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>
|
|
|
|
|
|
|
|
| |
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>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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>
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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>
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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>
|
|
|
|
|
|
|
|
| |
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>
|
|
|
|
|
|
|
|
|
|
|
|
| |
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>
|
|
|
|
|
|
|
|
|
| |
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: If4d9c9c769b598a3194a7cd5bbe5c74e7650694b
Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@digia.com>
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@digia.com>
|
|
|
|
|
| |
Change-Id: I86923a2b2aa2d17d79ba3a11cabf37e615eaf4cc
Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@digia.com>
|
|
|
|
|
|
|
|
|
|
|
| |
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>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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>
|
|
|
|
|
|
|
|
| |
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>
|
|
|
|
|
|
|
|
| |
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>
|
|
|
|
|
|
|
|
|
| |
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>
|
|
|
|
|
| |
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>
|
|
|
|
|
|
|
|
|
|
| |
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>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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>
|
|
|
|
|
|
|
|
|
|
|
| |
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>
|
|
|
|
|
|
|
|
|
|
| |
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>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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>
|
|
|
|
|
|
|
|
|
|
|
|
| |
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>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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>
|
|
|
|
|
|
|
|
|
|
| |
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>
|
|
|
|
|
|
|
|
|
|
| |
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>
|
|
|
|
|
|
|
|
|
|
|
| |
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>
|
|
|
|
|
| |
Change-Id: Ib7dc8dcbeca7e85d97b8c7fb04d2cf42e5245298
Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@digia.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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>
|
|
|
|
|
|
|
|
|
| |
fromPortraitToPrimary is called from the QIOSScreen
constructor. This is probably to early to call QGuiApplication
functions.
Change-Id: I882304fd641df13dc530491990245ba9ad495377
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@digia.com>
|