kwin/autotests/mock_effectshandler.h

281 lines
9.3 KiB
C
Raw Normal View History

2020-08-02 22:22:19 +00:00
/*
KWin - the KDE window manager
This file is part of the KDE project.
2020-08-02 22:22:19 +00:00
SPDX-FileCopyrightText: 2014 Martin Gräßlin <mgraesslin@kde.org>
2020-08-02 22:22:19 +00:00
SPDX-License-Identifier: GPL-2.0-or-later
*/
#ifndef MOCK_EFFECTS_HANDLER_H
#define MOCK_EFFECTS_HANDLER_H
#include <kwineffects.h>
#include <QX11Info>
class MockEffectsHandler : public KWin::EffectsHandler
{
Q_OBJECT
public:
explicit MockEffectsHandler(KWin::CompositingType type);
void activateWindow(KWin::EffectWindow *) override {}
Run clang-tidy with modernize-use-override check Summary: Currently code base of kwin can be viewed as two pieces. One is very ancient, and the other one is more modern, which uses new C++ features. The main problem with the ancient code is that it was written before C++11 era. So, no override or final keywords, lambdas, etc. Quite recently, KDE compiler settings were changed to show a warning if a virtual method has missing override keyword. As you might have already guessed, this fired back at us because of that ancient code. We had about 500 new compiler warnings. A "solution" was proposed to that problem - disable -Wno-suggest-override and the other similar warning for clang. It's hard to call a solution because those warnings are disabled not only for the old code, but also for new. This is not what we want! The main argument for not actually fixing the problem was that git history will be screwed as well because of human factor. While good git history is a very important thing, we should not go crazy about it and block every change that somehow alters git history. git blame allows to specify starting revision for a reason. The other argument (human factor) can be easily solved by using tools such as clang-tidy. clang-tidy is a clang-based linter for C++. It can be used for various things, e.g. fixing coding style(e.g. add missing braces to if statements, readability-braces-around-statements check), or in our case add missing override keywords. Test Plan: Compiles. Reviewers: #kwin, davidedmundson Reviewed By: #kwin, davidedmundson Subscribers: davidedmundson, apol, romangg, kwin Tags: #kwin Differential Revision: https://phabricator.kde.org/D22371
2019-07-22 16:52:26 +00:00
KWin::Effect *activeFullScreenEffect() const override {
return nullptr;
}
bool hasActiveFullScreenEffect() const override {
return false;
}
int activeScreen() const override {
return 0;
}
KWin::EffectWindow *activeWindow() const override {
return nullptr;
}
void addRepaint(const QRect &) override {}
void addRepaint(const QRegion &) override {}
void addRepaint(int, int, int, int) override {}
void addRepaintFull() override {}
double animationTimeFactor() const override {
return 0;
}
xcb_atom_t announceSupportProperty(const QByteArray &, KWin::Effect *) override {
return XCB_ATOM_NONE;
}
void buildQuads(KWin::EffectWindow *, KWin::WindowQuadList &) override {}
QRect clientArea(KWin::clientAreaOption, const QPoint &, int) const override {
return QRect();
}
QRect clientArea(KWin::clientAreaOption, const KWin::EffectWindow *) const override {
return QRect();
}
QRect clientArea(KWin::clientAreaOption, int, int) const override {
return QRect();
}
void closeTabBox() override {}
QString currentActivity() const override {
return QString();
}
int currentDesktop() const override {
return 0;
}
int currentTabBoxDesktop() const override {
return 0;
}
QList< int > currentTabBoxDesktopList() const override {
return QList<int>();
}
KWin::EffectWindow *currentTabBoxWindow() const override {
return nullptr;
}
KWin::EffectWindowList currentTabBoxWindowList() const override {
return KWin::EffectWindowList();
}
QPoint cursorPos() const override {
return QPoint();
}
bool decorationsHaveAlpha() const override {
return false;
}
bool decorationSupportsBlurBehind() const override {
return false;
}
void defineCursor(Qt::CursorShape) override {}
int desktopAbove(int, bool) const override {
return 0;
}
int desktopAtCoords(QPoint) const override {
return 0;
}
int desktopBelow(int, bool) const override {
return 0;
}
QPoint desktopCoords(int) const override {
return QPoint();
}
QPoint desktopGridCoords(int) const override {
return QPoint();
}
int desktopGridHeight() const override {
return 0;
}
QSize desktopGridSize() const override {
return QSize();
}
int desktopGridWidth() const override {
return 0;
}
QString desktopName(int) const override {
return QString();
}
int desktopToLeft(int, bool) const override {
return 0;
}
int desktopToRight(int, bool) const override {
return 0;
}
void doneOpenGLContextCurrent() override {}
void drawWindow(KWin::EffectWindow *, int, const QRegion &, KWin::WindowPaintData &) override {}
KWin::EffectFrame *effectFrame(KWin::EffectFrameStyle, bool, const QPoint &, Qt::Alignment) const override {
return nullptr;
}
KWin::EffectWindow *findWindow(WId) const override {
return nullptr;
}
KWin::EffectWindow *findWindow(KWaylandServer::SurfaceInterface *) const override {
return nullptr;
}
Add windowsystem plugin for KWin's qpa Summary: KWindowSystem provides a plugin interface to have platform specific implementations. So far KWin relied on the implementation in KWayland-integration repository. This is something I find unsuited, for the following reasons: * any test in KWin for functionality set through the plugin would fail * it's not clear what's going on where * in worst case some code could deadlock * KWin shouldn't use KWindowSystem and only a small subset is allowed to be used The last point needs some further explanation. KWin internally does not and cannot use KWindowSystem. KWindowSystem (especially KWindowInfo) is exposing information which KWin sets. It's more than weird if KWin asks KWindowSystem for the state of a window it set itself. On X11 it's just slow, on Wayland it can result in roundtrips to KWin itself which is dangerous. But due to using Plasma components we have a few areas where we use KWindowSystem. E.g. a Plasma::Dialog sets a window type, the slide in direction, blur and background contrast. This we want to support and need to support. Other API elements we do not want, like for examples the available windows. KWin internal windows either have direct access to KWin or a scripting interface exposed providing (limited) access - there is just no need to have this in KWindowSystem. To make it more clear what KWin supports as API of KWindowSystem for internal windows this change implements a stripped down version of the kwayland-integration plugin. The main difference is that it does not use KWayland at all, but a QWindow internal side channel. To support this EffectWindow provides an accessor for internalWindow and the three already mentioned effects are adjusted to read from the internal QWindow and it's dynamic properties. This change is a first step for a further refactoring. I plan to split the internal window out of ShellClient into a dedicated class. I think there are nowadays too many special cases. If it moves out there is the question whether we really want to use Wayland for the internal windows or whether this is just historic ballast (after all we used to use qwayland for that in the beginning). As the change could introduce regressions I'm targetting 5.16. Test Plan: new test case for window type, manual testing using Alt+Tab for the effects integration. Sliding popups, blur and contrast worked fine. Reviewers: #kwin Subscribers: kwin Tags: #kwin Differential Revision: https://phabricator.kde.org/D18228
2019-01-13 16:50:32 +00:00
KWin::EffectWindow *findWindow(QWindow *w) const override {
Q_UNUSED(w)
Add windowsystem plugin for KWin's qpa Summary: KWindowSystem provides a plugin interface to have platform specific implementations. So far KWin relied on the implementation in KWayland-integration repository. This is something I find unsuited, for the following reasons: * any test in KWin for functionality set through the plugin would fail * it's not clear what's going on where * in worst case some code could deadlock * KWin shouldn't use KWindowSystem and only a small subset is allowed to be used The last point needs some further explanation. KWin internally does not and cannot use KWindowSystem. KWindowSystem (especially KWindowInfo) is exposing information which KWin sets. It's more than weird if KWin asks KWindowSystem for the state of a window it set itself. On X11 it's just slow, on Wayland it can result in roundtrips to KWin itself which is dangerous. But due to using Plasma components we have a few areas where we use KWindowSystem. E.g. a Plasma::Dialog sets a window type, the slide in direction, blur and background contrast. This we want to support and need to support. Other API elements we do not want, like for examples the available windows. KWin internal windows either have direct access to KWin or a scripting interface exposed providing (limited) access - there is just no need to have this in KWindowSystem. To make it more clear what KWin supports as API of KWindowSystem for internal windows this change implements a stripped down version of the kwayland-integration plugin. The main difference is that it does not use KWayland at all, but a QWindow internal side channel. To support this EffectWindow provides an accessor for internalWindow and the three already mentioned effects are adjusted to read from the internal QWindow and it's dynamic properties. This change is a first step for a further refactoring. I plan to split the internal window out of ShellClient into a dedicated class. I think there are nowadays too many special cases. If it moves out there is the question whether we really want to use Wayland for the internal windows or whether this is just historic ballast (after all we used to use qwayland for that in the beginning). As the change could introduce regressions I'm targetting 5.16. Test Plan: new test case for window type, manual testing using Alt+Tab for the effects integration. Sliding popups, blur and contrast worked fine. Reviewers: #kwin Subscribers: kwin Tags: #kwin Differential Revision: https://phabricator.kde.org/D18228
2019-01-13 16:50:32 +00:00
return nullptr;
}
KWin::EffectWindow *findWindow(const QUuid &id) const override {
Q_UNUSED(id)
return nullptr;
}
void *getProxy(QString) override {
return nullptr;
}
bool grabKeyboard(KWin::Effect *) override {
return false;
}
bool hasDecorationShadows() const override {
return false;
}
bool isScreenLocked() const override {
return false;
}
QVariant kwinOption(KWin::KWinOption) override {
return QVariant();
}
bool makeOpenGLContextCurrent() override {
return false;
}
void moveWindow(KWin::EffectWindow *, const QPoint &, bool, double) override {}
KWin::WindowQuadType newWindowQuadType() override {
return KWin::WindowQuadError;
}
int numberOfDesktops() const override {
return 0;
}
int numScreens() const override {
return 0;
}
bool optionRollOverDesktops() const override {
return false;
}
void paintEffectFrame(KWin::EffectFrame *, const QRegion &, double, double) override {}
void paintScreen(int, const QRegion &, KWin::ScreenPaintData &) override {}
void paintWindow(KWin::EffectWindow *, int, const QRegion &, KWin::WindowPaintData &) override {}
void postPaintScreen() override {}
void postPaintWindow(KWin::EffectWindow *) override {}
Provide expected presentation time to effects Effects are given the interval between two consecutive frames. The main flaw of this approach is that if the Compositor transitions from the idle state to "active" state, i.e. when there is something to repaint, effects may see a very large interval between the last painted frame and the current. In order to address this issue, the Scene invalidates the timer that is used to measure time between consecutive frames before the Compositor is about to become idle. While this works perfectly fine with Xinerama-style rendering, with per screen rendering, determining whether the compositor is about to idle is rather a tedious task mostly because a single output can't be used for the test. Furthermore, since the Compositor schedules pointless repaints just to ensure that it's idle, it might take several attempts to figure out whether the scene timer must be invalidated if you use (true) per screen rendering. Ideally, all effects should use a timeline helper that is aware of the underlying render loop and its timings. However, this option is off the table because it will involve a lot of work to implement it. Alternative and much simpler option is to pass the expected presentation time to effects rather than time between consecutive frames. This means that effects are responsible for determining how much animation timelines have to be advanced. Typically, an effect would have to store the presentation timestamp provided in either prePaint{Screen,Window} and use it in the subsequent prePaint{Screen,Window} call to estimate the amount of time passed between the next and the last frames. Unfortunately, this is an API incompatible change. However, it shouldn't take a lot of work to port third-party binary effects, which don't use the AnimationEffect class, to the new API. On the bright side, we no longer need to be concerned about the Compositor getting idle. We do still try to determine whether the Compositor is about to idle, primarily, because the OpenGL render backend swaps buffers on present, but that will change with the ongoing compositing timing rework.
2020-11-20 15:44:04 +00:00
void prePaintScreen(KWin::ScreenPrePaintData &, std::chrono::milliseconds) override {}
void prePaintWindow(KWin::EffectWindow *, KWin::WindowPrePaintData &, std::chrono::milliseconds) override {}
QByteArray readRootProperty(long int, long int, int) const override {
return QByteArray();
}
void reconfigure() override {}
void refTabBox() override {}
void registerAxisShortcut(Qt::KeyboardModifiers, KWin::PointerAxisDirection, QAction *) override {}
void registerGlobalShortcut(const QKeySequence &, QAction *) override {}
void registerPointerShortcut(Qt::KeyboardModifiers, Qt::MouseButton, QAction *) override {}
Add support for global touchpad swipe gestures 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
2017-03-18 10:00:30 +00:00
void registerTouchpadSwipeShortcut(KWin::SwipeDirection, QAction *) override {}
void reloadEffect(KWin::Effect *) override {}
void removeSupportProperty(const QByteArray &, KWin::Effect *) override {}
void reserveElectricBorder(KWin::ElectricBorder, KWin::Effect *) override {}
void registerTouchBorder(KWin::ElectricBorder, QAction *) override {}
void unregisterTouchBorder(KWin::ElectricBorder, QAction *) override {}
QPainter *scenePainter() override {
return nullptr;
}
int screenNumber(const QPoint &) const override {
return 0;
}
void setActiveFullScreenEffect(KWin::Effect *) override {}
void setCurrentDesktop(int) override {}
void setElevatedWindow(KWin::EffectWindow *, bool) override {}
void setNumberOfDesktops(int) override {}
void setShowingDesktop(bool) override {}
void setTabBoxDesktop(int) override {}
void setTabBoxWindow(KWin::EffectWindow*) override {}
KWin::EffectWindowList stackingOrder() const override {
return KWin::EffectWindowList();
}
void startMouseInterception(KWin::Effect *, Qt::CursorShape) override {}
void startMousePolling() override {}
void stopMouseInterception(KWin::Effect *) override {}
void stopMousePolling() override {}
void ungrabKeyboard() override {}
void unrefTabBox() override {}
void unreserveElectricBorder(KWin::ElectricBorder, KWin::Effect *) override {}
QRect virtualScreenGeometry() const override {
return QRect();
}
QSize virtualScreenSize() const override {
return QSize();
}
void windowToDesktop(KWin::EffectWindow *, int) override {}
void windowToScreen(KWin::EffectWindow *, int) override {}
int workspaceHeight() const override {
return 0;
}
int workspaceWidth() const override {
return 0;
}
long unsigned int xrenderBufferPicture() override {
return 0;
}
xcb_connection_t *xcbConnection() const override {
return QX11Info::connection();
}
xcb_window_t x11RootWindow() const override {
return QX11Info::appRootWindow();
}
KWaylandServer::Display *waylandDisplay() const override {
return nullptr;
}
bool animationsSupported() const override {
return m_animationsSuported;
}
void setAnimationsSupported(bool set) {
m_animationsSuported = set;
}
KWin::PlatformCursorImage cursorImage() const override {
return KWin::PlatformCursorImage();
}
void hideCursor() override {}
void showCursor() override {}
void startInteractiveWindowSelection(std::function<void(KWin::EffectWindow*)> callback) override {
callback(nullptr);
}
void startInteractivePositionSelection(std::function<void (const QPoint &)> callback) override {
callback(QPoint(-1, -1));
}
void showOnScreenMessage(const QString &message, const QString &iconName = QString()) override {
Q_UNUSED(message)
Q_UNUSED(iconName)
}
void hideOnScreenMessage(OnScreenMessageHideFlags flags = OnScreenMessageHideFlags()) override { Q_UNUSED(flags)}
Run clang-tidy with modernize-use-override check Summary: Currently code base of kwin can be viewed as two pieces. One is very ancient, and the other one is more modern, which uses new C++ features. The main problem with the ancient code is that it was written before C++11 era. So, no override or final keywords, lambdas, etc. Quite recently, KDE compiler settings were changed to show a warning if a virtual method has missing override keyword. As you might have already guessed, this fired back at us because of that ancient code. We had about 500 new compiler warnings. A "solution" was proposed to that problem - disable -Wno-suggest-override and the other similar warning for clang. It's hard to call a solution because those warnings are disabled not only for the old code, but also for new. This is not what we want! The main argument for not actually fixing the problem was that git history will be screwed as well because of human factor. While good git history is a very important thing, we should not go crazy about it and block every change that somehow alters git history. git blame allows to specify starting revision for a reason. The other argument (human factor) can be easily solved by using tools such as clang-tidy. clang-tidy is a clang-based linter for C++. It can be used for various things, e.g. fixing coding style(e.g. add missing braces to if statements, readability-braces-around-statements check), or in our case add missing override keywords. Test Plan: Compiles. Reviewers: #kwin, davidedmundson Reviewed By: #kwin, davidedmundson Subscribers: davidedmundson, apol, romangg, kwin Tags: #kwin Differential Revision: https://phabricator.kde.org/D22371
2019-07-22 16:52:26 +00:00
void windowToDesktops(KWin::EffectWindow *w, const QVector<uint> &desktops) override {
Q_UNUSED(w)
Q_UNUSED(desktops)
}
KSharedConfigPtr config() const override;
KSharedConfigPtr inputConfig() const override;
[libkwineffects] Introduce API to easily show a QtQuick scene in an effect Summary: EffectQuickView/Scene is a convenient class to render a QtQuick scenegraph into an effect. Current methods (such as present windows) involve creating an underlying platform window which is expensive, causes a headache to filter out again in the rest of the code, and only works as an overlay. The new class exposes things more natively to an effect where we don't mess with real windows, we can perform the painting anywhere in the view and we don't have issues with hiding/closing. QtQuick has both software and hardware accelerated modes, and kwin also has 3 render backends. Every combination is supported. * When used in OpenGL mode for both, we render into an FBO export the texture ID then it's up to the effect to render that into a scene. * When using software QtQuick rendering we blit into an image, upload that into a KWinGLTexture which serves as an abstraction layer and render that into the scene. * When using GL for QtQuick and XRender/QPainter in kwin everything is rendered into the internal FBO, blit and exported as an image. * When using software rendering for both an image gets passed directly. Mouse and keyboard events can be forwarded, only if the effect intercepts them. The class is meant to be generic enough that we can remove all the QtQuick code from Aurorae. The intention is also to replace EffectFrameImpl using this backend and we can kill all of the EffectFrame code throughout the scenes. The close button in present windows will also be ported to this, simplifiying that code base. Classes that handle the rendering and handling QML are intentionally split so that in the future we can have a declarative effects API create overlays from within the same context. Similar to how one can instantiate windows from a typical QML scene. Notes: I don't like how I pass the kwin GL context from the backends into the effect, but I need something that works with the library separation. It also currently has wayland problem if I create a QOpenGLContext before the QPA is set up with a scene - but I don't have anything better? I know for the EffectFrame we need an API to push things through the effects stack to handle blur/invert etc. Will deal with that when we port the EffectFrame. Test Plan: Used in an effect Reviewers: #kwin, zzag Reviewed By: #kwin, zzag Subscribers: zzag, kwin Tags: #kwin Differential Revision: https://phabricator.kde.org/D24215
2019-09-27 15:06:37 +00:00
void renderEffectQuickView(KWin::EffectQuickView *quickView) const override {
Q_UNUSED(quickView);
}
KWin::SessionState sessionState() const override {
return KWin::SessionState::Normal;
}
private:
bool m_animationsSuported = true;
};
#endif