Commit graph

7 commits

Author SHA1 Message Date
Martin Gräßlin
ea52ef9e57 Add a PlatformCursorImage to Platform and EffectsHandler
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
2016-10-20 07:51:49 +02:00
Martin Gräßlin
142aab2e24 Introduce an EffectsHandler::animationsSupported -> bool
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
2016-08-15 17:38:33 +02:00
Marco Martin
5a55727056 support the slide protocol
take and apply thhe informations from the wayland slide
protocol in the sliding popups effect

REVIEW:125120
2015-09-14 16:39:39 +02:00
Marco Martin
3f5bf65a9e Use the kwayland blur protocol in the blur effect
use the new blur protocol to fetch information about the
region of blur behind to apply to windows like Plasma::Dialog
REVIEW:125017
2015-09-02 14:43:44 +02:00
Michael Pyne
85d87297b0 Return false for a bool instead of nullptr.
Fixes compiler warning (error by default in gcc 5).

REVIEW:123077
2015-03-19 23:22:46 -04:00
Martin Gräßlin
4230a0d331 [effects] Get xcb_connection_t* and rootWindow through EffectsHandler API
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
2014-04-16 16:05:05 +02:00
Martin Gräßlin
0fd9a1eeee [kwin] Introduce a new Effect Loading mechanism
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.
2014-03-28 14:04:54 +01:00