Summary: Fixes the build with D8705
Test Plan: Just adds includes, I wonder if it should go into Plasma/5.8 and /5.11 too
Reviewers: #plasma, davidedmundson
Reviewed By: #plasma, davidedmundson
Subscribers: graesslin, plasma-devel, kwin, #kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D8706
Summary:
Several effects announce a support property atom on the root window. This
change forwards the KWin::Application's signal that the xcbConnection
changed to the EffectsHandler so that the effects can respond to it.
All effects which announce a support property connect to this new signal
and re-announce the property. In case the xcb connection died (future
XWayland crashing case) it is set to XCB_ATOM_NONE by that. In case the
xcb connection got created (future delayed XWayland startup) the atom is
set to the proper value.
In addition all usages of the support properties are guarded, so that no
nonesense actions are performed if the support property is XCB_ATOM_NONE.
Test Plan: Only compile tested as we don't have XFree KWin yet
Reviewers: #kwin, #plasma
Subscribers: plasma-devel, kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D7761
Summary:
There are a few places where KWin needs to read values from kcminputrc.
As I need to add yet another one it makes more sense to properly
structure it like in other cases and have only one kcminputrc hold in
the application. This also allows to better mock the config values in
the integration tests.
Reviewers: #kwin, #plasma
Subscribers: plasma-devel, kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D5540
Summary:
By changing all kcfg to have arg="true" we can pass in the same
KSharedConfigPtr into all effects. This allows to have fake config in
the tests and in the planned effect demo mode.
Also it means that we don't have to hardcode the name kwinrc into the
files. In the configs - where we cannot access the effectshandler - we
use the define KWIN_CONFIG which gets generated based on the compile
time arguments.
Reviewers: #kwin, #plasma
Subscribers: plasma-devel, kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D3571
Summary:
This is implemented through QActions following the general approach
inside KWin and not the older approach used by ScreenEdges for pointer
callback activation.
Test Plan: Extended auto test
Reviewers: #kwin, #plasma
Subscribers: plasma-devel
Tags: #plasma
Differential Revision: https://phabricator.kde.org/D5263
When an application is not responding, its window is desaturated to communicate this.
Also "(Not Responding)" is added to the title bar.
Differential Revision: https://phabricator.kde.org/D5245
Summary:
WindowVertex contains the x position and also the relative texture x position
Our textures are scaled bigger than kwin's resolution, so this makes sure we set the right
texture position.
Otherwise our final array ends up using 0 to 0.5 of the texture, not 0 to 1.
Test Plan:
Opened some 2x windows, on a 1x output.
It looked how it should do, instead of it being double the size and cropped
Tested some things that use quads, like wobbly windows
Reviewers: #plasma
Subscribers: plasma-devel, kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D3502
Summary:
This change adds global touchpad swipe gestures to the
GlobalShortcutsManager and hooks up the swipe gestures as defined at the
Plasma Affenfels sprint:
* swipe up: Desktop Grid
* swipe down: Present Windows
* swipe left: previous virtual desktop
* swipe right: next virtual desktop
The main work is handled by two new classes: SwipeGesture and
GestureRecognizer. This is implemented in a way that it can be extended
to also recognize touch screen gestures and pinch gestures.
The SwipeGesture defines what is required for the gesture to trigger.
Currently this includes the minimum and maximum number of fingers
participating in the gesture and the direction. The gesture gets
registered in the GestureRecognizer.
The events for the gesture are fed into the GestureRecognizer. It
evaluates which gestures could trigger and tracks them for every update
of the gesture. In the process of the gesture tracking the
GestureRecognizer emits signals on the Gesture:
* started: when the Gesture gets considered for a sequence
* cancelled: the Gesture no longer matches the sequence
* triggered: the sequence ended and the Gesture still matches
The remaining changes are related to hook up the existing shortcut
framework with the new touchpad gestures. The GlobalShortcutManager
gained support for it, InputRedirection and EffectsHandler offer methods
to register a QAction. VirtualDesktopManager, PresentWindows and
DesktopGrid are adjusted to support the gesture.
Reviewers: #kwin, #plasma_on_wayland
Subscribers: plasma-devel
Tags: #plasma_on_wayland
Differential Revision: https://phabricator.kde.org/D5097
Summary:
This change adds support for marking the OnScreenMessage as it should
skip close animation. The screenshot effect is adjusted to use the
on screen message instead of the custom effect frame.
Test Plan: Message window is not captured when taking screenshot
Reviewers: #kwin, #plasma_on_wayland
Subscribers: plasma-devel, kwin
Tags: #plasma_on_wayland, #kwin
Differential Revision: https://phabricator.kde.org/D4091
Summary:
This adds support for the new on-screen-message support to the
kwineffects API and makes use of it in the colorpicker effect.
Not yet added to screenshot effect as for that we need support for
skip close animation on the on-screen-message window.
Reviewers: #plasma, #kwin
Subscribers: plasma-devel, kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D3803
Summary:
The default constructor shouldn't have been used anyway, but better safe
than sorry.
Reviewers: #plasma, graesslin
Reviewed By: #plasma, graesslin
Subscribers: plasma-devel, kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D3453
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:
The effectsConfig is no longer used by any Effect. ScriptedEffects use
KWin's KSharedConfigPtr and the builtin effects all have a kcfg with
kwinrc being hard coded.
The effectsConfig had the big disadvantage that it hardcoded kwinrc
while the rest of kwin uses a KSharedConfigPtr which might not point to
kwinrc.
Reviewers: #kwin, #plasma
Subscribers: plasma-devel, kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D3384
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:
When windows get added some effects grab the window and want to be the
only one animating this window. For this the grab roles exists. An
effect being notified later on evaluates the grab state and does not
start the animation.
This process failed due to being dependent on the order the effects are
loaded. Window Added/Closed are signals emitted by EffectsHandler, thus
first come, first serve. The requested effect order does not play into
it.
Due to that it could happen that an Effect which should not animate,
started to animate as the grab was still there.
This change adds the possibility to be notified whenever the window data
changes. A new signal is added to EffectsHandler which is emitted
whenever the windowData changes. The interested effects connect to it
and cancel their (just started) animation for the window.
Adjusted effects are:
* ScaleIn
* Fade
* WobblyWindows
In case of WobblyWindows an additional logical error was fixed that the
animations were only run when an effect grabbed instead of the other way
around.
BUG: 336866
FIXED-IN: 5.8.4
Reviewers: #kwin, #plasma, broulik
Subscribers: plasma-devel, kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D3211
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:
On Wayland per output rendering is performed and paintScreen is invoked
for every output. Some effects need the information which output is
currently being rendered as otherwise e.g. FBO access could fail.
This change adds the current output geometry to ScreenPaintData. On X11
(all outputs one geometry) this information is not set and a null rect
is returned. That way the effects can also easily check which rendering
mode is used.
Reviewers: #kwin, #plasma_on_wayland
Subscribers: plasma-devel, kwin
Tags: #plasma_on_wayland, #kwin
Differential Revision: https://phabricator.kde.org/D3058
Summary:
So far TabBox used highlight windows by passing window ids around through
an X property. This doesn't work on Wayland where we don't have window
ids for our TabBox and the Wayland windows.
This change introduces a new Effect::Feature for HighlightWindows which
the HighlightWindowsEffect provides. The EffectsHandlerImpl has a new
method to highlightWindows which it delegates to that effect if it is
loaded by invoking a new performFeature method.
The TabBoxHandler now passes the highlighting to the effects system
instead of updating the x11 property. Thus this works on Wayland and
at the same time improves the X11 side by no longer having to go through
the property protocol.
Test Plan: Verified that Alt+Tab highlights the windows on Wayland correctly.
Reviewers: #kwin, #plasma_on_wayland
Subscribers: plasma-devel, kwin
Tags: #plasma_on_wayland, #kwin
Differential Revision: https://phabricator.kde.org/D2630
Summary:
The Effect class is extended by three new virtual methods:
* touchDown
* touchMotion
* touchUp
The methods return a boolean value so that the events can be filtered
out. E.g. an effect which has also a mouse grab installed wants to
filter out all events, other effects don't need the events exclusively.
This is a difference to how e.g. keyboard and pointer events are handled.
But is more close to how KWin's internal input event passing works and
makes it easier to get touch event: one does not explicitly has to grab
the events. It's also closer to Wayland where all input events are
available.
As a first example the Present Windows effect is adjusted and allows to
activate windows through the touch screen. As much code as possible is
shared with pointer input.
Reviewers: #kwin, #plasma_on_wayland
Subscribers: plasma-devel, kwin
Tags: #plasma_on_wayland, #kwin
Differential Revision: https://phabricator.kde.org/D2450
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
Summary:
This allows effects to animate when a window is shown again and when
a window gets hidden but not yet closed/destroyed. This situation
happens on X11 for e.g. auto hiding panels and on Wayland for pretty
much any window which properly unmaps (windowHidden) prior to destroy.
Reviewers: #kwin, #plasma_on_wayland
Subscribers: plasma-devel, kwin
Tags: #plasma_on_wayland, #kwin
Differential Revision: https://phabricator.kde.org/D2084
The screen projection matrix is needed if an effect wants to customize
the modelview projection matrix while rendering a window and keeping
the currently applied screen projection and transformation.
With this change a new ctor overload is added to ScreenPaintData
which allows passing a projection matrix through the effects. This
allows effects to put up custom shaders with a shared projection matrix
and without having to calculate it themselves.
The projection matrix is a read-only information for the effects. There
is no way to change or overwrite it.
Effects currently modify the matrices by reading back the uniform
values from the shader they assume will be used to paint the window,
set new values for the uniforms, call paintWindow(), and then restore
the uniforms to their previous values.
This is both slow and unreliable, and will not work with dynamically
generated shaders.
This patch solves the problem by putting the matrices in
WindowPaintData and making it the responsibility of the paintWindow()
implementation to set the uniforms.
The left and right border images are rotated 90° before they are
uploaded into the atlas texture. The images are separated by a row
of transparent texels to minimize artifacts from oversampling.
With this change kwin renders the whole decoration with a single
call to glDrawArrays().
When this property is true, it indicates that the +U axis corresponds
to the +Y axis, and the +V axis corresponds to the +X axis.
This property is taken into account in WindowQuad::makeSubQuad().
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
The EffectLoader is a subclass of AbstractEffectLoader delegating all
methods to instances of:
* BuiltInEffectLoader
* ScriptedEffectLoader
* PluginEffectLoader
It's used by the EffectsHandlerImpl and replaces the complete Effect
loading mechanism we so far found in it. This also means that KLibrary
is no longer needed to load the Effects as the PluginEffectLoader uses
the KPluginTrader, which removes lots of deprecated functionality.
REVIEW: 117054
A KWin::EffectPluginFactory is introduced which provides a specialized
create method and methods for the supported and enabledByDefault checks.
A set of KWIN_EFFECT_FACTORY macros are added which create a subclass
of this EffectPluginFactory following the approach from the
KPluginFactory macros. The macros only support json metadata thus the
QPluginTrader needs to be used.
The KWIN_EFFECT macros are removed as they are no longer needed.
KWin Core's loader is not yet adjusted to this change. This is a
preparation step for introducing a PluginEffectLoader.
This method replaces the X-KDE-ORDERING property in the Effect's desktop
files. This change is a preparation step for integrating the new Effect
Loader which doesn't read the ordering information. Thus it needs to be
provided by the Effect itself so that the EffectsHandler can properly
insert it into the chain.
Also for the built-in Effects on the long run it doesn't make much sense
to install the desktop files. And binary plugin effects will migrate to
json metadata which also doesn't have the KService::Ptr. Thus overall it
simplifies to read this information directly from the Effect.
Instead of using EffectsHandler::sendReloadMessage we generate the dbus
interface in each plugin and call the reconfigure slot directly. That way
it's more type safe and we don't need to link kwineffects from the
configs.
REVIEW: 116875
There are no advantages for the effects KCM to have all the effect
config modules in one plugin.
By having a plugin per effect we can use the KPluginTrader to easily
find the configuration plugin for a given effect and load it.
To make this possible the following changes are done:
* config_builtins.cpp is deleted
* add_subdirectory is used for all effects which have a config module
* toplevel CMakeLists.txt contains the sources again for the effects
which have a config module, but effects which don't have a config
module are still included and thus the macro is still used
* plugin created for the config module, name pattern is:
kwin_effectname_config
* plugin installed to ${PLUGIN_INSTALL_DIR}/kwin/effects/configs
* desktop file adjusted to new plugin name and keyword removed
* desktop file converted to json as meta data and no longer installed
* Uses K_PLUGIN_FACTORY_WITH_JSON
* Macros for config are dropped from kwineffects.h
REVIEW: 116854
