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>
We do set the full OSK as LTR since keymaps are defined in that
direction. Other actors inside the OSK might want differently so
move this piece of setup to init(), so child actors can set their
own without the OSK overwriting the value.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2278>
Update the emoji panel so it can handle ratio changes dynamically,
and propagate the ratio from the Keyboard itself, so that the
emoji panel has a size that fits the OSK panel it was launched
from.
This is more important now with widely varying ratios, like
extended keyboards.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2278>
This keymap requires the corresponding input method for Hangul
input, and the hangul mode to be enabled. Look up for the right
state, and use a corresponding 'us' keymap for english input
otherwise, in order to follow hangul IM behavior.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2278>
Like OSK key buttons, we must avoid the default grabbing behavior
of StButton here. Hook to button-press-event to commit the selected
words, so we get a chance to prevent focus changes on the current
key focus.
Likewise, connect to ::touch-event to handle touch input.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2278>
This mode changes the current IBus engine to ibus-typing-booster
under the rug (i.e. no changes in keyboard status menu) for any
XKB engine selected.
In order to make it useful for the currently selected language,
the typing-booster dictionary is changed to the current XKB
layout language. And since the OSK has its own emoji panel,
typing-boosters own emoji completion is disabled.
These changes only apply as long as the OSK panel is shown,
reverting to the original engine and typing-booster configuration
after it is hidden. This in theory also caters for users that
do have ibus-typing-booster enabled as an input source.
The final effect is text prediction for the language that is
being typed, according to the OSK layout, given that
ibus-typing-booster and the relevant hunspell dictionaries are
used.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2278>
This action will replace CLUTTER_KEY_Backspace emission for
the OSK backspace key. Following the available mockups, implement
different modes of operation:
- Single tap deletes a single character
- Long tap starts deleting characters one by one
- Longer tap switches to word-by-word deletion
This is made possible via the input method surrounding text,
inspecting the string to look the previous char/word position
backwards, and relies on IM focus providing enough context.
Since deleting text and getting surrounding text are both
async operations, we make one happen after the other, until
the button is released.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2278>
Keep it consistent with the rest of the actions. For long press
handling (i.e. shift turning to caps lock), this also means the
release action should be cancelled after any long press, to prevent
both from taking effect at the same time.
Prior to this commit, we used to switch level (and hide the button
being pressed) on button press, which made its long press handler
never get a paired release and end up triggering caps lock.
Performing the action on release ensures the shift key button does
not fall into this situation, making this issue moot.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2278>
Have these defined in the JSON files themselves, instead of trying
to add them from JS while minding the differences in number of levels
and rows.
This means more redundant data in the JSON files, but simplifies
OSK layout creation significantly, and allows finer control over the
appearance without quirks.
As a result, importing data from CLDR is no longer as straightforward
as running an script. After initial import, manual editions will be
required to add missing keys, assign key widths, and so on.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2278>
These actions are defined in the JSON files themselves, allowing
us to migrate away from the sets of pre/post default keys, and fold
them into the JSON files for fuller control on layout and appearance.
As a first migration step, handle the relevant actions in the buttons
created from the JSON files, so we can port these.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2278>
Instead of having callers handle pressed+released, emit string
commits on a distinct signal that is emitted all at once during
release.
This also unifies the behavior of keys that have an extended keys
popup and not wrt press/release behavior and key repeat.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2278>
Add distinct properties for label/icon, and commit string/keyval
actions. This makes keys figure less things on their own, allows
disociating aspect and behavior (e.g. label '↲' and keyval 0x13),
and makes the fallbacks clearer (keyval and label resorting to
commit string).
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2278>
