The offset argument is changing from uint to int. Which means we
might would pass a negative offset and trigger an "out of bounds"
error. Make it work more or less alright with older mutters, by
clamping the offset to 0.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1146
Forward the arguments at the 'delete-surrounding-text' signal
from IBusInputContext to clutter_input_method_delete_surrounding()
so that ibus-typing-booster use the deleting surrounding text function.
Input method engines can delete the output text in applications
with this function.
This change will require a change of mutter of mutter!517
because the first arguemnt of the 'delete-surrounding-text' is INT
to express the offset of the current cursor position but
the first one of clutter_input_method_delete_surrounding() is UINT
since the Wayland spec accepts UINT in delete_surrounding()
mutter will change the type of the first one to INT in
clutter_input_method_delete_surrounding() to work with this change.
https://gitlab.gnome.org/GNOME/mutter/issues/539https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/477
In the xwayland-on-demand scenario, it may happen that Xwayland is
shutdown (causing a restart of ibus-daemon to drop ibus-x11) while
we are typing.
If we have a bit of bad luck, this will cause the IBusInputContext
to be disposed (due to its bus "closing") at a time when we have
an ibus_input_context_process_key_event_async() request on the fly.
As the object is disposed in between this would tickle JS (rightfully
complaining that it's been disposed under its feet) and make us pass
an actually NULL IBusInputContext to the corresponding _finish()
function (despite the IBusInputContext being still held alive by some
other refs). This will assert and abort in
ibus_input_context_process_key_event_async_finish() then.
To handle this, listen for IBusInputContext::destroy, and reset our
internal state, this way we can compare on the JS side that the
IBusInputContext is indeed an up-to-date one.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/813
The shell tries to spawn the ibus daemon on startup if unavailable, however
as per commit 8adfc5b1 we also force restarting it once the X11 server is
available.
Unfortunately this could cause a race if we disconnect while we were already
connected to an ibus daemon, but still in the process of going through the
various nested calls.
In fact the ::disconnect callback didn't stop any further async ibus call
that, even if failing, would have eventually triggered the emission of a
'ready' signal and to the Keyboard's callback, leading under X11 to a full
grab owned by ibus daemon.
In order to avoid this and keep control of the calls order, use in both
IbusManager and InputMethod a cancellable that is setup before connecting to
the bus, and that is cancelled on disconnection.
Then handle the finish() calls properly, using try/catch to validate the
returned value, taking in account the potential error and just not
proceeding in case of cancellation.
Fixes https://gitlab.gnome.org/GNOME/gnome-shell/issues/1712
gnome-shell calls ibus_input_context_focus_in() in InputMethod.focus_in()
but the event is not actually forwarded to panels and engines in GNOME
Wayland because gnome-shell changes IBus.Capabilite by focus events and
disables IBus.Capabilite.FOCUS when ibus_input_context_focus_in() is called.
IBus.Capabilite is assumed a fixed value per input context in the
first place and it should not be changed by focus events.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/573
Those unused arguments aren't bugs - unbeknownst to eslint, they all
correspond to valid signal parameters - but they don't contribute
anything to clarity, so just remove them anyway.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/627
When `ibus restart` runs, InputMethod.enabled is changed to false
and no longer enable ibus but 'enabled' and 'disabled' signals
are not used in the current IBus clients and it's good to delete
the member simply.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/295
ClutterVirtualInputDevice has the limitation that event flags won't be
made to contain CLUTTER_EVENT_FLAG_INPUT_METHOD, possibly causing feedback
loops.
As the event gets injected up the platform dependent bits, we can avoid
care on not pressing the same key twice, we still expect coherence between
key presses and releases from the IM though.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/531
The input method may hint that certain keycodes should be pressed/released
besides the textual information in ::commit. An example is hitting space
in some IMs to commit text, where both ::commit happens, and an space is
visibly inserted. In order to handle this properly, we must honor
::forward-key-press.
In order to cater for the case that a keypress is forwarded while handling
that same keypress in a physical keyboard, check the current event being
handled and just forward it as-is if it matches. This is necessary to
prevent state from being doubly set, and the second event silenced away.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/275Closes: #275
Even though we are using an "xkb" source, it still makes sense to
pass the event through the IBus simple engine, in order to let it
handle compose keys and ctrl+shift+[u|e].
https://gitlab.gnome.org/GNOME/gnome-shell/issues/115Closes: #115
When not using arrow notation with anonymous functions, we use Lang.bind()
to bind `this` to named callbacks. However since ES5, this functionality
is already provided by Function.prototype.bind() - in fact, Lang.bind()
itself uses it when no extra arguments are specified. Just use the built-in
function directly where possible, and use arrow notation in the few places
where we pass additional arguments.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/23
This is a ClutterInputMethod implementation using IBus underneath. The
input method will interact with the currently focused ClutterInputFocus,
be it shell chrome or wayland clients through the text_input protocol.
