Based on the implementation of wl_display_connect, WAYLAND_SOCKET is
always preferred over WAYLAND_DISPLAY, which means it is OK to have both
of them set. This allows subprocess of input method to have the correct
WAYLAND_DISPLAY variable set.
Same as real hardware wl_keyboard, key should be sent before modifier
change. For example, Left Ctrl press and release should produce
key events in the order of Control_L and Control+Control_L.
It can help clients predict how KWin will react. Sometimes, the noise of
seeing a virtual keyboard pop up is reason enough not to focus an input
field.
Observed in kdevelop, that isEnabled() could be false when switching
between different tabs with Ctrl+Tab. But Qt may still call show()
if you click on the texteditor widget. This leads to isEnabled == false but
setActive(true) is called. This causes kdevelop in a usable state because
keyboard grab will be created and no key event will reach application
because isEnabled == false. Under normal circumstances, key will reach
widget first and triggers another text_input_v2 enable to make input
method work properly.
text-input-v3 does not have preedit styling, instead, it can only
specify the range of cursor. Try to keep track of any
highlight/selection style range and combine them together. If it matches
the cursor position, use it as the cursor range.
Qt usually request InputMethod::hide() upon unfocus, but
InputMethod::show() is actually never called if focus transfer is done
by keyboard, which leads to a permanent disabled input method state.
It can be easily reproduced with a window with two text field, e.g.
QFileDialog, by pressing tab to switch the focused widget.
The semantics of hide/show should not deactivate the input method.
Instead, it should simply hide/show the input panel. Also it should not
be a hard request for input method to permanently hide the window. When
input method asked to show it again, the input panel window should be
shown.
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.
