This makes KWin switch to in-tree copy of KWaylandServer codebase.
KWaylandServer namespace has been left as is. It will be addressed later
by renaming classes in order to fit in the KWin namespace.
The .clang-format file is based on the one in ECM except the following
style options:
- AlwaysBreakBeforeMultilineStrings
- BinPackArguments
- BinPackParameters
- ColumnLimit
- BreakBeforeBraces
- KeepEmptyLinesAtTheStartOfBlocks
Maliit does client side animation by default but can be told to disable
them using an environment variable. Since we now want to do this
animation in KWin, always disable the client side animations in Maliit.
It feels slightly weird to unconditionally add a Maliit-specific
variable, but at the same time all other solutions are more error prone
and would likely need more code.
This adds support for animating showing/hiding of the input method panel
to the sliding popup effect, if the input panel is of type "Toplevel".
This is mainly intended to animate showing the virtual keyboard and has
been primarily tested with Maliit. It replaces the client-side animation
that Maliit would do, instead doing the animation on the KWin side which
provides a significantly smoother experience.
This ensures that we get a warning if the config header is not included
instead of compiling the code as if it was disabled. Interestingly, some
checks already used #if KWIN_BUILD_*, so those were generating -Wundef
warnings when the feature is disabled. Commit 886173cab assumed that all
those features were already 01, so this unbreaks the build if any of the
features is disabled.
Fixes: 886173cab ("Reduce ifdefs in Workspace::supportInformation()")
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.
