kwin/x11client.h

664 lines
22 KiB
C
Raw Normal View History

/********************************************************************
KWin - the KDE window manager
This file is part of the KDE project.
Copyright (C) 1999, 2000 Matthias Ettrich <ettrich@kde.org>
Copyright (C) 2003 Lubos Lunak <l.lunak@kde.org>
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/>.
*********************************************************************/
#pragma once
// kwin
#include "options.h"
#include "rules.h"
#include "abstract_client.h"
#include "xcbutils.h"
// Qt
#include <QElapsedTimer>
2014-12-02 12:50:26 +00:00
#include <QFlags>
#include <QPointer>
#include <QPixmap>
#include <QWindow>
// X
2013-07-31 08:11:39 +00:00
#include <xcb/sync.h>
// TODO: Cleanup the order of things in this .h file
class QTimer;
class KStartupInfoData;
class KStartupInfoId;
namespace KWin
{
/**
* @brief Defines Predicates on how to search for a Client.
*
* Used by Workspace::findClient.
*/
enum class Predicate {
WindowMatch,
WrapperIdMatch,
FrameIdMatch,
InputIdMatch
};
class KWIN_EXPORT X11Client : public AbstractClient
2011-01-30 14:34:42 +00:00
{
Q_OBJECT
/**
* By how much the window wishes to grow/shrink at least. Usually QSize(1,1).
* MAY BE DISOBEYED BY THE WM! It's only for information, do NOT rely on it at all.
* The value is evaluated each time the getter is called.
* Because of that no changed signal is provided.
*/
Q_PROPERTY(QSize basicUnit READ basicUnit)
/**
* A client can block compositing. That is while the Client is alive and the state is set,
* Compositing is suspended and is resumed when there are no Clients blocking compositing any
* more.
*
* This is actually set by a window property, unfortunately not used by the target application
* group. For convenience it's exported as a property to the scripts.
*
* Use with care!
*/
Q_PROPERTY(bool blocksCompositing READ isBlockingCompositing WRITE setBlockingCompositing NOTIFY blockingCompositingChanged)
Add a script to enforce window decorations for GTK windows This is going to be a controversal change. It enforces KWin decorations on all client side decorated windows from GTK+. Unfortunately we are caught between a rock and a hard place. Keeping the status quo means having broken windows and a more or less broken window manager due to GTK+ including the shadow in the windows. This is no solution. Enforcing server side decorations visually breaks the windows. This is also no solution. So why do it? It's our task to provide the best possible user experience and KWin is a window manager which has always done great efforts to fix misbehaving windows. One can think of the focus stealing prevention, the window rules and lately the scripts. The best possible window management experience is our aim. This means we cannot leave the users with the broken windows from GTK. The issues we noticed were reported to GTK+ about 2 months ago and we are working on improving the situation. Unfortunately several issues are not yet addressed and others will only be addressed in the next GTK+ release. We are working on improving the NETWM spec (see [1]) to ensure that the client side decorated windows are not in a broken state. This means the enforcment is a temporary solution and will be re-evaluated with the next GTK release. I would prefer to not have to do such a change, if some of the bugs were fixed or GTK+ would not use client-side-decos on wms not yet supporting those all of this would be a no issue. For a complete list of the problems caused by GTK's decos see bug [2] and the linked bug reports from there. The change is done in a least inversive way in KWin. We just check for the property _GTK_FRAME_EXTENTS and create a Q_PROPERTY in Client for it. If we add support for the frame extents in future we would also need this. So it's not a change just for enforcing the decoration. The actual enforcing is done through a KWin script so users can still disable it. REVIEW: 119062 [1] https://mail.gnome.org/archives/wm-spec-list/2014-June/msg00002.html [2] https://bugzilla.gnome.org/show_bug.cgi?id=729721
2014-07-01 13:44:02 +00:00
/**
* Whether the Client uses client side window decorations.
* Only GTK+ are detected.
*/
Add a script to enforce window decorations for GTK windows This is going to be a controversal change. It enforces KWin decorations on all client side decorated windows from GTK+. Unfortunately we are caught between a rock and a hard place. Keeping the status quo means having broken windows and a more or less broken window manager due to GTK+ including the shadow in the windows. This is no solution. Enforcing server side decorations visually breaks the windows. This is also no solution. So why do it? It's our task to provide the best possible user experience and KWin is a window manager which has always done great efforts to fix misbehaving windows. One can think of the focus stealing prevention, the window rules and lately the scripts. The best possible window management experience is our aim. This means we cannot leave the users with the broken windows from GTK. The issues we noticed were reported to GTK+ about 2 months ago and we are working on improving the situation. Unfortunately several issues are not yet addressed and others will only be addressed in the next GTK+ release. We are working on improving the NETWM spec (see [1]) to ensure that the client side decorated windows are not in a broken state. This means the enforcment is a temporary solution and will be re-evaluated with the next GTK release. I would prefer to not have to do such a change, if some of the bugs were fixed or GTK+ would not use client-side-decos on wms not yet supporting those all of this would be a no issue. For a complete list of the problems caused by GTK's decos see bug [2] and the linked bug reports from there. The change is done in a least inversive way in KWin. We just check for the property _GTK_FRAME_EXTENTS and create a Q_PROPERTY in Client for it. If we add support for the frame extents in future we would also need this. So it's not a change just for enforcing the decoration. The actual enforcing is done through a KWin script so users can still disable it. REVIEW: 119062 [1] https://mail.gnome.org/archives/wm-spec-list/2014-June/msg00002.html [2] https://bugzilla.gnome.org/show_bug.cgi?id=729721
2014-07-01 13:44:02 +00:00
Q_PROPERTY(bool clientSideDecorated READ isClientSideDecorated NOTIFY clientSideDecoratedChanged)
2011-01-30 14:34:42 +00:00
public:
explicit X11Client();
~X11Client() override; ///< Use destroyClient() or releaseWindow()
xcb_window_t wrapperId() const;
xcb_window_t inputId() const { return m_decoInputExtent; }
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
xcb_window_t frameId() const override;
2011-01-30 14:34:42 +00:00
QRect inputGeometry() const override;
QRect bufferGeometry() const override;
QMargins bufferMargins() const override;
[x11] Add support for _GTK_FRAME_EXTENTS Summary: KDE is known for having a strong view on the client-side decorations vs server-side decorations issue. The main argument raised against CSD is that desktop will look less consistent when clients start drawing window decorations by themselves, which is somewhat true. It all ties to how well each toolkit is integrated with the desktop environment. KDE doesn't control the desktop market on Linux. Another big "player" is GNOME. Both KDE and GNOME have very polarized views on in which direction desktop should move forward. The KDE community is pushing more toward server-side decorations while the GNOME community is pushing more toward client-side decorations. Both communities have developed great applications and it's not rare to see a GNOME application being used in KDE Plasma. The only problem is that these different views are not left behind the curtain and our users pay the price. Resizing GTK clients in Plasma became practically impossible due to resize borders having small hit area. When a client draws its window decoration, it's more likely that it also draws the drop-shadow around the decoration. The compositor must know the extents of the shadow so things like snapping and so on work as expected. And here lies the problem... While the xdg-shell protocol has a way to specify such things, the NetWM spec doesn't have anything like that. There's _GTK_FRAME_EXTENTS in the wild, however the problem with it is that it's a proprietary atom, which is specific only to GTK apps. Due to that, _GTK_FRAME_EXTENTS wasn't implemented because implementing anything like that would require major changes in how we think about geometry. Recent xdg-shell window geometry patches adjusted geometry abstractions in kwin to such a degree that it's very easy to add support for client side decorated clients on X11. We just have to make sure that the X11Client class provides correct buffer geometry and frame geometry when the gtk frame extents are set. Even though the X11 code is feature frozen, I still think it's worth to have _GTK_FRAME_EXTENTS support in kwin because it will fix the resize issues. Also, because KWin/Wayland is unfortunately far from becoming default, it will help us with testing some implementation bits of the window geometry from xdg-shell. BUG: 390550 FIXED-IN: 5.18.0 Test Plan: Things like quick tiling, maximizing, tiling scripts and so on work as expected with GTK clients. Reviewers: #kwin, davidedmundson Reviewed By: #kwin, davidedmundson Subscribers: cblack, trmdi, kwin Tags: #kwin Differential Revision: https://phabricator.kde.org/D24660
2019-10-08 08:46:59 +00:00
QPoint framePosToClientPos(const QPoint &point) const override;
QPoint clientPosToFramePos(const QPoint &point) const override;
QSize frameSizeToClientSize(const QSize &size) const override;
QSize clientSizeToFrameSize(const QSize &size) const override;
QRect frameRectToBufferRect(const QRect &rect) const;
[x11] Add support for _GTK_FRAME_EXTENTS Summary: KDE is known for having a strong view on the client-side decorations vs server-side decorations issue. The main argument raised against CSD is that desktop will look less consistent when clients start drawing window decorations by themselves, which is somewhat true. It all ties to how well each toolkit is integrated with the desktop environment. KDE doesn't control the desktop market on Linux. Another big "player" is GNOME. Both KDE and GNOME have very polarized views on in which direction desktop should move forward. The KDE community is pushing more toward server-side decorations while the GNOME community is pushing more toward client-side decorations. Both communities have developed great applications and it's not rare to see a GNOME application being used in KDE Plasma. The only problem is that these different views are not left behind the curtain and our users pay the price. Resizing GTK clients in Plasma became practically impossible due to resize borders having small hit area. When a client draws its window decoration, it's more likely that it also draws the drop-shadow around the decoration. The compositor must know the extents of the shadow so things like snapping and so on work as expected. And here lies the problem... While the xdg-shell protocol has a way to specify such things, the NetWM spec doesn't have anything like that. There's _GTK_FRAME_EXTENTS in the wild, however the problem with it is that it's a proprietary atom, which is specific only to GTK apps. Due to that, _GTK_FRAME_EXTENTS wasn't implemented because implementing anything like that would require major changes in how we think about geometry. Recent xdg-shell window geometry patches adjusted geometry abstractions in kwin to such a degree that it's very easy to add support for client side decorated clients on X11. We just have to make sure that the X11Client class provides correct buffer geometry and frame geometry when the gtk frame extents are set. Even though the X11 code is feature frozen, I still think it's worth to have _GTK_FRAME_EXTENTS support in kwin because it will fix the resize issues. Also, because KWin/Wayland is unfortunately far from becoming default, it will help us with testing some implementation bits of the window geometry from xdg-shell. BUG: 390550 FIXED-IN: 5.18.0 Test Plan: Things like quick tiling, maximizing, tiling scripts and so on work as expected with GTK clients. Reviewers: #kwin, davidedmundson Reviewed By: #kwin, davidedmundson Subscribers: cblack, trmdi, kwin Tags: #kwin Differential Revision: https://phabricator.kde.org/D24660
2019-10-08 08:46:59 +00:00
QMatrix4x4 inputTransformation() const override;
bool isTransient() const override;
bool groupTransient() const override;
2011-01-30 14:34:42 +00:00
bool wasOriginallyGroupTransient() const;
QList<AbstractClient*> mainClients() const override; // Call once before loop , is not indirect
bool hasTransient(const AbstractClient* c, bool indirect) const override;
void checkTransient(xcb_window_t w);
AbstractClient* findModal(bool allow_itself = false) override;
const Group* group() const override;
Group* group() override;
void checkGroup(Group* gr = nullptr, bool force = false);
2011-01-30 14:34:42 +00:00
void changeClientLeaderGroup(Group* gr);
void updateWindowRules(Rules::Types selection) override;
void applyWindowRules() override;
2011-01-30 14:34:42 +00:00
void updateFullscreenMonitors(NETFullscreenMonitors topology);
bool hasNETSupport() const;
QSize minSize() const override;
QSize maxSize() const override;
QSize basicUnit() const;
QPoint inputPos() const { return input_offset; } // Inside of geometry()
2011-01-30 14:34:42 +00:00
bool windowEvent(xcb_generic_event_t *e);
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
NET::WindowType windowType(bool direct = false, int supported_types = 0) const override;
bool manage(xcb_window_t w, bool isMapped);
2011-01-30 14:34:42 +00:00
void releaseWindow(bool on_shutdown = false);
void destroyClient() override;
2011-01-30 14:34:42 +00:00
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
QStringList activities() const override;
2011-01-30 14:34:42 +00:00
void setOnActivity(const QString &activity, bool enable);
void setOnAllActivities(bool set) override;
void setOnActivities(QStringList newActivitiesList) override;
2011-01-30 14:34:42 +00:00
void updateActivities(bool includeTransients);
void blockActivityUpdates(bool b = true) override;
2011-01-30 14:34:42 +00:00
/// Is not minimized and not hidden. I.e. normally visible on some virtual desktop.
bool isShown(bool shaded_is_shown) const override;
bool isHiddenInternal() const override; // For compositing
2011-01-30 14:34:42 +00:00
bool isShadeable() const override;
bool isMaximizable() const override;
MaximizeMode maximizeMode() const override;
bool isMinimizable() const override;
QRect iconGeometry() const override;
2011-01-30 14:34:42 +00:00
bool isFullScreenable() const override;
void setFullScreen(bool set, bool user = true) override;
bool isFullScreen() const override;
bool userCanSetFullScreen() const override;
2011-01-30 14:34:42 +00:00
QRect geometryFSRestore() const {
return geom_fs_restore; // only for session saving
2011-01-30 14:34:42 +00:00
}
int fullScreenMode() const {
return m_fullscreenMode; // only for session saving
2011-01-30 14:34:42 +00:00
}
bool userNoBorder() const;
bool noBorder() const override;
void setNoBorder(bool set) override;
bool userCanSetNoBorder() const override;
void checkNoBorder() override;
2011-01-30 14:34:42 +00:00
int sessionStackingOrder() const;
// Auxiliary functions, depend on the windowType
bool wantsInput() const override;
2011-01-30 14:34:42 +00:00
bool isResizable() const override;
bool isMovable() const override;
bool isMovableAcrossScreens() const override;
bool isCloseable() const override; ///< May be closed by the user (May have a close button)
2011-01-30 14:34:42 +00:00
bool takeFocus() override;
2011-01-30 14:34:42 +00:00
void updateDecoration(bool check_workspace_pos, bool force = false) override;
2011-01-30 14:34:42 +00:00
void updateShape();
[x11] Add support for _GTK_FRAME_EXTENTS Summary: KDE is known for having a strong view on the client-side decorations vs server-side decorations issue. The main argument raised against CSD is that desktop will look less consistent when clients start drawing window decorations by themselves, which is somewhat true. It all ties to how well each toolkit is integrated with the desktop environment. KDE doesn't control the desktop market on Linux. Another big "player" is GNOME. Both KDE and GNOME have very polarized views on in which direction desktop should move forward. The KDE community is pushing more toward server-side decorations while the GNOME community is pushing more toward client-side decorations. Both communities have developed great applications and it's not rare to see a GNOME application being used in KDE Plasma. The only problem is that these different views are not left behind the curtain and our users pay the price. Resizing GTK clients in Plasma became practically impossible due to resize borders having small hit area. When a client draws its window decoration, it's more likely that it also draws the drop-shadow around the decoration. The compositor must know the extents of the shadow so things like snapping and so on work as expected. And here lies the problem... While the xdg-shell protocol has a way to specify such things, the NetWM spec doesn't have anything like that. There's _GTK_FRAME_EXTENTS in the wild, however the problem with it is that it's a proprietary atom, which is specific only to GTK apps. Due to that, _GTK_FRAME_EXTENTS wasn't implemented because implementing anything like that would require major changes in how we think about geometry. Recent xdg-shell window geometry patches adjusted geometry abstractions in kwin to such a degree that it's very easy to add support for client side decorated clients on X11. We just have to make sure that the X11Client class provides correct buffer geometry and frame geometry when the gtk frame extents are set. Even though the X11 code is feature frozen, I still think it's worth to have _GTK_FRAME_EXTENTS support in kwin because it will fix the resize issues. Also, because KWin/Wayland is unfortunately far from becoming default, it will help us with testing some implementation bits of the window geometry from xdg-shell. BUG: 390550 FIXED-IN: 5.18.0 Test Plan: Things like quick tiling, maximizing, tiling scripts and so on work as expected with GTK clients. Reviewers: #kwin, davidedmundson Reviewed By: #kwin, davidedmundson Subscribers: cblack, trmdi, kwin Tags: #kwin Differential Revision: https://phabricator.kde.org/D24660
2019-10-08 08:46:59 +00:00
using AbstractClient::move;
void move(int x, int y, ForceGeometry_t force = NormalGeometrySet) override;
void setFrameGeometry(const QRect &rect, ForceGeometry_t force = NormalGeometrySet) override;
2011-01-30 14:34:42 +00:00
/// plainResize() simply resizes
void plainResize(int w, int h, ForceGeometry_t force = NormalGeometrySet);
void plainResize(const QSize& s, ForceGeometry_t force = NormalGeometrySet);
2011-01-30 14:34:42 +00:00
/// resizeWithChecks() resizes according to gravity, and checks workarea position
void resizeWithChecks(const QSize &size, ForceGeometry_t force = NormalGeometrySet) override;
void resizeWithChecks(int w, int h, xcb_gravity_t gravity, ForceGeometry_t force = NormalGeometrySet);
void resizeWithChecks(const QSize& s, xcb_gravity_t gravity, ForceGeometry_t force = NormalGeometrySet);
QSize constrainClientSize(const QSize &size, SizeMode mode = SizeModeAny) const override;
2011-01-30 14:34:42 +00:00
bool providesContextHelp() const override;
2011-01-30 14:34:42 +00:00
QRect adjustedClientArea(const QRect& desktop, const QRect& area) const;
xcb_colormap_t colormap() const;
2011-01-30 14:34:42 +00:00
/// Updates visibility depending on being shaded, virtual desktop, etc.
void updateVisibility();
/// Hides a client - Basically like minimize, but without effects, it's simply hidden
void hideClient(bool hide) override;
2011-01-30 14:34:42 +00:00
bool hiddenPreview() const; ///< Window is mapped in order to get a window pixmap
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
bool setupCompositing() override;
void finishCompositing(ReleaseReason releaseReason = ReleaseReason::Release) override;
void setBlockingCompositing(bool block);
inline bool isBlockingCompositing() { return blocks_compositing; }
2011-01-30 14:34:42 +00:00
QString captionNormal() const override {
return cap_normal;
}
QString captionSuffix() const override {
return cap_suffix;
}
2011-01-30 14:34:42 +00:00
using AbstractClient::keyPressEvent;
void keyPressEvent(uint key_code, xcb_timestamp_t time); // FRAME ??
void updateMouseGrab() override;
xcb_window_t moveResizeGrabWindow() const;
2011-01-30 14:34:42 +00:00
[x11] Add support for _GTK_FRAME_EXTENTS Summary: KDE is known for having a strong view on the client-side decorations vs server-side decorations issue. The main argument raised against CSD is that desktop will look less consistent when clients start drawing window decorations by themselves, which is somewhat true. It all ties to how well each toolkit is integrated with the desktop environment. KDE doesn't control the desktop market on Linux. Another big "player" is GNOME. Both KDE and GNOME have very polarized views on in which direction desktop should move forward. The KDE community is pushing more toward server-side decorations while the GNOME community is pushing more toward client-side decorations. Both communities have developed great applications and it's not rare to see a GNOME application being used in KDE Plasma. The only problem is that these different views are not left behind the curtain and our users pay the price. Resizing GTK clients in Plasma became practically impossible due to resize borders having small hit area. When a client draws its window decoration, it's more likely that it also draws the drop-shadow around the decoration. The compositor must know the extents of the shadow so things like snapping and so on work as expected. And here lies the problem... While the xdg-shell protocol has a way to specify such things, the NetWM spec doesn't have anything like that. There's _GTK_FRAME_EXTENTS in the wild, however the problem with it is that it's a proprietary atom, which is specific only to GTK apps. Due to that, _GTK_FRAME_EXTENTS wasn't implemented because implementing anything like that would require major changes in how we think about geometry. Recent xdg-shell window geometry patches adjusted geometry abstractions in kwin to such a degree that it's very easy to add support for client side decorated clients on X11. We just have to make sure that the X11Client class provides correct buffer geometry and frame geometry when the gtk frame extents are set. Even though the X11 code is feature frozen, I still think it's worth to have _GTK_FRAME_EXTENTS support in kwin because it will fix the resize issues. Also, because KWin/Wayland is unfortunately far from becoming default, it will help us with testing some implementation bits of the window geometry from xdg-shell. BUG: 390550 FIXED-IN: 5.18.0 Test Plan: Things like quick tiling, maximizing, tiling scripts and so on work as expected with GTK clients. Reviewers: #kwin, davidedmundson Reviewed By: #kwin, davidedmundson Subscribers: cblack, trmdi, kwin Tags: #kwin Differential Revision: https://phabricator.kde.org/D24660
2019-10-08 08:46:59 +00:00
QPoint gravityAdjustment(xcb_gravity_t gravity) const;
const QPoint calculateGravitation(bool invert) const;
2011-01-30 14:34:42 +00:00
void NETMoveResize(int x_root, int y_root, NET::Direction direction);
void NETMoveResizeWindow(int flags, int x, int y, int width, int height);
void restackWindow(xcb_window_t above, int detail, NET::RequestSource source, xcb_timestamp_t timestamp,
2011-01-30 14:34:42 +00:00
bool send_event = false);
void gotPing(xcb_timestamp_t timestamp);
2011-01-30 14:34:42 +00:00
void updateUserTime(xcb_timestamp_t time = XCB_TIME_CURRENT_TIME);
xcb_timestamp_t userTime() const override;
2011-01-30 14:34:42 +00:00
bool hasUserTimeSupport() const;
/// Does 'delete c;'
static void deleteClient(X11Client *c);
2011-01-30 14:34:42 +00:00
static bool belongToSameApplication(const X11Client *c1, const X11Client *c2, SameApplicationChecks checks = SameApplicationChecks());
static bool sameAppWindowRoleMatch(const X11Client *c1, const X11Client *c2, bool active_hack);
2011-01-30 14:34:42 +00:00
void killWindow() override;
void showContextHelp() override;
2011-01-30 14:34:42 +00:00
void checkActiveModal();
StrutRect strutRect(StrutArea area) const;
StrutRects strutRects() const;
bool hasStrut() const override;
2011-01-30 14:34:42 +00:00
/**
* If shown is true the client is mapped and raised, if false
* the client is unmapped and hidden, this function is called
* when the tabbing group of the client switches its visible
* client.
*/
void setClientShown(bool shown) override;
2011-01-30 14:34:42 +00:00
/**
* Whether or not the window has a strut that expands through the invisible area of
* an xinerama setup where the monitors are not the same resolution.
*/
2011-01-30 14:34:42 +00:00
bool hasOffscreenXineramaStrut() const;
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
QRect transparentRect() const override;
2011-01-30 14:34:42 +00:00
Add a script to enforce window decorations for GTK windows This is going to be a controversal change. It enforces KWin decorations on all client side decorated windows from GTK+. Unfortunately we are caught between a rock and a hard place. Keeping the status quo means having broken windows and a more or less broken window manager due to GTK+ including the shadow in the windows. This is no solution. Enforcing server side decorations visually breaks the windows. This is also no solution. So why do it? It's our task to provide the best possible user experience and KWin is a window manager which has always done great efforts to fix misbehaving windows. One can think of the focus stealing prevention, the window rules and lately the scripts. The best possible window management experience is our aim. This means we cannot leave the users with the broken windows from GTK. The issues we noticed were reported to GTK+ about 2 months ago and we are working on improving the situation. Unfortunately several issues are not yet addressed and others will only be addressed in the next GTK+ release. We are working on improving the NETWM spec (see [1]) to ensure that the client side decorated windows are not in a broken state. This means the enforcment is a temporary solution and will be re-evaluated with the next GTK release. I would prefer to not have to do such a change, if some of the bugs were fixed or GTK+ would not use client-side-decos on wms not yet supporting those all of this would be a no issue. For a complete list of the problems caused by GTK's decos see bug [2] and the linked bug reports from there. The change is done in a least inversive way in KWin. We just check for the property _GTK_FRAME_EXTENTS and create a Q_PROPERTY in Client for it. If we add support for the frame extents in future we would also need this. So it's not a change just for enforcing the decoration. The actual enforcing is done through a KWin script so users can still disable it. REVIEW: 119062 [1] https://mail.gnome.org/archives/wm-spec-list/2014-June/msg00002.html [2] https://bugzilla.gnome.org/show_bug.cgi?id=729721
2014-07-01 13:44:02 +00:00
bool isClientSideDecorated() const;
bool wantsShadowToBeRendered() const override;
void layoutDecorationRects(QRect &left, QRect &top, QRect &right, QRect &bottom) const override;
2011-01-30 14:34:42 +00:00
Xcb::Property fetchFirstInTabBox() const;
void readFirstInTabBox(Xcb::Property &property);
void updateFirstInTabBox();
Xcb::StringProperty fetchColorScheme() const;
void readColorScheme(Xcb::StringProperty &property);
void updateColorScheme() override;
2011-01-30 14:34:42 +00:00
//sets whether the client should be faked as being on all activities (and be shown during session save)
void setSessionActivityOverride(bool needed);
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
bool isClient() const override;
2011-01-30 14:34:42 +00:00
template <typename T>
void print(T &stream) const;
void cancelFocusOutTimer();
Screenedge show support for Clients This provides a new protocol intended to be used by auto-hiding panels to make use of the centralized screen edges. To use it a Client can set an X11 property of type _KDE_NET_WM_SCREEN_EDGE_SHOW to KWin. As value it takes: * 0: top edge * 1: right edge * 2: bottom edge * 3: left edge KWin will hide the Client (hide because unmap or minimize would break it) and create an Edge. If that Edge gets triggered the Client is shown again and the property gets deleted. If the Client doesn't border the specified screen edge the Client gets shown immediately so that we never end in a situation that we cannot unhide the auto-hidden panel again. The exact process is described in the documentation of ScreenEdges. The Client can request to be shown again by deleting the property. If KWin gets restarted the state is read from the property and it is tried to create the edge as described. As this is a KWin specific extension we need to discuss what it means for Clients using this feature with other WMs: it does nothing. As the Client gets hidden by KWin and not by the Client, it just doesn't get hidden if the WM doesn't provide the feature. In case of an auto-hiding panel this seems like a good solution given that we don't want to hide it if we cannot unhide it. Of course there's the option for the Client to provide that feature itself and if that's wanted we would need to announce the feature in the _NET_SUPPORTED atom. At the moment that doesn't sound like being needed as Plasma doesn't want to provide an own implementation. The implementation comes with a small test application showing how the feature is intended to be used. REVIEW: 115910
2014-02-20 11:39:23 +00:00
/**
* Restores the Client after it had been hidden due to show on screen edge functionality.
* In addition the property gets deleted so that the Client knows that it is visible again.
*/
void showOnScreenEdge() override;
Screenedge show support for Clients This provides a new protocol intended to be used by auto-hiding panels to make use of the centralized screen edges. To use it a Client can set an X11 property of type _KDE_NET_WM_SCREEN_EDGE_SHOW to KWin. As value it takes: * 0: top edge * 1: right edge * 2: bottom edge * 3: left edge KWin will hide the Client (hide because unmap or minimize would break it) and create an Edge. If that Edge gets triggered the Client is shown again and the property gets deleted. If the Client doesn't border the specified screen edge the Client gets shown immediately so that we never end in a situation that we cannot unhide the auto-hidden panel again. The exact process is described in the documentation of ScreenEdges. The Client can request to be shown again by deleting the property. If KWin gets restarted the state is read from the property and it is tried to create the edge as described. As this is a KWin specific extension we need to discuss what it means for Clients using this feature with other WMs: it does nothing. As the Client gets hidden by KWin and not by the Client, it just doesn't get hidden if the WM doesn't provide the feature. In case of an auto-hiding panel this seems like a good solution given that we don't want to hide it if we cannot unhide it. Of course there's the option for the Client to provide that feature itself and if that's wanted we would need to announce the feature in the _NET_SUPPORTED atom. At the moment that doesn't sound like being needed as Plasma doesn't want to provide an own implementation. The implementation comes with a small test application showing how the feature is intended to be used. REVIEW: 115910
2014-02-20 11:39:23 +00:00
Xcb::StringProperty fetchApplicationMenuServiceName() const;
void readApplicationMenuServiceName(Xcb::StringProperty &property);
void checkApplicationMenuServiceName();
Xcb::StringProperty fetchApplicationMenuObjectPath() const;
void readApplicationMenuObjectPath(Xcb::StringProperty &property);
void checkApplicationMenuObjectPath();
struct SyncRequest {
xcb_sync_counter_t counter;
xcb_sync_int64_t value;
xcb_sync_alarm_t alarm;
xcb_timestamp_t lastTimestamp;
QTimer *timeout, *failsafeTimeout;
bool isPending;
};
const SyncRequest &syncRequest() const {
return m_syncRequest;
}
virtual bool wantsSyncCounter() const;
void handleSync();
static void cleanupX11();
public Q_SLOTS:
void closeWindow() override;
void updateCaption() override;
2011-01-30 14:34:42 +00:00
private:
// Handlers for X11 events
bool mapRequestEvent(xcb_map_request_event_t *e);
void unmapNotifyEvent(xcb_unmap_notify_event_t *e);
void destroyNotifyEvent(xcb_destroy_notify_event_t *e);
void configureRequestEvent(xcb_configure_request_event_t *e);
Run clang-tidy with modernize-use-override check Summary: Currently code base of kwin can be viewed as two pieces. One is very ancient, and the other one is more modern, which uses new C++ features. The main problem with the ancient code is that it was written before C++11 era. So, no override or final keywords, lambdas, etc. Quite recently, KDE compiler settings were changed to show a warning if a virtual method has missing override keyword. As you might have already guessed, this fired back at us because of that ancient code. We had about 500 new compiler warnings. A "solution" was proposed to that problem - disable -Wno-suggest-override and the other similar warning for clang. It's hard to call a solution because those warnings are disabled not only for the old code, but also for new. This is not what we want! The main argument for not actually fixing the problem was that git history will be screwed as well because of human factor. While good git history is a very important thing, we should not go crazy about it and block every change that somehow alters git history. git blame allows to specify starting revision for a reason. The other argument (human factor) can be easily solved by using tools such as clang-tidy. clang-tidy is a clang-based linter for C++. It can be used for various things, e.g. fixing coding style(e.g. add missing braces to if statements, readability-braces-around-statements check), or in our case add missing override keywords. Test Plan: Compiles. Reviewers: #kwin, davidedmundson Reviewed By: #kwin, davidedmundson Subscribers: davidedmundson, apol, romangg, kwin Tags: #kwin Differential Revision: https://phabricator.kde.org/D22371
2019-07-22 16:52:26 +00:00
void propertyNotifyEvent(xcb_property_notify_event_t *e) override;
void clientMessageEvent(xcb_client_message_event_t *e) override;
void enterNotifyEvent(xcb_enter_notify_event_t *e);
void leaveNotifyEvent(xcb_leave_notify_event_t *e);
void focusInEvent(xcb_focus_in_event_t *e);
void focusOutEvent(xcb_focus_out_event_t *e);
Run clang-tidy with modernize-use-override check Summary: Currently code base of kwin can be viewed as two pieces. One is very ancient, and the other one is more modern, which uses new C++ features. The main problem with the ancient code is that it was written before C++11 era. So, no override or final keywords, lambdas, etc. Quite recently, KDE compiler settings were changed to show a warning if a virtual method has missing override keyword. As you might have already guessed, this fired back at us because of that ancient code. We had about 500 new compiler warnings. A "solution" was proposed to that problem - disable -Wno-suggest-override and the other similar warning for clang. It's hard to call a solution because those warnings are disabled not only for the old code, but also for new. This is not what we want! The main argument for not actually fixing the problem was that git history will be screwed as well because of human factor. While good git history is a very important thing, we should not go crazy about it and block every change that somehow alters git history. git blame allows to specify starting revision for a reason. The other argument (human factor) can be easily solved by using tools such as clang-tidy. clang-tidy is a clang-based linter for C++. It can be used for various things, e.g. fixing coding style(e.g. add missing braces to if statements, readability-braces-around-statements check), or in our case add missing override keywords. Test Plan: Compiles. Reviewers: #kwin, davidedmundson Reviewed By: #kwin, davidedmundson Subscribers: davidedmundson, apol, romangg, kwin Tags: #kwin Differential Revision: https://phabricator.kde.org/D22371
2019-07-22 16:52:26 +00:00
void damageNotifyEvent() override;
bool buttonPressEvent(xcb_window_t w, int button, int state, int x, int y, int x_root, int y_root, xcb_timestamp_t time = XCB_CURRENT_TIME);
bool buttonReleaseEvent(xcb_window_t w, int button, int state, int x, int y, int x_root, int y_root);
bool motionNotifyEvent(xcb_window_t w, int state, int x, int y, int x_root, int y_root);
2011-01-30 14:34:42 +00:00
protected:
Run clang-tidy with modernize-use-override check Summary: Currently code base of kwin can be viewed as two pieces. One is very ancient, and the other one is more modern, which uses new C++ features. The main problem with the ancient code is that it was written before C++11 era. So, no override or final keywords, lambdas, etc. Quite recently, KDE compiler settings were changed to show a warning if a virtual method has missing override keyword. As you might have already guessed, this fired back at us because of that ancient code. We had about 500 new compiler warnings. A "solution" was proposed to that problem - disable -Wno-suggest-override and the other similar warning for clang. It's hard to call a solution because those warnings are disabled not only for the old code, but also for new. This is not what we want! The main argument for not actually fixing the problem was that git history will be screwed as well because of human factor. While good git history is a very important thing, we should not go crazy about it and block every change that somehow alters git history. git blame allows to specify starting revision for a reason. The other argument (human factor) can be easily solved by using tools such as clang-tidy. clang-tidy is a clang-based linter for C++. It can be used for various things, e.g. fixing coding style(e.g. add missing braces to if statements, readability-braces-around-statements check), or in our case add missing override keywords. Test Plan: Compiles. Reviewers: #kwin, davidedmundson Reviewed By: #kwin, davidedmundson Subscribers: davidedmundson, apol, romangg, kwin Tags: #kwin Differential Revision: https://phabricator.kde.org/D22371
2019-07-22 16:52:26 +00:00
void debug(QDebug& stream) const override;
void addDamage(const QRegion &damage) override;
Allow a cross-process check for same applications Summary: Commit 5d9027b110 introduced a regression in TabBox by using the generic framework inside KWin to test for same application. What I did not consider was that the code in TabBox was "broken by design". It didn't use the generic check as that is too strict and considers windows from different processes as not belonging to the same application. But this is not wanted in the case of TabBox. On the other hand the change itself is an improvement to also support Wayland in a better way and not have special handling situations. Thus just reverting would not help. Instead this change addresses the problem by extending the internal API and to allow more adjustements. So far there was already an "active_hack" boolean flag. This is extended to proper flags with an additional flag to allow cross application checks. The checks in Client which would filter out different applications check for this flag and are skipped if set. In addition ShellClient also adds support for this flag and compares for the desktop file name. Thus we get in TabBox the same behavior as before with the advantage of having a better shared code base working on both X11 and Wayland. BUG: 386043 FIXED-IN: 5.11.4 Test Plan: Started two kwrite processes on X11, clicked new in one of them, used Alt+` and verified that there are three windows shown. Reviewers: #kwin, #plasma Subscribers: plasma-devel, kwin Tags: #kwin Differential Revision: https://phabricator.kde.org/D8661
2017-11-05 09:10:17 +00:00
bool belongsToSameApplication(const AbstractClient *other, SameApplicationChecks checks) const override;
void doSetActive() override;
void doSetKeepAbove() override;
void doSetKeepBelow() override;
void doSetShade(ShadeMode previousShadeMode) override;
void doSetDesktop() override;
void doMinimize() override;
void doSetSkipPager() override;
void doSetSkipTaskbar() override;
void doSetSkipSwitcher() override;
void doSetDemandsAttention() override;
bool belongsToDesktop() const override;
bool doStartMoveResize() override;
void doPerformMoveResize() override;
bool isWaitingForMoveResizeSync() const override;
void doResizeSync() override;
QSize resizeIncrements() const override;
bool acceptsFocus() const override;
2011-01-30 14:34:42 +00:00
//Signals for the scripting interface
//Signals make an excellent way for communication
//in between objects as compared to simple function
//calls
Q_SIGNALS:
void clientManaging(KWin::X11Client *);
void clientFullScreenSet(KWin::X11Client *, bool, bool);
/**
* Emitted whenever the Client want to show it menu
*/
void showRequest();
/**
* Emitted whenever the Client's menu is closed
*/
void menuHidden();
/**
* Emitted whenever the Client's menu is available
*/
void appMenuAvailable();
/**
* Emitted whenever the Client's menu is unavailable
*/
void appMenuUnavailable();
/**
* Emitted whenever the Client's block compositing state changes.
*/
void blockingCompositingChanged(KWin::X11Client *client);
Add a script to enforce window decorations for GTK windows This is going to be a controversal change. It enforces KWin decorations on all client side decorated windows from GTK+. Unfortunately we are caught between a rock and a hard place. Keeping the status quo means having broken windows and a more or less broken window manager due to GTK+ including the shadow in the windows. This is no solution. Enforcing server side decorations visually breaks the windows. This is also no solution. So why do it? It's our task to provide the best possible user experience and KWin is a window manager which has always done great efforts to fix misbehaving windows. One can think of the focus stealing prevention, the window rules and lately the scripts. The best possible window management experience is our aim. This means we cannot leave the users with the broken windows from GTK. The issues we noticed were reported to GTK+ about 2 months ago and we are working on improving the situation. Unfortunately several issues are not yet addressed and others will only be addressed in the next GTK+ release. We are working on improving the NETWM spec (see [1]) to ensure that the client side decorated windows are not in a broken state. This means the enforcment is a temporary solution and will be re-evaluated with the next GTK release. I would prefer to not have to do such a change, if some of the bugs were fixed or GTK+ would not use client-side-decos on wms not yet supporting those all of this would be a no issue. For a complete list of the problems caused by GTK's decos see bug [2] and the linked bug reports from there. The change is done in a least inversive way in KWin. We just check for the property _GTK_FRAME_EXTENTS and create a Q_PROPERTY in Client for it. If we add support for the frame extents in future we would also need this. So it's not a change just for enforcing the decoration. The actual enforcing is done through a KWin script so users can still disable it. REVIEW: 119062 [1] https://mail.gnome.org/archives/wm-spec-list/2014-June/msg00002.html [2] https://bugzilla.gnome.org/show_bug.cgi?id=729721
2014-07-01 13:44:02 +00:00
void clientSideDecoratedChanged();
2011-01-30 14:34:42 +00:00
private:
void exportMappingState(int s); // ICCCM 4.1.3.1, 4.1.4, NETWM 2.5.1
bool isManaged() const; ///< Returns false if this client is not yet managed
void updateAllowedActions(bool force = false);
QRect fullscreenMonitorsArea(NETFullscreenMonitors topology) const;
void changeMaximize(bool horizontal, bool vertical, bool adjust) override;
2011-01-30 14:34:42 +00:00
void getWmNormalHints();
void getMotifHints();
void getIcons();
void fetchName();
void fetchIconicName();
QString readName() const;
void setCaption(const QString& s, bool force = false);
bool hasTransientInternal(const X11Client *c, bool indirect, QList<const X11Client *> &set) const;
void setShortcutInternal() override;
2011-01-30 14:34:42 +00:00
void configureRequest(int value_mask, int rx, int ry, int rw, int rh, int gravity, bool from_tool);
NETExtendedStrut strut() const;
int checkShadeGeometry(int w, int h);
void getSyncCounter();
void sendSyncRequest();
void leaveMoveResize() override;
void positionGeometryTip() override;
void establishCommandWindowGrab(uint8_t button);
void establishCommandAllGrab(uint8_t button);
void resizeDecoration();
void createDecoration(const QRect &oldgeom) override;
2011-01-30 14:34:42 +00:00
void pingWindow();
void killProcess(bool ask, xcb_timestamp_t timestamp = XCB_TIME_CURRENT_TIME);
2011-01-30 14:34:42 +00:00
void updateUrgency();
2013-05-03 08:55:37 +00:00
static void sendClientMessage(xcb_window_t w, xcb_atom_t a, xcb_atom_t protocol,
uint32_t data1 = 0, uint32_t data2 = 0, uint32_t data3 = 0);
2011-01-30 14:34:42 +00:00
void embedClient(xcb_window_t w, xcb_visualid_t visualid, xcb_colormap_t colormap, uint8_t depth);
2011-01-30 14:34:42 +00:00
void detectNoBorder();
void destroyDecoration() override;
2011-01-30 14:34:42 +00:00
void updateFrameExtents();
[x11] Add support for _GTK_FRAME_EXTENTS Summary: KDE is known for having a strong view on the client-side decorations vs server-side decorations issue. The main argument raised against CSD is that desktop will look less consistent when clients start drawing window decorations by themselves, which is somewhat true. It all ties to how well each toolkit is integrated with the desktop environment. KDE doesn't control the desktop market on Linux. Another big "player" is GNOME. Both KDE and GNOME have very polarized views on in which direction desktop should move forward. The KDE community is pushing more toward server-side decorations while the GNOME community is pushing more toward client-side decorations. Both communities have developed great applications and it's not rare to see a GNOME application being used in KDE Plasma. The only problem is that these different views are not left behind the curtain and our users pay the price. Resizing GTK clients in Plasma became practically impossible due to resize borders having small hit area. When a client draws its window decoration, it's more likely that it also draws the drop-shadow around the decoration. The compositor must know the extents of the shadow so things like snapping and so on work as expected. And here lies the problem... While the xdg-shell protocol has a way to specify such things, the NetWM spec doesn't have anything like that. There's _GTK_FRAME_EXTENTS in the wild, however the problem with it is that it's a proprietary atom, which is specific only to GTK apps. Due to that, _GTK_FRAME_EXTENTS wasn't implemented because implementing anything like that would require major changes in how we think about geometry. Recent xdg-shell window geometry patches adjusted geometry abstractions in kwin to such a degree that it's very easy to add support for client side decorated clients on X11. We just have to make sure that the X11Client class provides correct buffer geometry and frame geometry when the gtk frame extents are set. Even though the X11 code is feature frozen, I still think it's worth to have _GTK_FRAME_EXTENTS support in kwin because it will fix the resize issues. Also, because KWin/Wayland is unfortunately far from becoming default, it will help us with testing some implementation bits of the window geometry from xdg-shell. BUG: 390550 FIXED-IN: 5.18.0 Test Plan: Things like quick tiling, maximizing, tiling scripts and so on work as expected with GTK clients. Reviewers: #kwin, davidedmundson Reviewed By: #kwin, davidedmundson Subscribers: cblack, trmdi, kwin Tags: #kwin Differential Revision: https://phabricator.kde.org/D24660
2019-10-08 08:46:59 +00:00
void setClientFrameExtents(const NETStrut &strut);
2011-01-30 14:34:42 +00:00
void internalShow();
void internalHide();
void internalKeep();
void map();
void unmap();
2011-01-30 14:34:42 +00:00
void updateHiddenPreview();
2011-01-30 14:34:42 +00:00
void updateInputShape();
void updateServerGeometry();
void updateWindowPixmap();
2011-01-30 14:34:42 +00:00
xcb_timestamp_t readUserTimeMapTimestamp(const KStartupInfoId* asn_id, const KStartupInfoData* asn_data,
2011-01-30 14:34:42 +00:00
bool session) const;
xcb_timestamp_t readUserCreationTime() const;
2011-01-30 14:34:42 +00:00
void startupIdChanged();
void updateInputWindow();
Xcb::Property fetchShowOnScreenEdge() const;
void readShowOnScreenEdge(Xcb::Property &property);
Screenedge show support for Clients This provides a new protocol intended to be used by auto-hiding panels to make use of the centralized screen edges. To use it a Client can set an X11 property of type _KDE_NET_WM_SCREEN_EDGE_SHOW to KWin. As value it takes: * 0: top edge * 1: right edge * 2: bottom edge * 3: left edge KWin will hide the Client (hide because unmap or minimize would break it) and create an Edge. If that Edge gets triggered the Client is shown again and the property gets deleted. If the Client doesn't border the specified screen edge the Client gets shown immediately so that we never end in a situation that we cannot unhide the auto-hidden panel again. The exact process is described in the documentation of ScreenEdges. The Client can request to be shown again by deleting the property. If KWin gets restarted the state is read from the property and it is tried to create the edge as described. As this is a KWin specific extension we need to discuss what it means for Clients using this feature with other WMs: it does nothing. As the Client gets hidden by KWin and not by the Client, it just doesn't get hidden if the WM doesn't provide the feature. In case of an auto-hiding panel this seems like a good solution given that we don't want to hide it if we cannot unhide it. Of course there's the option for the Client to provide that feature itself and if that's wanted we would need to announce the feature in the _NET_SUPPORTED atom. At the moment that doesn't sound like being needed as Plasma doesn't want to provide an own implementation. The implementation comes with a small test application showing how the feature is intended to be used. REVIEW: 115910
2014-02-20 11:39:23 +00:00
/**
* Reads the property and creates/destroys the screen edge if required
* and shows/hides the client.
*/
Screenedge show support for Clients This provides a new protocol intended to be used by auto-hiding panels to make use of the centralized screen edges. To use it a Client can set an X11 property of type _KDE_NET_WM_SCREEN_EDGE_SHOW to KWin. As value it takes: * 0: top edge * 1: right edge * 2: bottom edge * 3: left edge KWin will hide the Client (hide because unmap or minimize would break it) and create an Edge. If that Edge gets triggered the Client is shown again and the property gets deleted. If the Client doesn't border the specified screen edge the Client gets shown immediately so that we never end in a situation that we cannot unhide the auto-hidden panel again. The exact process is described in the documentation of ScreenEdges. The Client can request to be shown again by deleting the property. If KWin gets restarted the state is read from the property and it is tried to create the edge as described. As this is a KWin specific extension we need to discuss what it means for Clients using this feature with other WMs: it does nothing. As the Client gets hidden by KWin and not by the Client, it just doesn't get hidden if the WM doesn't provide the feature. In case of an auto-hiding panel this seems like a good solution given that we don't want to hide it if we cannot unhide it. Of course there's the option for the Client to provide that feature itself and if that's wanted we would need to announce the feature in the _NET_SUPPORTED atom. At the moment that doesn't sound like being needed as Plasma doesn't want to provide an own implementation. The implementation comes with a small test application showing how the feature is intended to be used. REVIEW: 115910
2014-02-20 11:39:23 +00:00
void updateShowOnScreenEdge();
Xcb::Window m_client;
Xcb::Window m_wrapper;
Xcb::Window m_frame;
2011-01-30 14:34:42 +00:00
QStringList activityList;
int m_activityUpdatesBlocked;
bool m_blockedActivityUpdatesRequireTransients;
Xcb::Window m_moveResizeGrabWindow;
2011-01-30 14:34:42 +00:00
bool move_resize_has_keyboard_grab;
bool m_managed;
2011-01-30 14:34:42 +00:00
Xcb::GeometryHints m_geometryHints;
2011-01-30 14:34:42 +00:00
void sendSyntheticConfigureNotify();
enum MappingState {
Withdrawn, ///< Not handled, as per ICCCM WithdrawnState
Mapped, ///< The frame is mapped
Unmapped, ///< The frame is not mapped
Kept ///< The frame should be unmapped, but is kept (For compositing)
};
MappingState mapping_state;
Xcb::TransientFor fetchTransient() const;
void readTransientProperty(Xcb::TransientFor &transientFor);
2011-01-30 14:34:42 +00:00
void readTransient();
xcb_window_t verifyTransientFor(xcb_window_t transient_for, bool set);
void addTransient(AbstractClient* cl) override;
void removeTransient(AbstractClient* cl) override;
2011-01-30 14:34:42 +00:00
void removeFromMainClients();
void cleanGrouping();
void checkGroupTransients();
void setTransient(xcb_window_t new_transient_for_id);
xcb_window_t m_transientForId;
xcb_window_t m_originalTransientForId;
X11Client *shade_below;
Xcb::MotifHints m_motif;
2011-01-30 14:34:42 +00:00
uint hidden : 1; ///< Forcibly hidden by calling hide()
uint noborder : 1;
uint app_noborder : 1; ///< App requested no border via window type, shape extension, etc.
uint ignore_focus_stealing : 1; ///< Don't apply focus stealing prevention to this client
bool blocks_compositing;
2011-01-30 14:34:42 +00:00
enum FullScreenMode {
FullScreenNone,
FullScreenNormal
} m_fullscreenMode;
2011-01-30 14:34:42 +00:00
MaximizeMode max_mode;
QRect m_bufferGeometry = QRect(0, 0, 100, 100);
2011-01-30 14:34:42 +00:00
QRect geom_fs_restore;
xcb_colormap_t m_colormap;
QString cap_normal, cap_iconic, cap_suffix;
2011-01-30 14:34:42 +00:00
Group* in_group;
QTimer* ping_timer;
qint64 m_killHelperPID;
xcb_timestamp_t m_pingTimestamp;
xcb_timestamp_t m_userTime;
NET::Actions allowed_actions;
2011-01-30 14:34:42 +00:00
bool shade_geometry_change;
SyncRequest m_syncRequest;
static bool check_active_modal; ///< \see X11Client::checkActiveModal()
2011-01-30 14:34:42 +00:00
int sm_stacking_order;
friend struct ResetupRulesProcedure;
friend bool performTransiencyCheck();
Xcb::StringProperty fetchActivities() const;
void readActivities(Xcb::StringProperty &property);
2011-01-30 14:34:42 +00:00
void checkActivities();
bool activitiesDefined; //whether the x property was actually set
bool sessionActivityOverride;
bool needsXWindowMove;
Xcb::Window m_decoInputExtent;
QPoint input_offset;
QTimer *m_focusOutTimer;
QList<QMetaObject::Connection> m_connections;
QMetaObject::Connection m_edgeRemoveConnection;
QMetaObject::Connection m_edgeGeometryTrackingConnection;
[x11] Add support for _GTK_FRAME_EXTENTS Summary: KDE is known for having a strong view on the client-side decorations vs server-side decorations issue. The main argument raised against CSD is that desktop will look less consistent when clients start drawing window decorations by themselves, which is somewhat true. It all ties to how well each toolkit is integrated with the desktop environment. KDE doesn't control the desktop market on Linux. Another big "player" is GNOME. Both KDE and GNOME have very polarized views on in which direction desktop should move forward. The KDE community is pushing more toward server-side decorations while the GNOME community is pushing more toward client-side decorations. Both communities have developed great applications and it's not rare to see a GNOME application being used in KDE Plasma. The only problem is that these different views are not left behind the curtain and our users pay the price. Resizing GTK clients in Plasma became practically impossible due to resize borders having small hit area. When a client draws its window decoration, it's more likely that it also draws the drop-shadow around the decoration. The compositor must know the extents of the shadow so things like snapping and so on work as expected. And here lies the problem... While the xdg-shell protocol has a way to specify such things, the NetWM spec doesn't have anything like that. There's _GTK_FRAME_EXTENTS in the wild, however the problem with it is that it's a proprietary atom, which is specific only to GTK apps. Due to that, _GTK_FRAME_EXTENTS wasn't implemented because implementing anything like that would require major changes in how we think about geometry. Recent xdg-shell window geometry patches adjusted geometry abstractions in kwin to such a degree that it's very easy to add support for client side decorated clients on X11. We just have to make sure that the X11Client class provides correct buffer geometry and frame geometry when the gtk frame extents are set. Even though the X11 code is feature frozen, I still think it's worth to have _GTK_FRAME_EXTENTS support in kwin because it will fix the resize issues. Also, because KWin/Wayland is unfortunately far from becoming default, it will help us with testing some implementation bits of the window geometry from xdg-shell. BUG: 390550 FIXED-IN: 5.18.0 Test Plan: Things like quick tiling, maximizing, tiling scripts and so on work as expected with GTK clients. Reviewers: #kwin, davidedmundson Reviewed By: #kwin, davidedmundson Subscribers: cblack, trmdi, kwin Tags: #kwin Differential Revision: https://phabricator.kde.org/D24660
2019-10-08 08:46:59 +00:00
QMargins m_clientFrameExtents;
2011-01-30 14:34:42 +00:00
};
inline xcb_window_t X11Client::wrapperId() const
2011-01-30 14:34:42 +00:00
{
return m_wrapper;
2011-01-30 14:34:42 +00:00
}
inline bool X11Client::isClientSideDecorated() const
Add a script to enforce window decorations for GTK windows This is going to be a controversal change. It enforces KWin decorations on all client side decorated windows from GTK+. Unfortunately we are caught between a rock and a hard place. Keeping the status quo means having broken windows and a more or less broken window manager due to GTK+ including the shadow in the windows. This is no solution. Enforcing server side decorations visually breaks the windows. This is also no solution. So why do it? It's our task to provide the best possible user experience and KWin is a window manager which has always done great efforts to fix misbehaving windows. One can think of the focus stealing prevention, the window rules and lately the scripts. The best possible window management experience is our aim. This means we cannot leave the users with the broken windows from GTK. The issues we noticed were reported to GTK+ about 2 months ago and we are working on improving the situation. Unfortunately several issues are not yet addressed and others will only be addressed in the next GTK+ release. We are working on improving the NETWM spec (see [1]) to ensure that the client side decorated windows are not in a broken state. This means the enforcment is a temporary solution and will be re-evaluated with the next GTK release. I would prefer to not have to do such a change, if some of the bugs were fixed or GTK+ would not use client-side-decos on wms not yet supporting those all of this would be a no issue. For a complete list of the problems caused by GTK's decos see bug [2] and the linked bug reports from there. The change is done in a least inversive way in KWin. We just check for the property _GTK_FRAME_EXTENTS and create a Q_PROPERTY in Client for it. If we add support for the frame extents in future we would also need this. So it's not a change just for enforcing the decoration. The actual enforcing is done through a KWin script so users can still disable it. REVIEW: 119062 [1] https://mail.gnome.org/archives/wm-spec-list/2014-June/msg00002.html [2] https://bugzilla.gnome.org/show_bug.cgi?id=729721
2014-07-01 13:44:02 +00:00
{
[x11] Add support for _GTK_FRAME_EXTENTS Summary: KDE is known for having a strong view on the client-side decorations vs server-side decorations issue. The main argument raised against CSD is that desktop will look less consistent when clients start drawing window decorations by themselves, which is somewhat true. It all ties to how well each toolkit is integrated with the desktop environment. KDE doesn't control the desktop market on Linux. Another big "player" is GNOME. Both KDE and GNOME have very polarized views on in which direction desktop should move forward. The KDE community is pushing more toward server-side decorations while the GNOME community is pushing more toward client-side decorations. Both communities have developed great applications and it's not rare to see a GNOME application being used in KDE Plasma. The only problem is that these different views are not left behind the curtain and our users pay the price. Resizing GTK clients in Plasma became practically impossible due to resize borders having small hit area. When a client draws its window decoration, it's more likely that it also draws the drop-shadow around the decoration. The compositor must know the extents of the shadow so things like snapping and so on work as expected. And here lies the problem... While the xdg-shell protocol has a way to specify such things, the NetWM spec doesn't have anything like that. There's _GTK_FRAME_EXTENTS in the wild, however the problem with it is that it's a proprietary atom, which is specific only to GTK apps. Due to that, _GTK_FRAME_EXTENTS wasn't implemented because implementing anything like that would require major changes in how we think about geometry. Recent xdg-shell window geometry patches adjusted geometry abstractions in kwin to such a degree that it's very easy to add support for client side decorated clients on X11. We just have to make sure that the X11Client class provides correct buffer geometry and frame geometry when the gtk frame extents are set. Even though the X11 code is feature frozen, I still think it's worth to have _GTK_FRAME_EXTENTS support in kwin because it will fix the resize issues. Also, because KWin/Wayland is unfortunately far from becoming default, it will help us with testing some implementation bits of the window geometry from xdg-shell. BUG: 390550 FIXED-IN: 5.18.0 Test Plan: Things like quick tiling, maximizing, tiling scripts and so on work as expected with GTK clients. Reviewers: #kwin, davidedmundson Reviewed By: #kwin, davidedmundson Subscribers: cblack, trmdi, kwin Tags: #kwin Differential Revision: https://phabricator.kde.org/D24660
2019-10-08 08:46:59 +00:00
return !m_clientFrameExtents.isNull();
Add a script to enforce window decorations for GTK windows This is going to be a controversal change. It enforces KWin decorations on all client side decorated windows from GTK+. Unfortunately we are caught between a rock and a hard place. Keeping the status quo means having broken windows and a more or less broken window manager due to GTK+ including the shadow in the windows. This is no solution. Enforcing server side decorations visually breaks the windows. This is also no solution. So why do it? It's our task to provide the best possible user experience and KWin is a window manager which has always done great efforts to fix misbehaving windows. One can think of the focus stealing prevention, the window rules and lately the scripts. The best possible window management experience is our aim. This means we cannot leave the users with the broken windows from GTK. The issues we noticed were reported to GTK+ about 2 months ago and we are working on improving the situation. Unfortunately several issues are not yet addressed and others will only be addressed in the next GTK+ release. We are working on improving the NETWM spec (see [1]) to ensure that the client side decorated windows are not in a broken state. This means the enforcment is a temporary solution and will be re-evaluated with the next GTK release. I would prefer to not have to do such a change, if some of the bugs were fixed or GTK+ would not use client-side-decos on wms not yet supporting those all of this would be a no issue. For a complete list of the problems caused by GTK's decos see bug [2] and the linked bug reports from there. The change is done in a least inversive way in KWin. We just check for the property _GTK_FRAME_EXTENTS and create a Q_PROPERTY in Client for it. If we add support for the frame extents in future we would also need this. So it's not a change just for enforcing the decoration. The actual enforcing is done through a KWin script so users can still disable it. REVIEW: 119062 [1] https://mail.gnome.org/archives/wm-spec-list/2014-June/msg00002.html [2] https://bugzilla.gnome.org/show_bug.cgi?id=729721
2014-07-01 13:44:02 +00:00
}
inline bool X11Client::groupTransient() const
2011-01-30 14:34:42 +00:00
{
return m_transientForId == rootWindow();
2011-01-30 14:34:42 +00:00
}
// Needed because verifyTransientFor() may set transient_for_id to root window,
// if the original value has a problem (window doesn't exist, etc.)
inline bool X11Client::wasOriginallyGroupTransient() const
2011-01-30 14:34:42 +00:00
{
return m_originalTransientForId == rootWindow();
2011-01-30 14:34:42 +00:00
}
inline bool X11Client::isTransient() const
2011-01-30 14:34:42 +00:00
{
return m_transientForId != XCB_WINDOW_NONE;
2011-01-30 14:34:42 +00:00
}
inline const Group* X11Client::group() const
2011-01-30 14:34:42 +00:00
{
return in_group;
2011-01-30 14:34:42 +00:00
}
inline Group* X11Client::group()
2011-01-30 14:34:42 +00:00
{
return in_group;
2011-01-30 14:34:42 +00:00
}
inline bool X11Client::isShown(bool shaded_is_shown) const
2011-01-30 14:34:42 +00:00
{
return !isMinimized() && (!isShade() || shaded_is_shown) && !hidden;
2011-01-30 14:34:42 +00:00
}
inline bool X11Client::isHiddenInternal() const
2011-01-30 14:34:42 +00:00
{
return hidden;
2011-01-30 14:34:42 +00:00
}
inline MaximizeMode X11Client::maximizeMode() const
2011-01-30 14:34:42 +00:00
{
return max_mode;
2011-01-30 14:34:42 +00:00
}
inline bool X11Client::isFullScreen() const
2011-01-30 14:34:42 +00:00
{
return m_fullscreenMode != FullScreenNone;
2011-01-30 14:34:42 +00:00
}
inline bool X11Client::hasNETSupport() const
2011-01-30 14:34:42 +00:00
{
return info->hasNETSupport();
2011-01-30 14:34:42 +00:00
}
inline xcb_colormap_t X11Client::colormap() const
2011-01-30 14:34:42 +00:00
{
return m_colormap;
2011-01-30 14:34:42 +00:00
}
inline int X11Client::sessionStackingOrder() const
2011-01-30 14:34:42 +00:00
{
return sm_stacking_order;
2011-01-30 14:34:42 +00:00
}
inline bool X11Client::isManaged() const
2011-01-30 14:34:42 +00:00
{
return m_managed;
2011-01-30 14:34:42 +00:00
}
inline void X11Client::plainResize(const QSize& s, ForceGeometry_t force)
2011-01-30 14:34:42 +00:00
{
plainResize(s.width(), s.height(), force);
2011-01-30 14:34:42 +00:00
}
inline void X11Client::resizeWithChecks(const QSize &s, AbstractClient::ForceGeometry_t force)
{
resizeWithChecks(s.width(), s.height(), XCB_GRAVITY_BIT_FORGET, force);
}
inline void X11Client::resizeWithChecks(const QSize& s, xcb_gravity_t gravity, ForceGeometry_t force)
2011-01-30 14:34:42 +00:00
{
resizeWithChecks(s.width(), s.height(), gravity, force);
2011-01-30 14:34:42 +00:00
}
inline bool X11Client::hasUserTimeSupport() const
2011-01-30 14:34:42 +00:00
{
return info->userTime() != -1U;
2011-01-30 14:34:42 +00:00
}
inline xcb_window_t X11Client::moveResizeGrabWindow() const
2011-01-30 14:34:42 +00:00
{
return m_moveResizeGrabWindow;
2011-01-30 14:34:42 +00:00
}
inline bool X11Client::hiddenPreview() const
2011-01-30 14:34:42 +00:00
{
return mapping_state == Kept;
2011-01-30 14:34:42 +00:00
}
template <typename T>
inline void X11Client::print(T &stream) const
{
stream << "\'Client:" << window() << ";WMCLASS:" << resourceClass() << ":"
<< resourceName() << ";Caption:" << caption() << "\'";
}
} // namespace
Q_DECLARE_METATYPE(KWin::X11Client *)
Q_DECLARE_METATYPE(QList<KWin::X11Client *>)