yukijoou/kwin
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions
kwin/plugins/qpa/window.h

69 lines
1.8 KiB
C
Raw Normal View History

[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
/********************************************************************
KWin - the KDE window manager
This file is part of the KDE project.
Copyright (C) 2015 Martin Gräßlin <mgraesslin@kde.org>
Update my email address
2020-01-14 16:17:18 +00:00
Copyright (C) 2019 Vlad Zahorodnii <vlad.zahorodnii@kde.org>
[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
This program is free software; you can redistribute it and/or modify
it under the terms of the GNU General Public License as published by
the Free Software Foundation; either version 2 of the License, or
(at your option) any later version.
This program is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
GNU General Public License for more details.
You should have received a copy of the GNU General Public License
along with this program. If not, see <http://www.gnu.org/licenses/>.
*********************************************************************/
#ifndef KWIN_QPA_WINDOW_H
#define KWIN_QPA_WINDOW_H
#include <qpa/qplatformwindow.h>
class QOpenGLFramebufferObject;
namespace KWin
{
Port QPA away from Wayland Summary: So far wayland was used by internal clients to submit raster buffers and position themselves on the screen. While we didn't have issues with submitting raster buffers, there were some problems with positioning task switchers. Mostly, because we had effectively two paths that may alter geometry. A better approach to deal with internal clients is to let our QPA use kwin core api directly. This way we can eliminate unnecessary roundtrips as well make geometry handling much easier and comprehensible. The last missing piece is shadows. Both Plasma::Dialog and Breeze widget style use platform-specific APIs to set and unset shadows. We need to add shadows API to KWindowSystem. Even though some internal clients lack drop-shadows at the moment, I don't consider it to be a blocker. We can add shadows back later on. CCBUG: 386304 Reviewers: #kwin, davidedmundson, romangg Reviewed By: #kwin, romangg Subscribers: romangg, kwin Tags: #kwin Maniphest Tasks: T9600 Differential Revision: https://phabricator.kde.org/D22810
2019-08-26 07:44:04 +00:00
class InternalClient;
[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
namespace QPA
{
class Window : public QPlatformWindow
{
public:
Port QPA away from Wayland Summary: So far wayland was used by internal clients to submit raster buffers and position themselves on the screen. While we didn't have issues with submitting raster buffers, there were some problems with positioning task switchers. Mostly, because we had effectively two paths that may alter geometry. A better approach to deal with internal clients is to let our QPA use kwin core api directly. This way we can eliminate unnecessary roundtrips as well make geometry handling much easier and comprehensible. The last missing piece is shadows. Both Plasma::Dialog and Breeze widget style use platform-specific APIs to set and unset shadows. We need to add shadows API to KWindowSystem. Even though some internal clients lack drop-shadows at the moment, I don't consider it to be a blocker. We can add shadows back later on. CCBUG: 386304 Reviewers: #kwin, davidedmundson, romangg Reviewed By: #kwin, romangg Subscribers: romangg, kwin Tags: #kwin Maniphest Tasks: T9600 Differential Revision: https://phabricator.kde.org/D22810
2019-08-26 07:44:04 +00:00
explicit Window(QWindow *window);
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
~Window() override;
[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
void setVisible(bool visible) override;
void setGeometry(const QRect &rect) override;
WId winId() const override;
Add high DPI support to internal KWin windows Summary: So far we didn't try to do high DPI on kwin internal windows, such as the user context menu and tab bars and whatever. Due to wayland scaling they were the correct phyiscal size but upscaled. This patch fixes our QPA to enable Qt's high-dpi support. BUG: 402853 Note icons are still low res. This is because the global QGuiApplication::devicePixelRatio which is the max of all connected screens is static for the duration of the app. QIcon uses this when determining the DPR to use. This will require a Qt change. Test Plan: Ran at 2x on my normal DPI screen (as that's easier to see anything) * User action menu is high DPI * Window deco tooltips are still fine * Tab switcher is high DPI * Overlay in present windows Desktop grid are still ok Reviewers: #kwin Subscribers: zzag, kwin Tags: #kwin Differential Revision: https://phabricator.kde.org/D18042
2019-01-11 22:48:04 +00:00
qreal devicePixelRatio() const override;
[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
void bindContentFBO();
Port QPA away from Wayland Summary: So far wayland was used by internal clients to submit raster buffers and position themselves on the screen. While we didn't have issues with submitting raster buffers, there were some problems with positioning task switchers. Mostly, because we had effectively two paths that may alter geometry. A better approach to deal with internal clients is to let our QPA use kwin core api directly. This way we can eliminate unnecessary roundtrips as well make geometry handling much easier and comprehensible. The last missing piece is shadows. Both Plasma::Dialog and Breeze widget style use platform-specific APIs to set and unset shadows. We need to add shadows API to KWindowSystem. Even though some internal clients lack drop-shadows at the moment, I don't consider it to be a blocker. We can add shadows back later on. CCBUG: 386304 Reviewers: #kwin, davidedmundson, romangg Reviewed By: #kwin, romangg Subscribers: romangg, kwin Tags: #kwin Maniphest Tasks: T9600 Differential Revision: https://phabricator.kde.org/D22810
2019-08-26 07:44:04 +00:00
const QSharedPointer<QOpenGLFramebufferObject> &contentFBO() const;
[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
QSharedPointer<QOpenGLFramebufferObject> swapFBO();
Port QPA away from Wayland Summary: So far wayland was used by internal clients to submit raster buffers and position themselves on the screen. While we didn't have issues with submitting raster buffers, there were some problems with positioning task switchers. Mostly, because we had effectively two paths that may alter geometry. A better approach to deal with internal clients is to let our QPA use kwin core api directly. This way we can eliminate unnecessary roundtrips as well make geometry handling much easier and comprehensible. The last missing piece is shadows. Both Plasma::Dialog and Breeze widget style use platform-specific APIs to set and unset shadows. We need to add shadows API to KWindowSystem. Even though some internal clients lack drop-shadows at the moment, I don't consider it to be a blocker. We can add shadows back later on. CCBUG: 386304 Reviewers: #kwin, davidedmundson, romangg Reviewed By: #kwin, romangg Subscribers: romangg, kwin Tags: #kwin Maniphest Tasks: T9600 Differential Revision: https://phabricator.kde.org/D22810
2019-08-26 07:44:04 +00:00
InternalClient *client() const;
[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
private:
void createFBO();
Port QPA away from Wayland Summary: So far wayland was used by internal clients to submit raster buffers and position themselves on the screen. While we didn't have issues with submitting raster buffers, there were some problems with positioning task switchers. Mostly, because we had effectively two paths that may alter geometry. A better approach to deal with internal clients is to let our QPA use kwin core api directly. This way we can eliminate unnecessary roundtrips as well make geometry handling much easier and comprehensible. The last missing piece is shadows. Both Plasma::Dialog and Breeze widget style use platform-specific APIs to set and unset shadows. We need to add shadows API to KWindowSystem. Even though some internal clients lack drop-shadows at the moment, I don't consider it to be a blocker. We can add shadows back later on. CCBUG: 386304 Reviewers: #kwin, davidedmundson, romangg Reviewed By: #kwin, romangg Subscribers: romangg, kwin Tags: #kwin Maniphest Tasks: T9600 Differential Revision: https://phabricator.kde.org/D22810
2019-08-26 07:44:04 +00:00
void map();
void unmap();
[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
Port QPA away from Wayland Summary: So far wayland was used by internal clients to submit raster buffers and position themselves on the screen. While we didn't have issues with submitting raster buffers, there were some problems with positioning task switchers. Mostly, because we had effectively two paths that may alter geometry. A better approach to deal with internal clients is to let our QPA use kwin core api directly. This way we can eliminate unnecessary roundtrips as well make geometry handling much easier and comprehensible. The last missing piece is shadows. Both Plasma::Dialog and Breeze widget style use platform-specific APIs to set and unset shadows. We need to add shadows API to KWindowSystem. Even though some internal clients lack drop-shadows at the moment, I don't consider it to be a blocker. We can add shadows back later on. CCBUG: 386304 Reviewers: #kwin, davidedmundson, romangg Reviewed By: #kwin, romangg Subscribers: romangg, kwin Tags: #kwin Maniphest Tasks: T9600 Differential Revision: https://phabricator.kde.org/D22810
2019-08-26 07:44:04 +00:00
InternalClient *m_handle = nullptr;
[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
QSharedPointer<QOpenGLFramebufferObject> m_contentFBO;
quint32 m_windowId;
Port QPA away from Wayland Summary: So far wayland was used by internal clients to submit raster buffers and position themselves on the screen. While we didn't have issues with submitting raster buffers, there were some problems with positioning task switchers. Mostly, because we had effectively two paths that may alter geometry. A better approach to deal with internal clients is to let our QPA use kwin core api directly. This way we can eliminate unnecessary roundtrips as well make geometry handling much easier and comprehensible. The last missing piece is shadows. Both Plasma::Dialog and Breeze widget style use platform-specific APIs to set and unset shadows. We need to add shadows API to KWindowSystem. Even though some internal clients lack drop-shadows at the moment, I don't consider it to be a blocker. We can add shadows back later on. CCBUG: 386304 Reviewers: #kwin, davidedmundson, romangg Reviewed By: #kwin, romangg Subscribers: romangg, kwin Tags: #kwin Maniphest Tasks: T9600 Differential Revision: https://phabricator.kde.org/D22810
2019-08-26 07:44:04 +00:00
bool m_resized = false;
Add high DPI support to internal KWin windows Summary: So far we didn't try to do high DPI on kwin internal windows, such as the user context menu and tab bars and whatever. Due to wayland scaling they were the correct phyiscal size but upscaled. This patch fixes our QPA to enable Qt's high-dpi support. BUG: 402853 Note icons are still low res. This is because the global QGuiApplication::devicePixelRatio which is the max of all connected screens is static for the duration of the app. QIcon uses this when determining the DPR to use. This will require a Qt change. Test Plan: Ran at 2x on my normal DPI screen (as that's easier to see anything) * User action menu is high DPI * Window deco tooltips are still fine * Tab switcher is high DPI * Overlay in present windows Desktop grid are still ok Reviewers: #kwin Subscribers: zzag, kwin Tags: #kwin Differential Revision: https://phabricator.kde.org/D18042
2019-01-11 22:48:04 +00:00
int m_scale = 1;
[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
};
}
}
#endif
Reference in a new issue Copy permalink