| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
| |
If a parent widget has an input context assigned return that from
QWidget::inputContext() before returning QApplication::inputContext().
Change-Id: I4982a91ace9b7485534f1c31fa4e2d549482640e
Task-number: QTBUG-17390
Reviewed-by: axis
|
|
|
|
| |
Reviewed-by: Trust Me
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The bug happened because we did not expect to receive a call to
CancelFepInlineEdit() when the widget had not previously been given
any preedit text by S60. However, this can happen, and if it happens
at the same time that there is a temporarily visible character in the
widget (because it will be obscured as a password a second later),
then the temporary character would be discarded.
Fixed by checking in the beginning of CancelFepInlineEdit() whether
we currently have any temporary preedit text or not, and if we do, we
don't clear the contents, since it is the input context itself that
generated the preedit text, not S60.
Also made sure that the temporary preedit text is committed if we
receive a call to UpdateFepInlineTextL(), which may sometimes happen
without a call to StartFepInlineEditL().
Task: QT-4314
AutoTest: Included
RevBy: Shane Kearns
|
|
|
|
|
|
|
| |
Since the events are balanced now, we need to give them time to get
through.
RevBy: Trust me
|
| |
|
|
|
|
|
|
|
|
|
| |
The bug was that when querying for the maximum text length, the case
where an invalid QVariant was returned (which is allowed) was not
handled properly. This would lead to input being blocked by the input
context when it shouldn't.
RevBy: Sami Merila
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When inputting only numbers, the symbol menu should not do anything.
However in the old code the resource id of the symbol table was still
being set, so the symbol key on N97 would look up a table that was
not valid for the current input mode and crash.
Fixed by setting the symbol table id to zero under those conditions.
RevBy: Sami Merila
Task: QTBUG-13472
AutoTest: Included
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The bug happened when you were typing a password and pressing "Done"
softkey very quickly. Because of the temporarily visible character,
the widget would not contain the full string at the time of softkey
triggering, only the *** part.
Fixed by having the input context listen for softkey (command) events
and commit the temporary character before the softkey action is
triggered.
AutoTest: Included
Task: QTBUG-12949
RevBy: Miikka Heikkinen
|
|
|
|
|
|
|
|
|
|
|
| |
Problem was reproduced on N97. If the FEP detects that the widget is
full while still editing text, it will try to send those events as
key events instead. Since this screws up the content in the widget,
we stop those events from reaching the widget in the input context.
AutoTest: Passed
Task: QTBUG-12949
RevBy: Miikka Heikkinen
|
|
|
|
|
|
|
|
|
|
|
|
| |
If a native control was created for a child widget, it would receive
the FocusChanged signal in its QSymbianControl with a value of not-
focused. This would lead the code to deactivate the whole toplevel
window. This was fixed by having Qt traverse the widget chain up to
the toplevel and check if parent widgets are also not focused.
AutoTest: Included and passed
RevBy: Denis Dzyubenko
RevBy: mread
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This fixed a case where using password mode would lead to Qt
believing that the cursor was one step to the left of where it really
was. This would have the effect of replacing the last character
instead of appending to it, and even crashing if the cursor was all
the way to the left.
The code is also much cleaner this way, but it meant that QTBUG-9867
had to be solved differently this time. We do this by assuming that
and empty FEP update means "erase last character", which seems to
work well in practice.
Also added a long overdue autotest for the FEP input methods. Most
tests pass, but some don't, which I will try to fix later.
Task: QTBUG-9867
Task: QTBUG-12949
RevBy: Miikka Heikkinen
AutoTest: Included
|
|
|
|
|
|
|
| |
When the focus proxy widget doesn't have InputMethodEnabled attribute set we
shouldn't try to set an input context on it.
Reviewed-by: Simon Hausmann
|
|
|
|
| |
Reviewed-by: Trust Me
|
|
|
|
|
|
| |
Test fixed to send the correct signal type on windows ce.
Reviewed-by: Marco
|
|
|
|
| |
Reviewed-by: Trust Me
|
|
|
|
| |
Reviewed-by: Trust Me
|
|
|
|
| |
RevBy: Trust me
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
After discussions with Matthias, several things were changed:
- the autoSipOnMouseFocus property was removed and replaced with a
new style hint, SH_RequestSoftwareInputPanel. This means the style
can define when the input panel is launched.
- The code which sends RequestSoftwareInputPanel events was moved
into its own function, and the widgets call that function.
AutoTest: Included and passed
RevBy: mae
|
|
|
|
| |
RevBy: Trust me
|
|
|
|
|
| |
We are not guaranteed that the checked-for event is the last event,
so we look for it in a list instead.
|
| |
|
| |
|
|
|
|
|
| |
AutoTest: Included
RevBy: denis
|
|
|
|
|
| |
AutoTest: Included
RevBy: denis
|
|
|