kwin/plugins/windowsystem/windowsystem.cpp

315 lines
6 KiB
C++
Raw Normal View History

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
/*
2020-08-02 22:22:19 +00:00
SPDX-FileCopyrightText: 2019 Martin Flöser <mgraesslin@kde.org>
SPDX-License-Identifier: GPL-2.0-only OR GPL-3.0-only OR LicenseRef-KDE-Accepted-GPL
*/
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
#include "windowsystem.h"
#include <KWindowSystem/KWindowSystem>
#include <QGuiApplication>
#include <QWindow>
Q_DECLARE_METATYPE(NET::WindowType)
namespace KWin
{
WindowSystem::WindowSystem()
: QObject()
, KWindowSystemPrivate()
{
}
void WindowSystem::activateWindow(WId win, long int time)
{
Q_UNUSED(win)
Q_UNUSED(time)
// KWin cannot activate own windows
}
void WindowSystem::forceActiveWindow(WId win, long int time)
{
Q_UNUSED(win)
Q_UNUSED(time)
// KWin cannot activate own windows
}
WId WindowSystem::activeWindow()
{
// KWin internal should not use KWindowSystem to find active window
return 0;
}
bool WindowSystem::allowedActionsSupported()
{
return false;
}
void WindowSystem::allowExternalProcessWindowActivation(int pid)
{
Q_UNUSED(pid)
}
bool WindowSystem::compositingActive()
{
// wayland is always composited
return true;
}
void WindowSystem::connectNotify(const QMetaMethod &signal)
{
Q_UNUSED(signal)
}
QPoint WindowSystem::constrainViewportRelativePosition(const QPoint &pos)
{
Q_UNUSED(pos)
return QPoint();
}
int WindowSystem::currentDesktop()
{
// KWin internal should not use KWindowSystem to find current desktop
return 0;
}
void WindowSystem::demandAttention(WId win, bool set)
{
Q_UNUSED(win)
Q_UNUSED(set)
}
QString WindowSystem::desktopName(int desktop)
{
Q_UNUSED(desktop)
return QString();
}
QPoint WindowSystem::desktopToViewport(int desktop, bool absolute)
{
Q_UNUSED(desktop)
Q_UNUSED(absolute)
return QPoint();
}
#if KWINDOWSYSTEM_BUILD_DEPRECATED_SINCE(5, 0)
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
WId WindowSystem::groupLeader(WId window)
{
Q_UNUSED(window)
return 0;
}
#endif
bool WindowSystem::icccmCompliantMappingState()
{
return false;
}
QPixmap WindowSystem::icon(WId win, int width, int height, bool scale, int flags)
{
Q_UNUSED(win)
Q_UNUSED(width)
Q_UNUSED(height)
Q_UNUSED(scale)
Q_UNUSED(flags)
return QPixmap();
}
void WindowSystem::lowerWindow(WId win)
{
Q_UNUSED(win)
}
bool WindowSystem::mapViewport()
{
return false;
}
void WindowSystem::minimizeWindow(WId win)
{
Q_UNUSED(win)
}
void WindowSystem::unminimizeWindow(WId win)
{
Q_UNUSED(win)
}
int WindowSystem::numberOfDesktops()
{
// KWin internal should not use KWindowSystem to find number of desktops
return 1;
}
void WindowSystem::raiseWindow(WId win)
{
Q_UNUSED(win)
}
QString WindowSystem::readNameProperty(WId window, long unsigned int atom)
{
Q_UNUSED(window)
Q_UNUSED(atom)
return QString();
}
void WindowSystem::setBlockingCompositing(WId window, bool active)
{
Q_UNUSED(window)
Q_UNUSED(active)
}
void WindowSystem::setCurrentDesktop(int desktop)
{
Q_UNUSED(desktop)
// KWin internal should not use KWindowSystem to set current desktop
}
void WindowSystem::setDesktopName(int desktop, const QString &name)
{
Q_UNUSED(desktop)
Q_UNUSED(name)
// KWin internal should not use KWindowSystem to set desktop name
}
void WindowSystem::setExtendedStrut(WId win, int left_width, int left_start, int left_end, int right_width, int right_start, int right_end, int top_width, int top_start, int top_end, int bottom_width, int bottom_start, int bottom_end)
{
Q_UNUSED(win)
Q_UNUSED(left_width)
Q_UNUSED(left_start)
Q_UNUSED(left_end)
Q_UNUSED(right_width)
Q_UNUSED(right_start)
Q_UNUSED(right_end)
Q_UNUSED(top_width)
Q_UNUSED(top_start)
Q_UNUSED(top_end)
Q_UNUSED(bottom_width)
Q_UNUSED(bottom_start)
Q_UNUSED(bottom_end)
}
void WindowSystem::setStrut(WId win, int left, int right, int top, int bottom)
{
Q_UNUSED(win)
Q_UNUSED(left)
Q_UNUSED(right)
Q_UNUSED(top)
Q_UNUSED(bottom)
}
void WindowSystem::setIcons(WId win, const QPixmap &icon, const QPixmap &miniIcon)
{
Q_UNUSED(win)
Q_UNUSED(icon)
Q_UNUSED(miniIcon)
}
void WindowSystem::setOnActivities(WId win, const QStringList &activities)
{
Q_UNUSED(win)
Q_UNUSED(activities)
}
void WindowSystem::setOnAllDesktops(WId win, bool b)
{
Q_UNUSED(win)
Q_UNUSED(b)
}
void WindowSystem::setOnDesktop(WId win, int desktop)
{
Q_UNUSED(win)
Q_UNUSED(desktop)
}
void WindowSystem::setShowingDesktop(bool showing)
{
Q_UNUSED(showing)
// KWin should not use KWindowSystem to set showing desktop state
}
void WindowSystem::clearState(WId win, NET::States state)
{
// KWin's windows don't support state
Q_UNUSED(win)
Q_UNUSED(state)
}
void WindowSystem::setState(WId win, NET::States state)
{
// KWin's windows don't support state
Q_UNUSED(win)
Q_UNUSED(state)
}
void WindowSystem::setType(WId win, NET::WindowType windowType)
{
const auto windows = qApp->allWindows();
auto it = std::find_if(windows.begin(), windows.end(), [win] (QWindow *w) { return w->winId() == win; });
if (it == windows.end()) {
return;
}
(*it)->setProperty("kwin_windowType", QVariant::fromValue(windowType));
}
void WindowSystem::setUserTime(WId win, long int time)
{
Q_UNUSED(win)
Q_UNUSED(time)
}
bool WindowSystem::showingDesktop()
{
// KWin should not use KWindowSystem for showing desktop state
return false;
}
QList< WId > WindowSystem::stackingOrder()
{
// KWin should not use KWindowSystem for stacking order
return {};
}
#if KWINDOWSYSTEM_BUILD_DEPRECATED_SINCE(5, 0)
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
WId WindowSystem::transientFor(WId window)
{
Q_UNUSED(window)
return 0;
}
#endif
int WindowSystem::viewportToDesktop(const QPoint &pos)
{
Q_UNUSED(pos)
return 0;
}
int WindowSystem::viewportWindowToDesktop(const QRect &r)
{
Q_UNUSED(r)
return 0;
}
QList< WId > WindowSystem::windows()
{
return {};
}
QRect WindowSystem::workArea(const QList< WId > &excludes, int desktop)
{
Q_UNUSED(excludes)
Q_UNUSED(desktop)
return {};
}
QRect WindowSystem::workArea(int desktop)
{
Q_UNUSED(desktop)
return {};
}
}