zwp_input_method_v1 has some different semantics comparing to
text-input-v3. There is no way to indicate that "clear preedit" with
zwp_input_method_v1. In some client (Namely, Gtk), receiving an empty
preedit string will also trigger replace selection action. For example,
focus into address bar in firefox will automatically select the URL in
the address bar, and a following empty preedit string will clear the
selection which is not desirable.
To avoid such behavior, simply send an empty "done()" to clear text
input v3 preedit if preedit is empty.
This may be problematic for certain client, e.g. firefox, and cause
input always reset after any key press. Also, sending reset on an
activate also does not match the text input v3 semantics.
zwp_input_method_v1 does not support generic double buffered event.
deleteSurroundingText need to be followed with done().
zwp_input_method_v1 preedit event order is preeditCursor,
preeditStyling, preeditString. To align it with text-input-v3 semantices,
send done() after receiving preedit_string() from input method.
Prefer hiding/showing the panel (i.e. the window) when not a touch event
than stopping to make the inputmethod active.
This way we remain compatible with non-virtualkeyboard inputmethods.
Since we adapted inputmethod to support methods like ibus, the input
method can be active but not have a visible panel.
This includes an extra property that will indicate us if the panel is
visible at any time. This will allow us to properly render the virtual
keyboard hide button in Plasma Mobile (or wherever we need it).
So far calling setActive(true) would issue a deactivation then another
activation. This sometimes makes maliit crash and we can achieve the
same result just by just issuing a reset.
When the panel disappears, just reconsider the panel's state but don't
just stop sending updates to the input method.
Some input methods are just helpers that show and hide as necessary.
This allows different input methods to get information about what's
beign typed from the actual hardware. This is especially useful for
non-latin script languages.
If the user has chosen to have a virtual keyboard (i.e. prefered maliit
over none in the KCM) they should get it. If it's too annoying it should
either be disabled or we can fix it so it gets less in the way.
This is especially important since some hardware registers itself as a
keyboard even if it's not a fully functional keyboard.
Ensures that m_active and the input context do not get out of sync and
that the right signals are always emitted by always using setActive to
activate.
Uses the context to define InputMethod::isActive.
Detach from the serials that the client send us, since they don't really
matter to the input method and track our own.
Also issue a commit state whenever we adopt a new input context. This
can happen for reasons that don't come from the client, like for example
the input method has just been enabled.
In practice, this solves an issue that we can easily see with maliit
where it would be left in a half-initialised state and would show
autocorrection fields on terminal applications when unnecessary and
possibly similar problems every now and then.
Not choosing any virtual keyboard is a valid option. In this case do not show the SNI since it isn't very useful then and takes up some space in the system tray.
BUG: 437171
When keyboard_grab is implemented, if we reset the inputmethod context
on any key, input method will not get keyboard input and will not be
able to use it.
Call ::updateInputPanelState when necessary (instead of a trimmed-down
refreshFrame version.
Actually provide the overlap information when it's available, there's no
need to send wrong information there.
We want to update the inputpanel state on new value which is being set
and not based on the cached value.
Fixes the keyboard going in wrong mode like pre-edit mode when closed
and re-opened.
