Summary:
A second interactive selection mode gets added to select a position on
the screen. This is handled by the same input event filter as for the
window selection. Just that instead of returning a window, it returns a
QPoint.
This allows to pick a point on the screen which we need to screenshot
the screen under the mouse cursor and in future for color picking.
The screenshot effect provides two new dbus methods to (interactively)
select a screen or fullscreen. This allows spectacle to screenshot the
(full) screen with still having the user in control.
Reviewers: #kwin, #plasma_on_wayland, bgupta
Subscribers: plasma-devel, kwin
Tags: #plasma_on_wayland, #kwin
Differential Revision: https://phabricator.kde.org/D3475
Summary:
EffectsHandler gains a new method to startInteractiveWindowSelection
which just delegates to the one in Platform. That way a window can be
selected and returned to an Effect.
The screenshot effect makes use of this new functionality and provides
an interactive window screenshot mode which saves to a temporary file.
Note that this is not yet the variant intended for use in spectacle.
Test Plan: Took a screenshot on Wayland
Reviewers: #kwin, #plasma_on_wayland
Subscribers: plasma-devel, kwin
Tags: #plasma_on_wayland, #kwin
Differential Revision: https://phabricator.kde.org/D3367
Summary:
And finally nothing inside libkwineffects, libkwinglutils,
libkwinxrenderutils and kwineffect and kwin core uses KWin::display.
We are finally XLib free!
This change drops KWin::display and removes the include to QX11Info from
kwinglobals.h. And the libraries no longer need to link X11Extras. Due
to that removal a few seeming unrelated changes are required to add the
include where needed and linkage to X11Extras.
The biggest change is to x11 platform plugin which still needs the
display and caches it in the Platform and passes it to various places in
a way that the code doesn't need to be adjusted.
Reviewers: #kwin, #plasma_on_wayland
Subscribers: plasma-devel, kwin
Tags: #plasma_on_wayland, #kwin
Differential Revision: https://phabricator.kde.org/D3337
Summary:
There is no effect using this method. As it's X11 specific it should be
removed.
Internally the EffectsHandlerImpl still requires the method. Thus it's
moved into the private part.
Reviewers: #kwin, #plasma_on_wayland
Subscribers: plasma-devel, kwin
Tags: #plasma_on_wayland, #kwin
Differential Revision: https://phabricator.kde.org/D3297
Summary:
The method is not used by any Effect and is X11 specific, thus better
remove it for good.
Reviewers: #kwin, #plasma_on_wayland
Subscribers: plasma-devel, kwin
Tags: #plasma_on_wayland, #kwin
Differential Revision: https://phabricator.kde.org/D3298
Summary:
The implementation delegates to the Platform to perform the actual
show/hide of the cursor image.
This replaces the implementation in the zoom effect which so far
directly interacted with xfixes to show/hide the cursor. This is now
provided by the x11/standalone platform. And due to this change the zoom
effect can now properly hide the cursor on platform DRM (wayland) as
well.
Test Plan: Zoom effect on Wayland hides the cursor
Reviewers: #kwin, #plasma_on_wayland
Subscribers: plasma-devel, kwin
Tags: #plasma_on_wayland, #kwin
Differential Revision: https://phabricator.kde.org/D3120
Summary:
There are several effects (screenshot, zoom) which need access to the
cursor image and cursor hotspot. So far these effects used X11
unconditionally to get the cursor which obviously does not work on
Wayland.
This change adds a new class PlatformCursorImage to kwinglobals which
wraps what a cursor is (image and hotspot) and adds a new virtual method
to Platform to provide such a PlatformCursorImage. By default it's the
cursor image the Platform tracks. On X11/standalone platform this new
virtual method is overriden and provides a PlatformCursorImage from X11
using the code previously used in screenshot effect.
Screenshot effect and zoom are adjusted to use the new API instead of
X11.
Test Plan:
Zoom effect tested on Wayland, now gets the proper cursor icon.
X11 functionality not yet tested.
Reviewers: #kwin, #plasma_on_wayland
Subscribers: plasma-devel, kwin
Tags: #plasma_on_wayland, #kwin
Differential Revision: https://phabricator.kde.org/D3093
Summary:
A new method to tell the effects system whether the compositor scene
is able to drive animations. E.g. on software emulation (llvmpipe) it's
better to not do any animations at all.
This information can be used by effects to adjust their behavior, e.g.
PresentWindows could skip transitions or effects can use it in their
supported check to completely disable themselves.
As a first step all scripted effects are considered to be unsupported
if animations are not supported. They inherit AnimationEffect and are
all about driving animations.
The information whether animations are supported comes from the Scene.
It's implemented in the following way:
* XRender: animations are always supported
* QPainter: animations are never supported
* OpenGL: animations are supported, except for software emulation
In addition - for easier testing - there is a new env variable
KWIN_EFFECTS_FORCE_ANIMATIONS to overwrite the selection.
Reviewers: #kwin, #plasma
Subscribers: kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D2386
So far the effects could just use the connection() and rootWindow()
provided by kwinglobals. Thus an internal detail from KWin core is
accessed directly.
To be more consistent with the rest of the API it's wrapped through the
EffectsHandler and with a convenient method in Effect.
The connection() is provided as xcbConnection() to free the very generic
name connection which could create confusion once we provide a wayland
connection to the Effects.
The rootWindow() is provided as x11RootWindow() to indicate that it is
for the X11 world.
REVIEW: 117597
Effect loading gets split by the kind of effects KWin supports:
* Built-In Effects
* Scripted Effects
* Binary Plugin Effects
For this a new AbstractEffectLoader is added which will have several
sub-classes:
* BuiltInEffectLoader
* ScriptedEffectLoader
* PluginEffectLoader
* EffectLoader
The EffectLoader will be what the EffectsHandlerImpl is using and it just
delegates to the three other types of loaders. Thus the handler doesn't
need to care about the different kinds of effects. The loading is
supposed to be completely async and the EffectLoader emits a signal
whenever an Effect got loaded. The EffectsHandlerImpl is supposed to
connect to this signal and insert it into its own Effect management.
Unloading is not performed by the loader, but by the EffectsHandler.
There is one important change which needs to be implemented: the ordering
cannot be provided by the loader and thus needs to be added to the
Effects directly.
So far only the BuiltInEffectsLoader is implemented. It's not yet
integrated into the EffectsHandlerImpl, but a unit test is added which
tries to perform the various operations provided by the loader and the
BuiltInEffects. The test should cover all cases except the Check Default
functionality which is only used by Blur and Contrast effects. This
cannot be mocked yet as the GLPlatform doesn't allow mocking yet.
