IBus naturally doesn't know how to implement the text-input protocol,
and some input methods emit event streams that are incompatible with the
protocol, if not assumed to be part of an grouped series of events. As
IBus doesn't have any API to let us know about such groupings, let's
fake it by adding a specially crafted idle callback.
The idle callback has a known limitation; if there is an idle callback
with a higher priority, that either doesn't remove itself, or
reschedules itself before the next idle, we'll never get triggered.
This, however, is unlikely to actually be the bigger problem in such
situations, as it'd likely mean we'd have a 100% CPU bug.
https://gitlab.gnome.org/GNOME/gtk/issues/1365
This protocol supersedes the internal gtk_text_input protocol that
was in place. Functionally it is very similar, with just some more
verbosity in both ways (text_change_cause, .done event), and some
improvements wrt the pre-edit text styling.
If text_input_enable() is called when there no active IM (eg. running plain
mutter), some ClutterInputFocus method calls that are not allowed while
unfocused will end up called, triggering critical warnings.
If there is no IM return early here, all other calls are superfluous then.
This is the implementation of the internal text-input protocol that will
be used to communicate IMs (to be implemented by gnome-shell) with clients.
The text_input protocol has its own focus expressed through enter/leave
events, that will typically follow the keyboard's.
The client will be able to communicate its current status (eg. focus state,
cursor rectangle in surface coordinates, text surrounding the cursor
position, ...) and will receive commands from the compositor (eg. preedit
text, committing a string, ...).
Whenever there is an active input method, the compositor will route key
events directly through it. The client will not receive wl_keyboard
events if the event is consumed by the IM.
