kwin/plugins/CMakeLists.txt

add_subdirectory(kglobalaccel)
add_subdirectory(qpa)
add_subdirectory(idletime)
add_subdirectory(platforms)
add_subdirectory(scenes)
add_subdirectory(windowsystem)
add_subdirectory(kpackage)

if (KWIN_BUILD_DECORATIONS)
    add_subdirectory(kdecorations)
endif()
[wayland] Add a plugin for kglobalaccel The KGlobalAccelD which gets created by KWin needs a plugin for the platform specific parts. This change introduces such a plugin. It's linked against kwin so that it can integrate with the core. On enable the plugin registers itself in the InputRedirection and GlobalShortcutsManager checks the plugin whether a shortcut got triggered. As the loading of the plugin must happen after InputRedirection is fully created a dedicated init method is added to InputRedirection. REVIEW: 124187 2015-06-26 11:47:08 +00:00			`add_subdirectory(kglobalaccel)`
[wayland] Add a QPA plugin for kwin_wayland This introduces an own QPA plugin for KWin. QtWayland's plugin is not a good solution for KWin as QtWayland is meant for Wayland clients and not for a Wayland server. Given that it makes more sense to have a very minimal QPA plugin which supports the use cases we actually have. With our own QPA plugin we should be able to improve the following areas: * no need to create Wayland server before QApplication * Qt::BypassWindowManagerHint can be supported * no workaround for creating OpenGL context in main thread * sharing OpenGL context with Qt * OpenGL context for Qt on libhybris backend The plugin supports so far the following features: * creating a QPlatformWindow using KWayland::Client (ShellSurface) * creating a QPlatformBackingStore using a ShmPool * creating a QPlatformOpenGLContext with Wayland::EGL * or creating a QPlatformOpenGLContext which shares with KWin's scene * creating a QPlatformScreen for each KWayland::Client::Output * QPlatformNativeInterface compatible to QtWayland 2015-08-14 14:52:40 +00:00			`add_subdirectory(qpa)`
Add a plugin for KIdleTime Basically a simplified fork from kwayland-integration. We cannot use the idletime plugin from kwayland-integration as it a) doesn't react on our own qpa plugin name b) performs blocking roundtrips in the main thread -> freeze This simplifies by using our internal registry and we don't even check whether Seat and Idle are announced: we know they are. Reviewed-By: Bhushan Shah 2015-11-06 11:57:24 +00:00			`add_subdirectory(idletime)`
Move backends/ to plugins/platforms/ Summary: Source code reorganization: The base class AbstractBackend got renamed to Platform, thus the "backends" are "platforms" now. As they are plugins they should go together with other KWin plugins which are nowadays in the folder plugins. So new location is plugins/platforms/ Reviewers: #plasma, sebas Subscribers: plasma-devel Projects: #plasma Differential Revision: https://phabricator.kde.org/D1353 2016-04-08 06:49:42 +00:00			`add_subdirectory(platforms)`
Move SceneXRender into a plugin Summary: First step for loading the compositor Scenes through plugins. The general idea is that we currently needlessly pull in all the Scenes although only one will be used. E.g. on X11 we pull in QPainter, although they are not compatible. On Wayland we pull in XRender although they are not compatible. Furthermore our current Scene creation strategy is not really fault tolerant and can create situations where we don't get a compositor. E.g on fbdev backend the default settings won't work as it does not support OpenGL. Long term I want to tackle those conceptional problems together: we try to load all plugins supported by the current platform till we have a scene which works. Thus on Wayland we don't end up in a situation where we don't have a working compositor because the configuration is bad. To make this possible the switch statement in the Scene needs to go and needs to be replaced by a for loop iterating over all the available scenes on the platform. If we go there it makes sense to replace it directly with a plugin based approach. So this is a change which tackles the problem by first introducing the plugin loading. The xrender based scene (as it's the most simple one) is moved into a plugin. It is first tried to find a scene plugin and only if there is none the existing code is used. Test Plan: Tested all scenes Reviewers: #kwin, #plasma Subscribers: plasma-devel, kwin Tags: #kwin Differential Revision: https://phabricator.kde.org/D7232 2017-08-10 16:13:42 +00:00			`add_subdirectory(scenes)`
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			`add_subdirectory(windowsystem)`
Move package structure plugins to plugins dir Summary: Package structure plugins are not that special so move them to the corresponding directory. Test Plan: Compiles. Reviewers: #kwin Subscribers: kwin Tags: #kwin Differential Revision: https://phabricator.kde.org/D18685 2019-02-02 19:47:46 +00:00			`add_subdirectory(kpackage)`
Move clients/ to plugins/kdecorations/ Summary: KWin's plugins are now all in a plugins subdirectory. This is a good argument to also move the window decoration plugins there. The name clients was not really good anyway and makes it difficult for people not familiar with the code base to find it. Having it under plugins is the more expectable location. Reviewers: #plasma Subscribers: plasma-devel Projects: #plasma Differential Revision: https://phabricator.kde.org/D1414 2016-04-15 08:34:57 +00:00
Cleanup style in CMakeLists.txt files We have lots of inconsistency at the moment in CMakeLists.txt files. Most of it is due to kwin being a very old project. This change hopefully fixes all of it. 2019-09-17 09:15:35 +00:00			`if (KWIN_BUILD_DECORATIONS)`
Move clients/ to plugins/kdecorations/ Summary: KWin's plugins are now all in a plugins subdirectory. This is a good argument to also move the window decoration plugins there. The name clients was not really good anyway and makes it difficult for people not familiar with the code base to find it. Having it under plugins is the more expectable location. Reviewers: #plasma Subscribers: plasma-devel Projects: #plasma Differential Revision: https://phabricator.kde.org/D1414 2016-04-15 08:34:57 +00:00			`add_subdirectory(kdecorations)`
			`endif()`