yukijoou/kwin
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions
kwin/src/internal_client.h

92 lines
3 KiB
C
Raw Normal View History

Prettify license headers
2020-08-02 22:22:19 +00:00
/*
KWin - the KDE window manager
This file is part of the KDE project.
Split out a dedicated InternalClient class Summary: Most of the functionality which is special to internal clients is moved from ShellClient to InternalClient. As KWin's qpa is still bound to the Wayland protocol InternalClient inherits from ShellClient. Due to that some aspects in ShellClient are "weird". ShellClient still detects whether it's an internal client and uses the variable m_internal to capture the state. This is required as we cannot use the isInternal method. Most of m_internal usage is in init which is called from constructor of ShellClient. Thus it's not possible to call into virtual methods of InternalClient. Also some of the code is duplicated and some methods are temporarily marked as virtual. The next step will be to remove ShmBuffer for internal windows which should decouple the two implementations further with the long term goal of having InternalClient inherit AbstractClient directly. Test Plan: Run nested KWin, triggered outline (OpenGL case) and debug console (shm case). InternalWindow unit test still passes. Reviewers: #kwin Subscribers: kwin Tags: #kwin Differential Revision: https://phabricator.kde.org/D18569
2019-01-27 19:48:00 +00:00
Prettify license headers
2020-08-02 22:22:19 +00:00
SPDX-FileCopyrightText: 2019 Martin Flöser <mgraesslin@kde.org>
SPDX-FileCopyrightText: 2019 Vlad Zahorodnii <vlad.zahorodnii@kde.org>
Split out a dedicated InternalClient class Summary: Most of the functionality which is special to internal clients is moved from ShellClient to InternalClient. As KWin's qpa is still bound to the Wayland protocol InternalClient inherits from ShellClient. Due to that some aspects in ShellClient are "weird". ShellClient still detects whether it's an internal client and uses the variable m_internal to capture the state. This is required as we cannot use the isInternal method. Most of m_internal usage is in init which is called from constructor of ShellClient. Thus it's not possible to call into virtual methods of InternalClient. Also some of the code is duplicated and some methods are temporarily marked as virtual. The next step will be to remove ShmBuffer for internal windows which should decouple the two implementations further with the long term goal of having InternalClient inherit AbstractClient directly. Test Plan: Run nested KWin, triggered outline (OpenGL case) and debug console (shm case). InternalWindow unit test still passes. Reviewers: #kwin Subscribers: kwin Tags: #kwin Differential Revision: https://phabricator.kde.org/D18569
2019-01-27 19:48:00 +00:00
Prettify license headers
2020-08-02 22:22:19 +00:00
SPDX-License-Identifier: GPL-2.0-or-later
*/
Split out a dedicated InternalClient class Summary: Most of the functionality which is special to internal clients is moved from ShellClient to InternalClient. As KWin's qpa is still bound to the Wayland protocol InternalClient inherits from ShellClient. Due to that some aspects in ShellClient are "weird". ShellClient still detects whether it's an internal client and uses the variable m_internal to capture the state. This is required as we cannot use the isInternal method. Most of m_internal usage is in init which is called from constructor of ShellClient. Thus it's not possible to call into virtual methods of InternalClient. Also some of the code is duplicated and some methods are temporarily marked as virtual. The next step will be to remove ShmBuffer for internal windows which should decouple the two implementations further with the long term goal of having InternalClient inherit AbstractClient directly. Test Plan: Run nested KWin, triggered outline (OpenGL case) and debug console (shm case). InternalWindow unit test still passes. Reviewers: #kwin Subscribers: kwin Tags: #kwin Differential Revision: https://phabricator.kde.org/D18569
2019-01-27 19:48:00 +00:00
#pragma once
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
#include "abstract_client.h"
Split out a dedicated InternalClient class Summary: Most of the functionality which is special to internal clients is moved from ShellClient to InternalClient. As KWin's qpa is still bound to the Wayland protocol InternalClient inherits from ShellClient. Due to that some aspects in ShellClient are "weird". ShellClient still detects whether it's an internal client and uses the variable m_internal to capture the state. This is required as we cannot use the isInternal method. Most of m_internal usage is in init which is called from constructor of ShellClient. Thus it's not possible to call into virtual methods of InternalClient. Also some of the code is duplicated and some methods are temporarily marked as virtual. The next step will be to remove ShmBuffer for internal windows which should decouple the two implementations further with the long term goal of having InternalClient inherit AbstractClient directly. Test Plan: Run nested KWin, triggered outline (OpenGL case) and debug console (shm case). InternalWindow unit test still passes. Reviewers: #kwin Subscribers: kwin Tags: #kwin Differential Revision: https://phabricator.kde.org/D18569
2019-01-27 19:48:00 +00:00
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 KWIN_EXPORT InternalClient : public AbstractClient
Split out a dedicated InternalClient class Summary: Most of the functionality which is special to internal clients is moved from ShellClient to InternalClient. As KWin's qpa is still bound to the Wayland protocol InternalClient inherits from ShellClient. Due to that some aspects in ShellClient are "weird". ShellClient still detects whether it's an internal client and uses the variable m_internal to capture the state. This is required as we cannot use the isInternal method. Most of m_internal usage is in init which is called from constructor of ShellClient. Thus it's not possible to call into virtual methods of InternalClient. Also some of the code is duplicated and some methods are temporarily marked as virtual. The next step will be to remove ShmBuffer for internal windows which should decouple the two implementations further with the long term goal of having InternalClient inherit AbstractClient directly. Test Plan: Run nested KWin, triggered outline (OpenGL case) and debug console (shm case). InternalWindow unit test still passes. Reviewers: #kwin Subscribers: kwin Tags: #kwin Differential Revision: https://phabricator.kde.org/D18569
2019-01-27 19:48:00 +00:00
{
Q_OBJECT
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
Split out a dedicated InternalClient class Summary: Most of the functionality which is special to internal clients is moved from ShellClient to InternalClient. As KWin's qpa is still bound to the Wayland protocol InternalClient inherits from ShellClient. Due to that some aspects in ShellClient are "weird". ShellClient still detects whether it's an internal client and uses the variable m_internal to capture the state. This is required as we cannot use the isInternal method. Most of m_internal usage is in init which is called from constructor of ShellClient. Thus it's not possible to call into virtual methods of InternalClient. Also some of the code is duplicated and some methods are temporarily marked as virtual. The next step will be to remove ShmBuffer for internal windows which should decouple the two implementations further with the long term goal of having InternalClient inherit AbstractClient directly. Test Plan: Run nested KWin, triggered outline (OpenGL case) and debug console (shm case). InternalWindow unit test still passes. Reviewers: #kwin Subscribers: kwin Tags: #kwin Differential Revision: https://phabricator.kde.org/D18569
2019-01-27 19:48:00 +00:00
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 InternalClient(QWindow *window);
Split out a dedicated InternalClient class Summary: Most of the functionality which is special to internal clients is moved from ShellClient to InternalClient. As KWin's qpa is still bound to the Wayland protocol InternalClient inherits from ShellClient. Due to that some aspects in ShellClient are "weird". ShellClient still detects whether it's an internal client and uses the variable m_internal to capture the state. This is required as we cannot use the isInternal method. Most of m_internal usage is in init which is called from constructor of ShellClient. Thus it's not possible to call into virtual methods of InternalClient. Also some of the code is duplicated and some methods are temporarily marked as virtual. The next step will be to remove ShmBuffer for internal windows which should decouple the two implementations further with the long term goal of having InternalClient inherit AbstractClient directly. Test Plan: Run nested KWin, triggered outline (OpenGL case) and debug console (shm case). InternalWindow unit test still passes. Reviewers: #kwin Subscribers: kwin Tags: #kwin Differential Revision: https://phabricator.kde.org/D18569
2019-01-27 19:48:00 +00:00
~InternalClient() override;
bool eventFilter(QObject *watched, QEvent *event) override;
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
qreal bufferScale() const override;
QString captionNormal() const override;
QString captionSuffix() const override;
Honor minimum and maximum size of InternalClient Reviewers: #kwin, davidedmundson Reviewed By: #kwin, davidedmundson Subscribers: kwin Tags: #kwin Differential Revision: https://phabricator.kde.org/D26831
2020-02-12 10:44:10 +00:00
QSize minSize() const override;
QSize maxSize() const override;
Split out a dedicated InternalClient class Summary: Most of the functionality which is special to internal clients is moved from ShellClient to InternalClient. As KWin's qpa is still bound to the Wayland protocol InternalClient inherits from ShellClient. Due to that some aspects in ShellClient are "weird". ShellClient still detects whether it's an internal client and uses the variable m_internal to capture the state. This is required as we cannot use the isInternal method. Most of m_internal usage is in init which is called from constructor of ShellClient. Thus it's not possible to call into virtual methods of InternalClient. Also some of the code is duplicated and some methods are temporarily marked as virtual. The next step will be to remove ShmBuffer for internal windows which should decouple the two implementations further with the long term goal of having InternalClient inherit AbstractClient directly. Test Plan: Run nested KWin, triggered outline (OpenGL case) and debug console (shm case). InternalWindow unit test still passes. Reviewers: #kwin Subscribers: kwin Tags: #kwin Differential Revision: https://phabricator.kde.org/D18569
2019-01-27 19:48:00 +00:00
NET::WindowType windowType(bool direct = false, int supported_types = 0) const override;
void killWindow() override;
Make Toplevel::isClient() return true for internal and wayland windows It's needed to merge Toplevel and AbstractClient. Previously, we couldn't do it because Toplevel::isClient() was somewhat widely used.
2021-05-25 16:06:17 +00:00
bool isClient() const override;
Split out a dedicated InternalClient class Summary: Most of the functionality which is special to internal clients is moved from ShellClient to InternalClient. As KWin's qpa is still bound to the Wayland protocol InternalClient inherits from ShellClient. Due to that some aspects in ShellClient are "weird". ShellClient still detects whether it's an internal client and uses the variable m_internal to capture the state. This is required as we cannot use the isInternal method. Most of m_internal usage is in init which is called from constructor of ShellClient. Thus it's not possible to call into virtual methods of InternalClient. Also some of the code is duplicated and some methods are temporarily marked as virtual. The next step will be to remove ShmBuffer for internal windows which should decouple the two implementations further with the long term goal of having InternalClient inherit AbstractClient directly. Test Plan: Run nested KWin, triggered outline (OpenGL case) and debug console (shm case). InternalWindow unit test still passes. Reviewers: #kwin Subscribers: kwin Tags: #kwin Differential Revision: https://phabricator.kde.org/D18569
2019-01-27 19:48:00 +00:00
bool isPopupWindow() const override;
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
QByteArray windowRole() const override;
Split out a dedicated InternalClient class Summary: Most of the functionality which is special to internal clients is moved from ShellClient to InternalClient. As KWin's qpa is still bound to the Wayland protocol InternalClient inherits from ShellClient. Due to that some aspects in ShellClient are "weird". ShellClient still detects whether it's an internal client and uses the variable m_internal to capture the state. This is required as we cannot use the isInternal method. Most of m_internal usage is in init which is called from constructor of ShellClient. Thus it's not possible to call into virtual methods of InternalClient. Also some of the code is duplicated and some methods are temporarily marked as virtual. The next step will be to remove ShmBuffer for internal windows which should decouple the two implementations further with the long term goal of having InternalClient inherit AbstractClient directly. Test Plan: Run nested KWin, triggered outline (OpenGL case) and debug console (shm case). InternalWindow unit test still passes. Reviewers: #kwin Subscribers: kwin Tags: #kwin Differential Revision: https://phabricator.kde.org/D18569
2019-01-27 19:48:00 +00:00
void closeWindow() override;
bool isCloseable() const override;
bool isMovable() const override;
bool isMovableAcrossScreens() const override;
bool isResizable() const override;
Use better window placement heuristics for internal clients Currently, we do some sort of window placement only for decorated internal windows, which feels hacky. With this change, all internal clients will go through the window placement code, unless it's a popup or the BypassWindowManagerHint flag is set. If the BypassWindowManagerHint flag is set, the window must have valid position. CCBUG: 400675
2020-09-23 13:24:10 +00:00
bool isPlaceable() const override;
Split out a dedicated InternalClient class Summary: Most of the functionality which is special to internal clients is moved from ShellClient to InternalClient. As KWin's qpa is still bound to the Wayland protocol InternalClient inherits from ShellClient. Due to that some aspects in ShellClient are "weird". ShellClient still detects whether it's an internal client and uses the variable m_internal to capture the state. This is required as we cannot use the isInternal method. Most of m_internal usage is in init which is called from constructor of ShellClient. Thus it's not possible to call into virtual methods of InternalClient. Also some of the code is duplicated and some methods are temporarily marked as virtual. The next step will be to remove ShmBuffer for internal windows which should decouple the two implementations further with the long term goal of having InternalClient inherit AbstractClient directly. Test Plan: Run nested KWin, triggered outline (OpenGL case) and debug console (shm case). InternalWindow unit test still passes. Reviewers: #kwin Subscribers: kwin Tags: #kwin Differential Revision: https://phabricator.kde.org/D18569
2019-01-27 19:48:00 +00:00
bool noBorder() const override;
bool userCanSetNoBorder() const override;
bool wantsInput() const override;
bool isInternal() const override;
bool isLockScreen() const override;
[wayland] Make sure that only the fading popups effect animates outline Summary: Window open/close animation effects should not animate the outline because the end result is a bit awkward. Reviewers: #kwin, davidedmundson Reviewed By: #kwin, davidedmundson Subscribers: kwin Tags: #kwin Differential Revision: https://phabricator.kde.org/D19886
2019-03-19 14:01:29 +00:00
bool isOutline() const override;
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 isShown(bool shaded_is_shown) const override;
bool isHiddenInternal() const override;
void hideClient(bool hide) override;
Remove force geometry flags With the client-side decoration changes, kwin will properly determine whether the window needs to be configured even if the frame geometry has not changed. This change slightly changes the semantics of the setFrameGeometry() method. Prior to this, it was possible to force a geometry, i.e. block other geometry updates, however such a behavior is counter-intuitive and it exponentially increases the complexity of code. As far as I know, the force flag was needed to propagate geometry changes if the frame geometry doesn't change, but the client geometry does. With the client-side decoration changes, the force flag is not needed, as kwin now takes into account the client geometry and the frame geometry when determining whether to send a configure event.
2021-04-25 08:52:30 +00:00
void resizeWithChecks(const QSize &size) override;
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
AbstractClient *findModal(bool allow_itself = false) override;
Check if we successfully restored input focus In rare cases, Workspace::restoreFocus() may fail, for example when the most recently activated client is about to be destroyed or unmapped. If it happens that we cannot restore the focus, then mark the window in FocusIn event as active. CCBUG: 424223
2020-07-22 11:00:11 +00:00
bool takeFocus() override;
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 setNoBorder(bool set) override;
void updateDecoration(bool check_workspace_pos, bool force = false) override;
Introduce AbstractClient::destroyClient() Summary: The new method provides a generic way for destructing clients. Notice that we can't just delete clients because we may need to discard temporary window rules, which is usually done in destroyClient(). Test Plan: Compiles. Reviewers: #kwin, davidedmundson Reviewed By: #kwin, davidedmundson Subscribers: kwin Tags: #kwin Differential Revision: https://phabricator.kde.org/D27821
2020-02-19 15:22:23 +00:00
void destroyClient() override;
wayland: Introduce internal popup event filter The event filter allows dismissing the user actions menu by clicking anywhere outside of it. BUG: 428408
2021-01-30 20:29:55 +00:00
bool hasPopupGrab() const override;
void popupDone() override;
Introduce transient constraints api in Workspace Currently, the Workspace has no any api to constrain one window above another. This results in having hacks such as keepDeletedTransientAbove() This change introduces a basic api to constrain a given window above another. It can be used for ensuring that transient windows are placed above their parents. It also can be used for stacking the outline window below the move-resize window. Internal windows may also have transient parents. Because of that, this change makes the workspace add internal clients to the stacking order by default. The good thing about it is that it allows us unify some input related code for "external" windows and internal windows.
2021-05-09 15:07:36 +00:00
bool hitTest(const QPoint &point) const override;
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 present(const QSharedPointer<QOpenGLFramebufferObject> fbo);
void present(const QImage &image, const QRegion &damage);
QWindow *internalWindow() const;
Split out a dedicated InternalClient class Summary: Most of the functionality which is special to internal clients is moved from ShellClient to InternalClient. As KWin's qpa is still bound to the Wayland protocol InternalClient inherits from ShellClient. Due to that some aspects in ShellClient are "weird". ShellClient still detects whether it's an internal client and uses the variable m_internal to capture the state. This is required as we cannot use the isInternal method. Most of m_internal usage is in init which is called from constructor of ShellClient. Thus it's not possible to call into virtual methods of InternalClient. Also some of the code is duplicated and some methods are temporarily marked as virtual. The next step will be to remove ShmBuffer for internal windows which should decouple the two implementations further with the long term goal of having InternalClient inherit AbstractClient directly. Test Plan: Run nested KWin, triggered outline (OpenGL case) and debug console (shm case). InternalWindow unit test still passes. Reviewers: #kwin Subscribers: kwin Tags: #kwin Differential Revision: https://phabricator.kde.org/D18569
2019-01-27 19:48:00 +00:00
protected:
bool acceptsFocus() const override;
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 belongsToSameApplication(const AbstractClient *other, SameApplicationChecks checks) const override;
Prepend "Interactive" to interactive move resize methods This is to improve code readability and make it easier to differentiate between methods that are used during interactive move-resize and normal move-resize methods in the future.
2021-04-30 18:06:58 +00:00
void doInteractiveResizeSync() override;
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 updateCaption() override;
Rework async geometry updates Window management features were written with synchronous geometry updates in mind. Currently, this poses a big problem on Wayland because geometry updates are done in asynchronous fashion there. At the moment, geometry is updated in a so called pseudo-asynchronous fashion, meaning that the frame geometry will be reset to the old value once geometry updates are unblocked. The main drawback of this approach is that it is too error prone, the data flow is hard to comprehend, etc. It is worth noting that there is already a machinery to perform async geometry which is used during interactive move/resize operations. This change extends the move/resize geometry usage beyond interactive move/resize to make asynchronous geometry updates less error prone and easier to comprehend. With the proposed solution, all geometry updates must be done on the move/resize geometry first. After that, the new geometry is passed on to the Client-specific implementation of moveResizeInternal(). To be more specific, the frameGeometry() returns the current frame geometry, it is primarily useful only to the scene. If you want to move or resize a window, you need to use moveResizeGeometry() because it corresponds to the last requested frame geometry. It is worth noting that the moveResizeGeometry() returns the desired bounding geometry. The client may commit the xdg_toplevel surface with a slightly smaller window geometry, for example to enforce a specific aspect ratio. The client is not allowed to resize beyond the size as indicated in moveResizeGeometry(). The data flow is very simple: moveResize() updates the move/resize geometry and calls the client-specific implementation of the moveResizeInternal() method. Based on whether a configure event is needed, moveResizeInternal() will update the frameGeometry() either immediately or after the client commits a new buffer. Unfortunately, both the compositor and xdg-shell clients try to update the window geometry. It means that it's possible to have conflicts between the two. With this change, the compositor's move resize geometry will be synced only if there are no pending configure events, meaning that the user doesn't try to resize the window.
2021-04-30 18:26:09 +00:00
void moveResizeInternal(const QRect &rect, MoveResizeMode mode) override;
Split out a dedicated InternalClient class Summary: Most of the functionality which is special to internal clients is moved from ShellClient to InternalClient. As KWin's qpa is still bound to the Wayland protocol InternalClient inherits from ShellClient. Due to that some aspects in ShellClient are "weird". ShellClient still detects whether it's an internal client and uses the variable m_internal to capture the state. This is required as we cannot use the isInternal method. Most of m_internal usage is in init which is called from constructor of ShellClient. Thus it's not possible to call into virtual methods of InternalClient. Also some of the code is duplicated and some methods are temporarily marked as virtual. The next step will be to remove ShmBuffer for internal windows which should decouple the two implementations further with the long term goal of having InternalClient inherit AbstractClient directly. Test Plan: Run nested KWin, triggered outline (OpenGL case) and debug console (shm case). InternalWindow unit test still passes. Reviewers: #kwin Subscribers: kwin Tags: #kwin Differential Revision: https://phabricator.kde.org/D18569
2019-01-27 19:48:00 +00:00
private:
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 requestGeometry(const QRect &rect);
void commitGeometry(const QRect &rect);
void setCaption(const QString &caption);
void markAsMapped();
Split out a dedicated InternalClient class Summary: Most of the functionality which is special to internal clients is moved from ShellClient to InternalClient. As KWin's qpa is still bound to the Wayland protocol InternalClient inherits from ShellClient. Due to that some aspects in ShellClient are "weird". ShellClient still detects whether it's an internal client and uses the variable m_internal to capture the state. This is required as we cannot use the isInternal method. Most of m_internal usage is in init which is called from constructor of ShellClient. Thus it's not possible to call into virtual methods of InternalClient. Also some of the code is duplicated and some methods are temporarily marked as virtual. The next step will be to remove ShmBuffer for internal windows which should decouple the two implementations further with the long term goal of having InternalClient inherit AbstractClient directly. Test Plan: Run nested KWin, triggered outline (OpenGL case) and debug console (shm case). InternalWindow unit test still passes. Reviewers: #kwin Subscribers: kwin Tags: #kwin Differential Revision: https://phabricator.kde.org/D18569
2019-01-27 19:48:00 +00:00
void syncGeometryToInternalWindow();
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 updateInternalWindowGeometry();
Split out a dedicated InternalClient class Summary: Most of the functionality which is special to internal clients is moved from ShellClient to InternalClient. As KWin's qpa is still bound to the Wayland protocol InternalClient inherits from ShellClient. Due to that some aspects in ShellClient are "weird". ShellClient still detects whether it's an internal client and uses the variable m_internal to capture the state. This is required as we cannot use the isInternal method. Most of m_internal usage is in init which is called from constructor of ShellClient. Thus it's not possible to call into virtual methods of InternalClient. Also some of the code is duplicated and some methods are temporarily marked as virtual. The next step will be to remove ShmBuffer for internal windows which should decouple the two implementations further with the long term goal of having InternalClient inherit AbstractClient directly. Test Plan: Run nested KWin, triggered outline (OpenGL case) and debug console (shm case). InternalWindow unit test still passes. Reviewers: #kwin Subscribers: kwin Tags: #kwin Differential Revision: https://phabricator.kde.org/D18569
2019-01-27 19:48:00 +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
QWindow *m_internalWindow = nullptr;
QString m_captionNormal;
QString m_captionSuffix;
Split out a dedicated InternalClient class Summary: Most of the functionality which is special to internal clients is moved from ShellClient to InternalClient. As KWin's qpa is still bound to the Wayland protocol InternalClient inherits from ShellClient. Due to that some aspects in ShellClient are "weird". ShellClient still detects whether it's an internal client and uses the variable m_internal to capture the state. This is required as we cannot use the isInternal method. Most of m_internal usage is in init which is called from constructor of ShellClient. Thus it's not possible to call into virtual methods of InternalClient. Also some of the code is duplicated and some methods are temporarily marked as virtual. The next step will be to remove ShmBuffer for internal windows which should decouple the two implementations further with the long term goal of having InternalClient inherit AbstractClient directly. Test Plan: Run nested KWin, triggered outline (OpenGL case) and debug console (shm case). InternalWindow unit test still passes. Reviewers: #kwin Subscribers: kwin Tags: #kwin Differential Revision: https://phabricator.kde.org/D18569
2019-01-27 19:48:00 +00:00
NET::WindowType m_windowType = NET::Normal;
Qt::WindowFlags m_internalWindowFlags = Qt::WindowFlags();
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_userNoBorder = false;
Q_DISABLE_COPY(InternalClient)
Split out a dedicated InternalClient class Summary: Most of the functionality which is special to internal clients is moved from ShellClient to InternalClient. As KWin's qpa is still bound to the Wayland protocol InternalClient inherits from ShellClient. Due to that some aspects in ShellClient are "weird". ShellClient still detects whether it's an internal client and uses the variable m_internal to capture the state. This is required as we cannot use the isInternal method. Most of m_internal usage is in init which is called from constructor of ShellClient. Thus it's not possible to call into virtual methods of InternalClient. Also some of the code is duplicated and some methods are temporarily marked as virtual. The next step will be to remove ShmBuffer for internal windows which should decouple the two implementations further with the long term goal of having InternalClient inherit AbstractClient directly. Test Plan: Run nested KWin, triggered outline (OpenGL case) and debug console (shm case). InternalWindow unit test still passes. Reviewers: #kwin Subscribers: kwin Tags: #kwin Differential Revision: https://phabricator.kde.org/D18569
2019-01-27 19:48:00 +00:00
};
}
Reference in a new issue Copy permalink