When moving/resizing a window we don't want the keyboard events being
passed to the Clients. Instead we want to do the normal processing.
Unfortunately moving the window through the keyboard relies on warping
the pointer which is not (yet) available on Wayland. This means that this
is not yet working, but ending through enter/escape etc. is working as
expected.
Major new functionality is xkbcommon support. InputRedirection holds an
instance to a small wrapper class which has the xkb context, keymap and
state. The keymap is initialied from the file descriptor we get from the
Wayland backend.
InputRedirection uses this to translate the keycodes into keysymbols and
to QString and to track the modifiers as provided by the
Qt::KeybordModifiers flags.
This provides us enough information for internal usage (e.g. pass through
effects if they have "grabbed" the keyboard).
If KWin doesn't filter out the key events, it passes them on to the
currently active Client respectively an unmanaged on top of the stack.
This needs still some improvement (not each unmanaged should get the
event). The Client/Unmnaged still uses xtest extension to send the key
events to the window. So keylogging is still possible.
InputRedirection keeps track of the Toplevel which is currently the one
which should get pointer events. This is determined by checking whether
there is an Unmanaged or a Client at the pointer position. At the moment
this is still slightly incorrect, e.g. pointer grabs are ignored,
unmanaged are not checked whether they are output only and input shapes
are not yet tracked.
The pointer events are delivered to the Toplevel as:
* enter
* leave
* move
* button press
* axis event
Nevertheless move events are still generated in InputRedirection through
xcb test for simplicity. They are still send to the root window, so all
windows get mouse move.
Button press and axis are generated only in the implementations of the
event handlers and delivered directly to the window, so other windows
won't see it.
Unfortunately this is extremely platform specific with code for X11 and
Wayland. But at the moment it doesn't make much sense to abstract as
Effects are the only case where a fullscreen low level input area is
used.
A small problem is also that the mouse cursor doesn't get restored and
is changed when the X11 cursor changes. This will be fixed once we start
to properly track the cursor of the individual X windows.
New inheriting class which uses the InputRedirection to track the cursor
position. It doesn't support warping of cursor.
This introduces a slight dependency loop in the startup. Cursor needs to
be created after the WaylandBackend to ensure that the operation mode is
set correctly. But the WaylandBackend itself is accessing Cursor. It
should be safe as inside the WaylandBackend it's only accessed after
callbacks.
InputRedirection forwards pointer events (currently motion, press and
release) through the EffectsHandlerImpl for the case that an effect has
intercepted pointer events.
If the KWin operation mode is not X11 only, the window for intercepting
the mouse events is no longer created.
A new AreaBasedEdge is introduced which supports the Edge functionality
by just connecting to the globalPointerChanged signal of
InputRedirection.
The AreaBasedEdges are used if KWin's operation mode is not X11 only.
This unfortunately required to change the datatype of the list of edges
in ScreenEdges. It used to be specific on the inheriting class.
So far this new class is not yet doing much. The WaylandBackend forwards
the received pointer events to this InputRedirection class. From there
signals are emitted to inform internal areas about the changes first.
The events are currently forwarded to X through the xtest extension. This
will be removed in future. Input will be forwarded directly to the
surface which wants it (no matter whether X11 or Wayland).
It's no longer needed as the OpenGLBackend has a direct rendering
detection and the remaining OpenGL2 backend aborts if the backend
uses indirect rendering. Thus the GLPlatform must always have a
direct rendering context.
REVIEW: 116829
* A KDecoration needs to include json metadata
* A KDecoration needs to be installed to kwin/kdecorations
* Aurorae and Oxygen adjusted
* kcmdeco locates all decorations through the KPluginTrader
* libkdecoration uses KPluginTrader to find the plugin
* config plugins also need to include json metadata with
X-KDE-PluginInfo-Name being the same as the decoration
* config plugins need to get installed to kwin/kdecorations/config
* kcmdeco locates the config plugin for a deco through the name
and KPluginTrader
REVIEW: 116765
X-KWin-Internal should be used for effects which are either internal
to KWin and are configured at a different location in KWin. Examples
are:
* CoverSwitch - configured in WindowSwitcher KCM, but not FlipSwitch
as that one has a non WindowSwitcher mode
* window geometry - configured in moving
And it should also be used for helper effects to the overall
kde-workspace module. Examples are:
* Dashboard - required by Plasma
* KScreen - required for KScreen
* Screenshot - required by KSnapshot
Why a new category and not the already existing NoShow property?
The idea is to just filter on the effects in the list. Thus it should
be possible to show them. But NoShow is clearly intended to not be
shown at all.
REVIEW: 116754
Lambda connections are tricky: they do not get automatically
disconnected when the captured [this] gets destroyed, but they get
disconnected when the sender object gets destroyed.
Thus the slide effect was crashing if it got disabled and a window
got deleted, because the connection was still present and tried to
access the destroyed this pointer.
To circumvent we need to pass this as context object.
REVIEW: 116712
Looks like this completely broke in Qt. The groups are all placed at
0/0 if there is an animation defined and the complete layout is broken.
The animation is not that useful in fact so no big loss.
EffectsHandlerImpl::isEffectsSupported performs the check whether the
effect with the given name is supported by the current compositor.
The check is the following:
* if effect is already loaded, it is supported
* if the effect cannot be found, it is not supported
* if it's a scripted effect, it's always supported
* if it's a built-in effect, we ask BuiltInEffects::supported
* for all other effects we resolve the library and the supported
method
The idea behind providing this functionality in the DBus interface is
to allow filtering in the effects KCM for the effects which are
supported by the current compositor.
In addition a areEffectsSupported method is added which takes a
list of names and returns a list of bools.
REVIEW: 116665
The connect is from the KDecorationOptions which lives longer than the
factory, thus the lambda might be invoked after the Factory got
destroyed. Adding the context object protects against that.
All effects with
X-KWin-Exclusive-Category=category
are considered as mutual exclusive for specified category. So far this is
just a hint for the GUI representation. Such effects should get a
radio button while effects in the same category without that property
or with it set to false should get a checkbox.
As a first step the desktop change animation effects use this property
and are put into a new category "Virtual Desktop Switching Animation".
REVIEW: 116710
The option changes the behavior of the menu button, thus we should point
out to the user that the behavior changes.
This is only done for Auroae configurations as other decorations have to
take care about it themselves.
CCBUG: 331462
REVIEW: 116715
To increase consistency with other decorations and because it changes
the behavior of the menu button in an unexpected way we default to
double click menu button doesn't close the window.
BUG: 331462
FIXED-IN: 5.0
REVIEW: 116716
