Forward these from the IM, and handle the ones involving
the OSK state: lowercase/uppercase/auto_capitalization/titlecase.
The latter two involve peeking at the surrounding text, to figure
out if it makes sense to toggle keyboard level.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3162>
Move the complex parts of this mechanism from the Keyboard object
to the KeyboardController object, replaced by code that is easier to
follow.
Also, keyval guessing is deferred to a later point in the commit
procedure so so it does not happen for a single character only,
this way we can send multi-character input through the IM, which
is necessary for some OSK layouts.
Closes: https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/7190
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3162>
We only support "latched" which stays toggled on for a single
character unless long-pressed. Support "default" mode explicitly
to switch back to the default level, leaving "locked" implicitly
supported as the way to stay in the same level.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3162>
This is already covered by a timeout to handle focus transitions between
windows at the Clutter.InputMethod implementation, we can react immediately
and avoid chaining up timeouts.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3162>
This getGroups() method was not called anywhere for
a long time, the last user was dropped at commit
8fdf47ea5b ("keyboard: Do not create widgetry for
all keyboard groups at once").
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3162>
Since we now just store the current group, we do not need to track
closely source changes vs selection changes in the available sources.
We just re-generate the current OSK keymap for all, so coalesce both
signals into a more generic "group-changed".
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3162>
And fix it so it is effective again. This is a small piece of
smarts the code needs to earn, so that keys with the "emoji"
action are hidden, and their width assigned to the next key.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3162>
And drop some more guesswork in the code, since some layouts have
less than 4 levels. This also allows for having OSK maps with more
than 4 levels. Let us hope that the sanity of our future kin will
remain below that threshold.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3162>
Drop some code, in favor of a numeric keypad that is driven through
the same JSON-based maps. This is also a first use of the "height"
key property in the JSON files, for the Enter key.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3162>
Do not hardcode the us-terminal OSK keymap, and append '-extended'
to the current group name, accounting with the existing 'us' fallback.
This allows for concerned individuals to propose language-specific
terminal layouts.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3162>
This will allow OSK descriptions to declare "tall" keys. May be
used in combination with the "start" property added in previous
commits, in case a gap needs to be explicitly left.
No OSK description uses this yet.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3162>
This optional property defines the offset the a key should have
relative to the previous key (on its left) or the start of the
column if it is the first key. If this property is not
present, the key will be placed with no relative offset.
This for example allows keymaps to explicitly define the padding
of the rows that are not "full" relative to other rows, without
guesswork in the code. It is used for this purpose in the
keymaps/levels/rows that needed it.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3162>
Previously backspace would only ever remove a single character left of
the cursor, regardless of selection.
This requires the application to correctly set the anchor position in
text_input::set_surrounding_text(), which currently only gtk4 seems to
do. When there is no selection or on other applications that always set
cursor = anchor, like gtk3 does, the behavior is not changed and still
only deletes one character.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2746>
Since mutter@33088d59 the cursor we receive from mutter already is a
character index while the code here still treated it like a byte offset.
Further the code to detect the previous word position was treating the
cursor parameter already like a character index, while passing the
cursor that was prior to that commit a byte offset.
The function also had some unreachable and redundant code paths. The
pos < 0 case can never be reached due to the max(). Also the regex
already ensures that all whitespace is considered, so the code to remove
spaces not actually do anything except when deleting the first word in
the text, in which it would cause the first character to not get
deleted.
Also it was not handling characters with more than 2 bytes correctly. In
the presence of these JS string functions, such as search(), can not be
considered to operate on character indices anymore but rather the number
of UTF-16 byte pairs. Issues with this can be avoided by using
iterators, which unlike anything else iterate on characters, not byte
pairs and by not using the results returned by JS string functions for
anything but JS strings.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2746>
These have been long deprecated over in clutter, and (via several
vtables) simply forward the call to the equivalent ClutterActor methods
Save ourselves the hassle and just use ClutterActor methods directly
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3010>
Reportedly, non-alphanumeric key levels were able to stick by
happenstance, and let the user press multiple keys until explicitly
switching to a different mode. Reportedly, this broke, switching to
the default level after the first key press on the additional levels.
Since we have this information in the OSK key models (each level has
a "mode" field to either default/latched/locked), retrieve this
information for them for each level, and only reset to the default
level if on one of those latched levels, and the relevant key was not
locked through long-press.
Closes: https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/5763
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2945>
The _commitAction() paths have early returns, which made resetting the
latched mode inconsistent depending on the paths taken to commit the
string. This made latched modes not return to normal on e.g. Shell
entries.
Make this happen outside the function, and after the only calling
point, so that the level is correctly reset on all situations.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2945>
We have been using type-safe comparisons in new code for quite a while
now, however old code has only been adapted slowly.
Change all the remaining bits to get rid of another legacy style
difference.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2866>
If the OSK is destroyed while visible without being close()'d first,
the completion mode might remain turned on. Ensure it is turned off
on OSK destruction so that typing-booster has no chance to remain
turned on.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2543>
Even though the emoji panel may be destroyed with the OSK, the swipeTracker
that is set up to navigate between pages is left lingering, and handling
events for some gestures in the stage. This results in warnings like:
JS ERROR: TypeError: this._panel is null
set delta@resource:///org/gnome/shell/ui/keyboard.js:720:9
_onSwipeUpdate@resource:///org/gnome/shell/ui/keyboard.js:750:22
_updateGesture@resource:///org/gnome/shell/ui/swipeTracker.js:670:14
vfunc_gesture_progress@resource:///org/gnome/shell/ui/swipeTracker.js:288>
on touch interaction after the OSK was shown and dismissed. In order to fix
this, issue explicit destruction of the swipeTracker when the emoji pager
actor is destroyed.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2543>
When propagating keys from the OSK, we usually feed these directly to
the IBusInputContext and let the IM handle the effects of this virtual
key event (which may also include feeding a key event back to us).
But these functions may also return a FALSE value if the key was "let
through" by the IM, which means the ball is in our yard again, and
we are responsible of letting this event get to its destination.
If that happens, just fall through, so the string is committed to
the client as an UTF-8 string, or propagated through keyboard events.
Closes: https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/5930
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2508>
