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

638 lines
20 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.
branches/work/kwin_composite becomes new trunk kwin. svn path=/trunk/KDE/kdebase/workspace/; revision=659202
2007-04-29 17:35:43 +00:00
Prettify license headers
2020-08-02 22:22:19 +00:00
SPDX-FileCopyrightText: 1999, 2000 Matthias Ettrich <ettrich@kde.org>
SPDX-FileCopyrightText: 2003 Lubos Lunak <l.lunak@kde.org>
branches/work/kwin_composite becomes new trunk kwin. svn path=/trunk/KDE/kdebase/workspace/; revision=659202
2007-04-29 17:35:43 +00:00
Prettify license headers
2020-08-02 22:22:19 +00:00
SPDX-License-Identifier: GPL-2.0-or-later
*/
branches/work/kwin_composite becomes new trunk kwin. svn path=/trunk/KDE/kdebase/workspace/; revision=659202
2007-04-29 17:35:43 +00:00
Rename Client to X11Client Summary: Currently each managed X11 client is represented with an instance of Client class, however the name of that class is very generic and the only reason why it's called that way is because historically kwin was created as an x11 window manager, so "Client" was a sensible choice. With introduction of wayland support, things had changed and therefore Client needs to be renamed to X11Client in order to better reflect what that class stands for. Renaming of Client to X11Client was agreed upon during the last KWin sprint. Test Plan: Compiles, the test suite is still green. Reviewers: #kwin, romangg Reviewed By: #kwin, romangg Subscribers: romangg, davidedmundson, kwin Tags: #kwin Differential Revision: https://phabricator.kde.org/D24184
2019-09-24 08:48:08 +00:00
#pragma once
branches/work/kwin_composite becomes new trunk kwin. svn path=/trunk/KDE/kdebase/workspace/; revision=659202
2007-04-29 17:35:43 +00:00
Cleanup and reorder includes in client.h Removing the workspace include required to include it in many other places.
2013-04-26 09:52:15 +00:00
// kwin
Move decoration renderer to decoration item Currently, the implementation of the DecoratedClient and the decoration renderer are strongly coupled. This poses a problem with the item based design as the ultimate goal is to have scene items construct paint nodes which are then fed to the renderer. The DecorationItem has to have control over the decoration texture. Another issue is that the scene cannot smoothly cross-fade between two window states if the decoration is removed, e.g. from fullscreen mode to normal and vice versa. This change moves the decoration renderer to the decoration item. With the introduction of a generic scene texture atlas, we hope to get rid of the decoration renderer altogether.
2021-04-26 16:38:40 +00:00
#include "decorationitem.h"
Introduce an AbstractClient base class for Client (and ShellClient) The idea for this base class is to provide access to all elements which make up a managed "Client" being it X11 or Wayland. They share a lot, like they have a caption, they can be minimized, etc. etc. Of course it would have also been possible to derive a new class from Client, but that looks like the more difficult task as Client is very X11 specific. So far only a very small interface is extracted with pure-virtual methods. This is going to change by moving the functionality up into the AbstractClient. The interface extracted so far is inspired by the usage of FocusChain and users of FocusChain.
2015-03-05 09:21:03 +00:00
#include "abstract_client.h"
Port Client's decoration resize extend input window to XCB Using Xcb::Window to manage the xcb_window_t and simplify the code - no longer need to check whether the input_window is valid before calling e.g. map, as that's handled in Xcb::Window. One XLib usage for setting cursor is still present. This will be ported once all the QCursor::handle() get removed. REVIEW: 108771
2013-02-04 10:20:15 +00:00
#include "xcbutils.h"
Cleanup and reorder includes in client.h Removing the workspace include required to include it in many other places.
2013-04-26 09:52:15 +00:00
// Qt
[kdecoration2] Detect double clicks on the decoration title bar No longer handled by the Decoration.
2014-11-28 13:50:21 +00:00
#include <QElapsedTimer>
Drop dependency on kdecoration.h
2014-12-02 12:50:26 +00:00
#include <QFlags>
#include <QPointer>
Cleanup and reorder includes in client.h Removing the workspace include required to include it in many other places.
2013-04-26 09:52:15 +00:00
#include <QPixmap>
[decorations] Add a KDecoration::window() returning the QWindow KWin core can access the QWindow of the decoration instead of the QWidget. This is a preparation step to allow QWidget based window decorations without any QWidgets at all. KWin core makes already use of this new accessor to get the window Id which is also on QWidgets provided through the QWindow.
2013-10-08 06:33:23 +00:00
#include <QWindow>
Cleanup and reorder includes in client.h Removing the workspace include required to include it in many other places.
2013-04-26 09:52:15 +00:00
// X
Port from XLib XSync to xcb sync
2013-07-31 08:11:39 +00:00
#include <xcb/sync.h>
Support for _NET_WM_SYNC_REQUEST, based on a patch by Rayiner Hashem <gtg990h@mail.gatech.edu>. svn path=/trunk/KDE/kdebase/workspace/; revision=679986
2007-06-25 08:51:44 +00:00
SVN_SILENT Standardize coding style on client.* and workspace.* svn path=/trunk/KDE/kdebase/workspace/; revision=898612
2008-12-18 13:50:57 +00:00
// TODO: Cleanup the order of things in this .h file
branches/work/kwin_composite becomes new trunk kwin. svn path=/trunk/KDE/kdebase/workspace/; revision=659202
2007-04-29 17:35:43 +00:00
class QTimer;
class KStartupInfoData;
Cleanup and reorder includes in client.h Removing the workspace include required to include it in many other places.
2013-04-26 09:52:15 +00:00
class KStartupInfoId;
branches/work/kwin_composite becomes new trunk kwin. svn path=/trunk/KDE/kdebase/workspace/; revision=659202
2007-04-29 17:35:43 +00:00
namespace KWin
{
Here comes the new TabBox. It is a complete rewrite using a MVC approach. Here some highlights: * Models and Delegates for Clients and Desktops * Horizontal, vertical and tabular layout * Layout of one item can be configured by an XML definition * A desktop item can include a client list * An optional second list view showing only the selected item * A new KCM "kwintabbox" * An alternative TabBox with independent settings and keybindings * Optional Highlight Windows effect integration * List scrolls instead of removing items * Scroll wheel support * Cursor key support * Middle click on item closes window BUG: 195745 BUG: 197187 BUG: 201103 FEATURE: 118184 FEATURE: 156723 FEATURE: 177441 FEATURE: 182897 FEATURE: 193882 GUI: svn path=/trunk/KDE/kdebase/workspace/; revision=1022861
2009-09-13 11:36:45 +00:00
[kwin] Use std::find_if and lambda functions for Workspace::findClient Instead of passing the macro based Predicate to findClient it now expects a function which can be passed to std::find_if. Existing code like: xcb_window_t window; // our test window Client *c = findClient(WindowMatchPredicated(window)); becomes: Client *c = findClient([window](const Client *c) { return c->window() == window; }); The advantage is that it is way more flexible and has the logic what to check for directly with the code and not hidden in the macro definition. In addition there is a simplified overload for the very common case of matching a window id against one of Client's windows. This overloaded method takes a Predicate and the window id. Above example becomes: Client *c = findClient(Predicate::WindowMatch, w); Existing code is migrated to use the simplified method taking MatchPredicate and window id. The very few cases where a more complex condition is tested the lambda function is used. As these are very local tests only used in one function it's not worthwhile to add further overloads to the findClient method in Workspace. With this change all the Predicate macro definitions are removed from utils.h as they are now completely unused. REVIEW: 116916
2014-03-20 08:19:53 +00:00
/**
* @brief Defines Predicates on how to search for a Client.
*
* Used by Workspace::findClient.
Use more traditional doxygen style Summary: So far we were following a bit unique and rare doxygen comment style: /** * Contents of the comment. **/ Doxygen comments with this style look balanced and neat, but many people that contribute to KWin don't follow this style. Instead, they prefer more traditional doxygen comment style, i.e. /** * Contents of the comment. */ Reviewing such changes has been a bit frustrating for me (so selfish!) and for other contributors. This change switches doxygen comment style in KWin to a more traditional style. The main reason for doing this is to make code review process easier for new contributors as well us. Reviewers: #kwin, davidedmundson Reviewed By: #kwin, davidedmundson Subscribers: kwin Tags: #kwin Differential Revision: https://phabricator.kde.org/D22812
2019-07-29 18:58:33 +00:00
*/
[kwin] Use std::find_if and lambda functions for Workspace::findClient Instead of passing the macro based Predicate to findClient it now expects a function which can be passed to std::find_if. Existing code like: xcb_window_t window; // our test window Client *c = findClient(WindowMatchPredicated(window)); becomes: Client *c = findClient([window](const Client *c) { return c->window() == window; }); The advantage is that it is way more flexible and has the logic what to check for directly with the code and not hidden in the macro definition. In addition there is a simplified overload for the very common case of matching a window id against one of Client's windows. This overloaded method takes a Predicate and the window id. Above example becomes: Client *c = findClient(Predicate::WindowMatch, w); Existing code is migrated to use the simplified method taking MatchPredicate and window id. The very few cases where a more complex condition is tested the lambda function is used. As these are very local tests only used in one function it's not worthwhile to add further overloads to the findClient method in Workspace. With this change all the Predicate macro definitions are removed from utils.h as they are now completely unused. REVIEW: 116916
2014-03-20 08:19:53 +00:00
enum class Predicate {
WindowMatch,
WrapperIdMatch,
FrameIdMatch,
GIT_SILENT Add trailing comma to enums
2021-03-14 17:06:22 +00:00
InputIdMatch,
[kwin] Use std::find_if and lambda functions for Workspace::findClient Instead of passing the macro based Predicate to findClient it now expects a function which can be passed to std::find_if. Existing code like: xcb_window_t window; // our test window Client *c = findClient(WindowMatchPredicated(window)); becomes: Client *c = findClient([window](const Client *c) { return c->window() == window; }); The advantage is that it is way more flexible and has the logic what to check for directly with the code and not hidden in the macro definition. In addition there is a simplified overload for the very common case of matching a window id against one of Client's windows. This overloaded method takes a Predicate and the window id. Above example becomes: Client *c = findClient(Predicate::WindowMatch, w); Existing code is migrated to use the simplified method taking MatchPredicate and window id. The very few cases where a more complex condition is tested the lambda function is used. As these are very local tests only used in one function it's not worthwhile to add further overloads to the findClient method in Workspace. With this change all the Predicate macro definitions are removed from utils.h as they are now completely unused. REVIEW: 116916
2014-03-20 08:19:53 +00:00
};
Move decoration renderer to decoration item Currently, the implementation of the DecoratedClient and the decoration renderer are strongly coupled. This poses a problem with the item based design as the ultimate goal is to have scene items construct paint nodes which are then fed to the renderer. The DecorationItem has to have control over the decoration texture. Another issue is that the scene cannot smoothly cross-fade between two window states if the decoration is removed, e.g. from fullscreen mode to normal and vice versa. This change moves the decoration renderer to the decoration item. With the introduction of a generic scene texture atlas, we hope to get rid of the decoration renderer altogether.
2021-04-26 16:38:40 +00:00
/**
* @todo Remove when the X11 platform support is dropped. This decoration renderer
* will be used if compositing is off.
*/
class X11DecorationRenderer : public DecorationRenderer
{
Q_OBJECT
public:
explicit X11DecorationRenderer(Decoration::DecoratedClientImpl *client);
~X11DecorationRenderer() override;
protected:
void render(const QRegion &region) override;
private:
void update();
QTimer *m_scheduleTimer;
xcb_gcontext_t m_gc;
};
Rename Client to X11Client Summary: Currently each managed X11 client is represented with an instance of Client class, however the name of that class is very generic and the only reason why it's called that way is because historically kwin was created as an x11 window manager, so "Client" was a sensible choice. With introduction of wayland support, things had changed and therefore Client needs to be renamed to X11Client in order to better reflect what that class stands for. Renaming of Client to X11Client was agreed upon during the last KWin sprint. Test Plan: Compiles, the test suite is still green. Reviewers: #kwin, romangg Reviewed By: #kwin, romangg Subscribers: romangg, davidedmundson, kwin Tags: #kwin Differential Revision: https://phabricator.kde.org/D24184
2019-09-24 08:48:08 +00:00
class KWIN_EXPORT X11Client : public AbstractClient
KWin uses kdelibs coding style.
2011-01-30 14:34:42 +00:00
{
branches/work/kwin_composite becomes new trunk kwin. svn path=/trunk/KDE/kdebase/workspace/; revision=659202
2007-04-29 17:35:43 +00:00
Q_OBJECT
More properties on Toplevel and Client Mostly exporting the getters used by EffectWindow as Properties. In client some have got a notify signal. REVIEW: 103510
2011-12-29 09:19:36 +00:00
/**
* 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.
Use more traditional doxygen style Summary: So far we were following a bit unique and rare doxygen comment style: /** * Contents of the comment. **/ Doxygen comments with this style look balanced and neat, but many people that contribute to KWin don't follow this style. Instead, they prefer more traditional doxygen comment style, i.e. /** * Contents of the comment. */ Reviewing such changes has been a bit frustrating for me (so selfish!) and for other contributors. This change switches doxygen comment style in KWin to a more traditional style. The main reason for doing this is to make code review process easier for new contributors as well us. Reviewers: #kwin, davidedmundson Reviewed By: #kwin, davidedmundson Subscribers: kwin Tags: #kwin Differential Revision: https://phabricator.kde.org/D22812
2019-07-29 18:58:33 +00:00
*/
More properties on Toplevel and Client Mostly exporting the getters used by EffectWindow as Properties. In client some have got a notify signal. REVIEW: 103510
2011-12-29 09:19:36 +00:00
Q_PROPERTY(QSize basicUnit READ basicUnit)
Export blocking compositing as a Client's Q_PROPERTY Allows to block compositing on Client's from scripts. Usecase: window rule cannot properly identify buggy clients and scripting allows to just act on fullscreen windows. BUG: 297146 FIXED-IN: 4.9.0 REVIEW: 104448
2012-03-31 17:09:00 +00:00
/**
* 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!
Use more traditional doxygen style Summary: So far we were following a bit unique and rare doxygen comment style: /** * Contents of the comment. **/ Doxygen comments with this style look balanced and neat, but many people that contribute to KWin don't follow this style. Instead, they prefer more traditional doxygen comment style, i.e. /** * Contents of the comment. */ Reviewing such changes has been a bit frustrating for me (so selfish!) and for other contributors. This change switches doxygen comment style in KWin to a more traditional style. The main reason for doing this is to make code review process easier for new contributors as well us. Reviewers: #kwin, davidedmundson Reviewed By: #kwin, davidedmundson Subscribers: kwin Tags: #kwin Differential Revision: https://phabricator.kde.org/D22812
2019-07-29 18:58:33 +00:00
*/
Export blocking compositing as a Client's Q_PROPERTY Allows to block compositing on Client's from scripts. Usecase: window rule cannot properly identify buggy clients and scripting allows to just act on fullscreen windows. BUG: 297146 FIXED-IN: 4.9.0 REVIEW: 104448
2012-03-31 17:09:00 +00:00
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.
Use more traditional doxygen style Summary: So far we were following a bit unique and rare doxygen comment style: /** * Contents of the comment. **/ Doxygen comments with this style look balanced and neat, but many people that contribute to KWin don't follow this style. Instead, they prefer more traditional doxygen comment style, i.e. /** * Contents of the comment. */ Reviewing such changes has been a bit frustrating for me (so selfish!) and for other contributors. This change switches doxygen comment style in KWin to a more traditional style. The main reason for doing this is to make code review process easier for new contributors as well us. Reviewers: #kwin, davidedmundson Reviewed By: #kwin, davidedmundson Subscribers: kwin Tags: #kwin Differential Revision: https://phabricator.kde.org/D22812
2019-07-29 18:58:33 +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
Q_PROPERTY(bool clientSideDecorated READ isClientSideDecorated NOTIFY clientSideDecoratedChanged)
KWin uses kdelibs coding style.
2011-01-30 14:34:42 +00:00
public:
Rename Client to X11Client Summary: Currently each managed X11 client is represented with an instance of Client class, however the name of that class is very generic and the only reason why it's called that way is because historically kwin was created as an x11 window manager, so "Client" was a sensible choice. With introduction of wayland support, things had changed and therefore Client needs to be renamed to X11Client in order to better reflect what that class stands for. Renaming of Client to X11Client was agreed upon during the last KWin sprint. Test Plan: Compiles, the test suite is still green. Reviewers: #kwin, romangg Reviewed By: #kwin, romangg Subscribers: romangg, davidedmundson, kwin Tags: #kwin Differential Revision: https://phabricator.kde.org/D24184
2019-09-24 08:48:08 +00:00
explicit X11Client();
[x11] Disable synchronized resizing for Xwayland < 1.21 In case Xwayland does not use multiple buffers, the currently attached buffer is going to be destroyed if the frame window is resized. It may render the previous and the current window pixmap invalid and thus result in visual artifacts when an X11 client is being interactively resized. In order to avoid the visual artifacts, this change disables support for synchronized resizing for X11 clients if the version of Xwayland is less than the version in which Xwayland started using multiple buffers, i.e. 1.21. Differential Revision: https://phabricator.kde.org/D29250
2020-04-27 18:44:12 +00:00
~X11Client() override; ///< Use destroyClient() or releaseWindow()
Use an Xcb::Window for Client::wrapper The Xcb::Window nicely encapsulates the created wrapper window. As almost all code is adjusted, the variable is also renamed to m_wrapper to follow the normal naming scheme.
2013-05-02 16:26:05 +00:00
xcb_window_t wrapperId() const;
Port Client's decoration resize extend input window to XCB Using Xcb::Window to manage the xcb_window_t and simplify the code - no longer need to check whether the input_window is valid before calling e.g. map, as that's handled in Xcb::Window. One XLib usage for setting cursor is still present. This will be ported once all the QCursor::handle() get removed. REVIEW: 108771
2013-02-04 10:20:15 +00:00
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;
KWin uses kdelibs coding style.
2011-01-30 14:34:42 +00:00
Provide input geometry and input transformation matrix for Xwayland clients Summary: We need to provide the input geometry and the input transformation matrix for Xwayland clients in order to make sure that input events are correctly mapped from the global screen coordinates to the screen-local coordinates. BUG: 417444 FIXED-IN: 5.18.1 Reviewers: #kwin Subscribers: kwin Tags: #kwin Differential Revision: https://phabricator.kde.org/D27375
2020-02-13 16:40:53 +00:00
QRect inputGeometry() const override;
[wayland] Implement window geometry more properly Summary: So far the window geometry from xdg-shell wasn't implemented as it should be. A toplevel must have two geometries assigned to it - frame and buffer. The frame geometry describes bounds of the client excluding server-side and client-side drop-shadows. The buffer geometry specifies rectangle on the screen occupied by the main surface. State and geometry handling in XdgShellClient is still a bit broken. This change doesn't intend to fix that, it must be done in another patch asap. Test Plan: New tests pass. Reviewers: #kwin, davidedmundson Reviewed By: #kwin, davidedmundson Subscribers: davidedmundson, romangg, kwin Tags: #kwin Maniphest Tasks: T10867 Differential Revision: https://phabricator.kde.org/D24455
2019-10-03 19:43:28 +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 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;
[x11] Fix visual artifacts during interactive resize Summary: When a window is being interactively resized, its contents may jump. The reason why that happens is because KWin renders partially resized client window. Composite extension spec says that a window will get a new pixmap each time it is resized or mapped. This applies to the frame window, but not to the client window itself. If the client window is resized, off-screen storage for the frame window won't be reallocated. Therefore, KWin may render partially resized client window if the client doesn't attempt to be in sync with our rendering loop. Currently, the only way to do that is to use extended frame counters, which are not supported by KWin. So, in order to fix visual artifacts during interactive resize, we need somehow forcefully re-allocate off-screen storage for the frame window. Unfortunately, Composite extension doesn't provide any request to do that, so the only option we have is to resize the frame window. BUG: 415839 FIXED-IN: 5.18.0 Reviewers: #kwin Subscribers: davidedmundson, ngraham, alexde, fredrik, kwin Tags: #kwin Differential Revision: https://phabricator.kde.org/D26914
2020-02-03 11:29:43 +00:00
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
Provide input geometry and input transformation matrix for Xwayland clients Summary: We need to provide the input geometry and the input transformation matrix for Xwayland clients in order to make sure that input events are correctly mapped from the global screen coordinates to the screen-local coordinates. BUG: 417444 FIXED-IN: 5.18.1 Reviewers: #kwin Subscribers: kwin Tags: #kwin Differential Revision: https://phabricator.kde.org/D27375
2020-02-13 16:40:53 +00:00
QMatrix4x4 inputTransformation() const override;
Use AbstractClient for raise/lowerClient Not a 100 % port. Transient handling is still bound to Client and does a static cast back to Client.
2015-03-05 12:35:54 +00:00
bool isTransient() const override;
Move groupTransient and group from Client to AbstractClient as virtual Summary: The default implementations just return false/nullptr. The advantage of having this in AbstractClient is that we can reduce the needed casts from AbstractClient to Client in core as can be seen in this change. There are more cases which can be improved thanks to this refactoring which will follow in dedicated commits. Test Plan: ctest passes Reviewers: #kwin Subscribers: kwin Tags: #kwin Differential Revision: https://phabricator.kde.org/D17890
2018-12-31 17:57:13 +00:00
bool groupTransient() const override;
KWin uses kdelibs coding style.
2011-01-30 14:34:42 +00:00
bool wasOriginallyGroupTransient() const;
Move mainClients() and allMainClients from Client to AbstractClient AbstractClient::mainClients is virtual and overriden in Client, allMainClients has only a common implementation in AbstractClient. In activation.cpp we still need one case where a temporary ClientList needs to be constructed. Once transients are fully migrated that should be removable again.
2015-09-11 13:55:23 +00:00
QList<AbstractClient*> mainClients() const override; // Call once before loop , is not indirect
Move hasTransient from Client to AbstractClient
2015-09-11 12:14:21 +00:00
bool hasTransient(const AbstractClient* c, bool indirect) const override;
Port Client::transient_for handling to XCB The type of the transient_for related variables are changed to xcb_window_t. They cannot be Xcb::Window as we don't take ownership over the transient for window. Variables are renamed to m_camelCase to follow naming scheme. A wrapper for retrieving the TransientFor hint is added to the Xcb Wrappers.
2013-05-03 06:53:35 +00:00
void checkTransient(xcb_window_t w);
TabBoxClientImpl changed to using an AbstractClient The change is mostly straight forward. Effects are straight forward adjusted. Client::findModal is moved up, this causes still a few dynamic_casts to Client. Mostly because Workspace::activateClient still operates on Client.
2015-03-05 12:59:18 +00:00
AbstractClient* findModal(bool allow_itself = false) override;
Move groupTransient and group from Client to AbstractClient as virtual Summary: The default implementations just return false/nullptr. The advantage of having this in AbstractClient is that we can reduce the needed casts from AbstractClient to Client in core as can be seen in this change. There are more cases which can be improved thanks to this refactoring which will follow in dedicated commits. Test Plan: ctest passes Reviewers: #kwin Subscribers: kwin Tags: #kwin Differential Revision: https://phabricator.kde.org/D17890
2018-12-31 17:57:13 +00:00
const Group* group() const override;
Group* group() override;
Use nullptr everywhere Summary: Because KWin is a very old project, we use three kinds of null pointer literals: 0, NULL, and nullptr. Since C++11, it's recommended to use nullptr keyword. This change converts all usages of 0 and NULL literal to nullptr. Even though it breaks git history, we need to do it in order to have consistent code as well to ease code reviews (it's very tempting for some people to add unrelated changes to their patches, e.g. converting NULL to nullptr). Test Plan: Compiles. Reviewers: #kwin, davidedmundson, romangg Reviewed By: #kwin, davidedmundson, romangg Subscribers: romangg, kwin Tags: #kwin Differential Revision: https://phabricator.kde.org/D23618
2019-09-19 14:46:54 +00:00
void checkGroup(Group* gr = nullptr, bool force = false);
KWin uses kdelibs coding style.
2011-01-30 14:34:42 +00:00
void changeClientLeaderGroup(Group* gr);
Explicitly indicate support for window rules This way it's more difficult to overlook the case where a new client type unexpectedly advertises that it supports window rules.
2020-08-20 11:31:48 +00:00
bool supportsWindowRules() const override;
Implement AbstractClient::skipSwitcher Moves implementation from Client to AbstractClient.
2015-03-12 14:35:36 +00:00
void updateWindowRules(Rules::Types selection) override;
[x11] Apply "Block compositing" rule right away Summary: When the user changes "Block compositing" rule, apply it immediately. BUG: 415903 Reviewers: #kwin, davidedmundson Reviewed By: #kwin, davidedmundson Subscribers: kwin Tags: #kwin Differential Revision: https://phabricator.kde.org/D26708
2020-01-16 13:58:49 +00:00
void applyWindowRules() override;
KWin uses kdelibs coding style.
2011-01-30 14:34:42 +00:00
void updateFullscreenMonitors(NETFullscreenMonitors topology);
bool hasNETSupport() const;
Move maxSize and minSize to AbstractClient With a default implementation returning either a INT_MAX size or 0.
2015-05-27 11:21:56 +00:00
QSize minSize() const override;
QSize maxSize() const override;
export the baseincrement size to the effectwindow and utilize it in the windowgeometry effect BUG: 283518 REVIEW: 103033 FIXED-IN: 4.8
2011-11-02 22:05:03 +00:00
QSize basicUnit() const;
kwin: Insert an input-only window above each decorated client This input-only window is used to capture events above the client window and preventing them from reaching the client. It is currently used to enlarge the borders by an invisible amount, using the ExtendedBorderRegion provided by the decoration.
2011-11-09 19:39:13 +00:00
QPoint inputPos() const { return input_offset; } // Inside of geometry()
KWin uses kdelibs coding style.
2011-01-30 14:34:42 +00:00
Enable the event filtering for the movingClient This requires to have the Client::windowEvent() take an xcb_generic_event_t* instead of XEvent*. Currently functionality is ifdefed.
2013-07-26 08:32:48 +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;
branches/work/kwin_composite becomes new trunk kwin. svn path=/trunk/KDE/kdebase/workspace/; revision=659202
2007-04-29 17:35:43 +00:00
Client::manager() takes an xcb_window_t as argument
2013-05-03 08:20:05 +00:00
bool manage(xcb_window_t w, bool isMapped);
KWin uses kdelibs coding style.
2011-01-30 14:34:42 +00:00
void releaseWindow(bool on_shutdown = false);
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;
KWin uses kdelibs coding style.
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;
Move basic activities support from X11Client to AbstractClient We're now sharing most of the X11Client activity behavior accross all clients. This allows to cleanup some of the existing virtuals and remove quite a bit of code overalls. Has to introduce an extra platform specific hook since X11Client serializes the activity information in an atom and we will probably need to do something similar on the Wayland platform at some point. This allows us to start interacting with the activities with kwin wayland. They are not restored properly accross sessions though since nothing is really persisted and the session management still seems to be amiss.
2021-03-09 14:04:20 +00:00
void doSetOnActivities(const QStringList &newActivitiesList) override;
void updateActivities(bool includeTransients) override;
KWin uses kdelibs coding style.
2011-01-30 14:34:42 +00:00
/// Is not minimized and not hidden. I.e. normally visible on some virtual desktop.
Remove boolean trap in AbstractClient::isShown() Check shaded state where needed.
2021-11-23 12:13:56 +00:00
bool isShown() const override;
Use hiddenInternal() for a ShellClient which got unmapped Summary: So far when a ShellClient got unmapped ready_for_painting was set to false. That is the ShellClient was treated in the same way as a not yet shown window. It was completely excluded from painting, a close animation impossible. This change makes use of the functionality available in Client::hiddenInternal(). The window is considered as hidden, thus still excluded from e.g. getting input events, but could be rendered any time as we still have a previous window pixmap (if referenced). This allows to have it considered in the rendering pass, but effects still cannot make use of it as that state is not yet exposed to the effects. Reviewers: #kwin, #plasma_on_wayland Subscribers: plasma-devel, kwin Tags: #plasma_on_wayland, #kwin Differential Revision: https://phabricator.kde.org/D2083
2016-07-04 13:06:20 +00:00
bool isHiddenInternal() const override; // For compositing
KWin uses kdelibs coding style.
2011-01-30 14:34:42 +00:00
UserActionsMenu operates on AbstractClient There are still a few areas where it's dynamic casting to Client, e.g.: * sendToDesktop * window tabbing related * activities related
2015-03-06 10:33:51 +00:00
bool isShadeable() const override;
bool isMaximizable() const override;
Workspace::performWindowOperation operates on AbstractClient Only exception is the call to ::takeActivity which still expects a Client.
2015-03-06 09:05:40 +00:00
MaximizeMode maximizeMode() const override;
Move QuickTileMode from KDecorationDefines to Client
2014-12-02 09:52:16 +00:00
UserActionsMenu operates on AbstractClient There are still a few areas where it's dynamic casting to Client, e.g.: * sendToDesktop * window tabbing related * activities related
2015-03-06 10:33:51 +00:00
bool isMinimizable() const override;
preliminar support for task geometries in wayland make the minimize effect work by reading taskGeometry from plasmawindowmanagement and returning as iconGeometry() there is one task geometry per panel window, iconGeometry() will return the geometry associated to the nearest panel from the window REVIEW:125873
2015-11-05 10:30:02 +00:00
QRect iconGeometry() const override;
KWin uses kdelibs coding style.
2011-01-30 14:34:42 +00:00
Split up fullscreen able check into AbstractClient subclasses Summary: Most parts of this function are only relevant for X clients, in particular the "fullscreen hack". Therefore split up the function into the AbstractClient subclasses. Test Plan: Manually and autotests still pass. Reviewers: #kwin, zzag Reviewed By: #kwin, zzag Subscribers: graesslin, zzag, kwin Tags: #kwin Maniphest Tasks: T11098 Differential Revision: https://phabricator.kde.org/D18128
2019-01-09 14:20:19 +00:00
bool isFullScreenable() const override;
Workspace::performWindowOperation operates on AbstractClient Only exception is the call to ::takeActivity which still expects a Client.
2015-03-06 09:05:40 +00:00
void setFullScreen(bool set, bool user = true) override;
Introduce an AbstractClient base class for Client (and ShellClient) The idea for this base class is to provide access to all elements which make up a managed "Client" being it X11 or Wayland. They share a lot, like they have a caption, they can be minimized, etc. etc. Of course it would have also been possible to derive a new class from Client, but that looks like the more difficult task as Client is very X11 specific. So far only a very small interface is extracted with pure-virtual methods. This is going to change by moving the functionality up into the AbstractClient. The interface extracted so far is inspired by the usage of FocusChain and users of FocusChain.
2015-03-05 09:21:03 +00:00
bool isFullScreen() const override;
UserActionsMenu operates on AbstractClient There are still a few areas where it's dynamic casting to Client, e.g.: * sendToDesktop * window tabbing related * activities related
2015-03-06 10:33:51 +00:00
bool userCanSetFullScreen() const override;
KWin uses kdelibs coding style.
2011-01-30 14:34:42 +00:00
int fullScreenMode() const {
Correct code style of Client fullscreen control Summary: As a preperational step for future changes obey the code styling guide in Client fullscreen functionality. No functional changes. Test Plan: Manually, autotests pass. Reviewers: #kwin, davidedmundson Reviewed By: #kwin, davidedmundson Subscribers: zzag, graesslin, kwin Tags: #kwin Maniphest Tasks: T11098 Differential Revision: https://phabricator.kde.org/D18153
2019-01-10 12:16:01 +00:00
return m_fullscreenMode; // only for session saving
KWin uses kdelibs coding style.
2011-01-30 14:34:42 +00:00
}
Save the correct value of noborder property Summary: We can't use Client::noBorder while saving the desktop session because the returned value is not necessarily set by the user. BUG: 403948 Reviewers: #kwin, davidedmundson Reviewed By: #kwin, davidedmundson Subscribers: kwin Tags: #kwin Differential Revision: https://phabricator.kde.org/D18756
2019-02-05 11:10:40 +00:00
bool userNoBorder() const;
Workspace::performWindowOperation operates on AbstractClient Only exception is the call to ::takeActivity which still expects a Client.
2015-03-06 09:05:40 +00:00
bool noBorder() const override;
void setNoBorder(bool set) override;
UserActionsMenu operates on AbstractClient There are still a few areas where it's dynamic casting to Client, e.g.: * sendToDesktop * window tabbing related * activities related
2015-03-06 10:33:51 +00:00
bool userCanSetNoBorder() const override;
Support updating deco for changes of borderless maximize windows config Summary: So far only updated the Clients, now also ShellClient. Reviewers: #kwin, #plasma Subscribers: plasma-devel, kwin Tags: #kwin Differential Revision: https://phabricator.kde.org/D8095
2017-10-01 19:48:57 +00:00
void checkNoBorder() override;
KWin uses kdelibs coding style.
2011-01-30 14:34:42 +00:00
int sessionStackingOrder() const;
// Auxiliary functions, depend on the windowType
Workspace::takeActivity operates on AbstractClient
2015-03-06 14:04:59 +00:00
bool wantsInput() const override;
KWin uses kdelibs coding style.
2011-01-30 14:34:42 +00:00
UserActionsMenu operates on AbstractClient There are still a few areas where it's dynamic casting to Client, e.g.: * sendToDesktop * window tabbing related * activities related
2015-03-06 10:33:51 +00:00
bool isResizable() const override;
bool isMovable() const override;
bool isMovableAcrossScreens() const override;
Introduce an AbstractClient base class for Client (and ShellClient) The idea for this base class is to provide access to all elements which make up a managed "Client" being it X11 or Wayland. They share a lot, like they have a caption, they can be minimized, etc. etc. Of course it would have also been possible to derive a new class from Client, but that looks like the more difficult task as Client is very X11 specific. So far only a very small interface is extracted with pure-virtual methods. This is going to change by moving the functionality up into the AbstractClient. The interface extracted so far is inspired by the usage of FocusChain and users of FocusChain.
2015-03-05 09:21:03 +00:00
bool isCloseable() const override; ///< May be closed by the user (May have a close button)
KWin uses kdelibs coding style.
2011-01-30 14:34:42 +00:00
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;
KWin uses kdelibs coding style.
2011-01-30 14:34:42 +00:00
Invalidate decoration explicitly Lets us to remove AbstractClient::updateDecoration().
2021-12-08 13:21:48 +00:00
void invalidateDecoration() override;
KWin uses kdelibs coding style.
2011-01-30 14:34:42 +00:00
void updateShape();
/// resizeWithChecks() resizes according to gravity, and checks workarea position
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;
void resizeWithChecks(int w, int h, xcb_gravity_t gravity);
void resizeWithChecks(const QSize& s, xcb_gravity_t gravity);
Refactor geometry constraints code Summary: Currently, there are a couple of issues with sizeForClientSize(). First of all, we have a method called clientSizeToFrameSize() which does similar thing except applying geometry constraints and checking window rules. The other issue is that sizeForClientSize() is doing a bit too much, it checks window rules, it applies a bunch of geometry constrains. Sometimes it does not perform conversion between client sizes and frame sizes! This change attempts to address those issues by replacing sizeForClientSize with two similar methods and changing semantics of some methods of the X11Client class. The most significant difference between sizeForClientSize() and the new methods is that neither constrainClientSize() nor constrainFrameSize() check window rules. This is up to users of those methods. In many places, we don't have to check window rules because we check isResizable(), which returns false if the frame size is enforced by a window rule. Reviewers: #kwin, davidedmundson Reviewed By: #kwin, davidedmundson Subscribers: davidedmundson, romangg, kwin Tags: #kwin Differential Revision: https://phabricator.kde.org/D26828
2020-02-12 10:38:40 +00:00
QSize constrainClientSize(const QSize &size, SizeMode mode = SizeModeAny) const override;
KWin uses kdelibs coding style.
2011-01-30 14:34:42 +00:00
Add virtual AbstractClient::showContextHelp and ::providesContextHelp Required in the context of decorations. Default implementation does nothing respectively returns false.
2015-12-03 16:11:14 +00:00
bool providesContextHelp() const override;
KWin uses kdelibs coding style.
2011-01-30 14:34:42 +00:00
Change Client's clormap to xcb_colormap_t At same time also renaming variable to follow naming scheme and have a sensible name. Also moved default value initialization into initializer list. REVIEW: 110283
2013-05-03 09:46:18 +00:00
xcb_colormap_t colormap() const;
KWin uses kdelibs coding style.
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
AbstractClient: split up hideClient into hide and show This makes the purpose of the method call more clear
2021-11-03 09:40:31 +00:00
void hideClient() override;
void showClient() override;
KWin uses kdelibs coding style.
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;
Try to wait for DESTROY_NOTIFY before releasing an Unmanaged So far the Unmanaged got released after an XCB_UNMAP_NOTIFY. This event gets created after xcb_unmap_window or after xcb_destroy_window. In the latter case the window is already distroyed and any of KWin's cleanup calls will cause a BadWindow (or similar) error. The idea to circumvent these errors is to try to wait for the DESTROY_NOTIFY event. To do so the processing of the release is slightly delayed. If KWin gets the destroy notify before the delay times out the Unamanged gets released immediately but with a Destroy flag. For this a new enum ReleaseToplevel is introduced and Unmanage::release takes this as an argument instead of the bool which indicated OnShutdown. Also this enum is added to Toplevel::finishCompositing so that it can ignore the destroyed case and not generate an error. REVIEW: 117422
2014-04-07 14:23:17 +00:00
void finishCompositing(ReleaseReason releaseReason = ReleaseReason::Release) override;
Export blocking compositing as a Client's Q_PROPERTY Allows to block compositing on Client's from scripts. Usecase: window rule cannot properly identify buggy clients and scripting allows to just act on fullscreen windows. BUG: 297146 FIXED-IN: 4.9.0 REVIEW: 104448
2012-03-31 17:09:00 +00:00
void setBlockingCompositing(bool block);
add rule/property based composite blocking
2011-03-20 14:42:05 +00:00
inline bool isBlockingCompositing() { return blocks_compositing; }
KWin uses kdelibs coding style.
2011-01-30 14:34:42 +00:00
Add <number> to Wayland captions if the caption is the same Summary: Bringing another caption feature from X11 to Wayland. If we have multiple windows with the same caption, starting from the second window a suffix <number> is added. E.g. if we have three windows with caption "foo", the naming is: * foo * foo <2> * foo <3> The change tries to use as much shared code between the X11 and Wayland implementation. Unfortunately it's not possible to share completely as the X11 implementation does X11 specific things like editing the visible name. By sharing the code the numbering also works cross windowing system. That is if a window is called "foo" on X11, a new window on Wayland with caption "foo" will get adjusted to "foo <2>" and vice versa. The change also eliminates a duplicated signal for captionChanged in ShellClient (found by test case). By using the shared implementation on X11 side a bug gets fixed which got introduced with the support of "unresponsive", this is no longer considered and the numbering still works even if there is a window which is unresponsive. Test Plan: New test case and manual testing Reviewers: #kwin, #plasma Subscribers: plasma-devel, kwin Tags: #kwin Differential Revision: https://phabricator.kde.org/D7425
2017-08-20 06:56:13 +00:00
QString captionNormal() const override {
return cap_normal;
}
QString captionSuffix() const override {
return cap_suffix;
}
KWin uses kdelibs coding style.
2011-01-30 14:34:42 +00:00
Move keyPressEvent(uint) to AbstractClient The variant with additional timestamp is still in Client.
2015-10-23 13:32:10 +00:00
using AbstractClient::keyPressEvent;
void keyPressEvent(uint key_code, xcb_timestamp_t time); // FRAME ??
Introduce an AbstractClient base class for Client (and ShellClient) The idea for this base class is to provide access to all elements which make up a managed "Client" being it X11 or Wayland. They share a lot, like they have a caption, they can be minimized, etc. etc. Of course it would have also been possible to derive a new class from Client, but that looks like the more difficult task as Client is very X11 specific. So far only a very small interface is extracted with pure-virtual methods. This is going to change by moving the functionality up into the AbstractClient. The interface extracted so far is inspired by the usage of FocusChain and users of FocusChain.
2015-03-05 09:21:03 +00:00
void updateMouseGrab() override;
Port Client's move resize grab window to XCB Using Xcb::Window to wrap this helper window and port all the used XLib calls to XCB. Also renaming the variable to m_ and camel case to follow general naming scheme.
2013-05-02 17:04:43 +00:00
xcb_window_t moveResizeGrabWindow() const;
KWin uses kdelibs coding style.
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;
KWin uses kdelibs coding style.
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);
Client::restackWindow() accepts xcb_(window|timestamp)_t as argument At the same time X define usage is changed to XCB enums.
2013-05-03 08:27:04 +00:00
void restackWindow(xcb_window_t above, int detail, NET::RequestSource source, xcb_timestamp_t timestamp,
KWin uses kdelibs coding style.
2011-01-30 14:34:42 +00:00
bool send_event = false);
Use xcb_timestamp_t for ping window functionality At same time rename the variable to follow m_camelCase naming scheme and initialise the variable with default value in ctor.
2013-05-03 09:35:46 +00:00
void gotPing(xcb_timestamp_t timestamp);
KWin uses kdelibs coding style.
2011-01-30 14:34:42 +00:00
Client's userTime related code ported over to XCB At same time variable user_time renamed to m_userTime to follow naming scheme.
2013-05-03 09:29:50 +00:00
void updateUserTime(xcb_timestamp_t time = XCB_TIME_CURRENT_TIME);
Move ::userTime to AbstractClient Default implementation returns 0.
2015-03-12 10:24:27 +00:00
xcb_timestamp_t userTime() const override;
KWin uses kdelibs coding style.
2011-01-30 14:34:42 +00:00
bool hasUserTimeSupport() const;
/// Does 'delete c;'
Rename Client to X11Client Summary: Currently each managed X11 client is represented with an instance of Client class, however the name of that class is very generic and the only reason why it's called that way is because historically kwin was created as an x11 window manager, so "Client" was a sensible choice. With introduction of wayland support, things had changed and therefore Client needs to be renamed to X11Client in order to better reflect what that class stands for. Renaming of Client to X11Client was agreed upon during the last KWin sprint. Test Plan: Compiles, the test suite is still green. Reviewers: #kwin, romangg Reviewed By: #kwin, romangg Subscribers: romangg, davidedmundson, kwin Tags: #kwin Differential Revision: https://phabricator.kde.org/D24184
2019-09-24 08:48:08 +00:00
static void deleteClient(X11Client *c);
KWin uses kdelibs coding style.
2011-01-30 14:34:42 +00:00
Rename Client to X11Client Summary: Currently each managed X11 client is represented with an instance of Client class, however the name of that class is very generic and the only reason why it's called that way is because historically kwin was created as an x11 window manager, so "Client" was a sensible choice. With introduction of wayland support, things had changed and therefore Client needs to be renamed to X11Client in order to better reflect what that class stands for. Renaming of Client to X11Client was agreed upon during the last KWin sprint. Test Plan: Compiles, the test suite is still green. Reviewers: #kwin, romangg Reviewed By: #kwin, romangg Subscribers: romangg, davidedmundson, kwin Tags: #kwin Differential Revision: https://phabricator.kde.org/D24184
2019-09-24 08:48:08 +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);
KWin uses kdelibs coding style.
2011-01-30 14:34:42 +00:00
KillWindow support for Wayland windows Summary: AbstractClient gains a new pure virtual killWindow method and this gets implemented in ShellClient. ShellClient performs the killing by sending a term signal to the process. This can only work if the client connected through the socket and didn't get a socketpair fd passed. In that case the pid is KWin's and KWin doesn't want to terminate. Thus this is special handled to destroy the connection instead. In case terminating the process has no effect, the connection gets destroyed after five seconds. The KillWindow is adjusted to operate on AbstractClient instead of Client. This implements T4463. Test Plan: Killed windows and auto test Reviewers: #kwin, #plasma_on_wayland Subscribers: plasma-devel, kwin Tags: #plasma_on_wayland, #kwin Differential Revision: https://phabricator.kde.org/D3370
2016-11-15 15:48:20 +00:00
void killWindow() override;
Add virtual AbstractClient::showContextHelp and ::providesContextHelp Required in the context of decorations. Default implementation does nothing respectively returns false.
2015-12-03 16:11:14 +00:00
void showContextHelp() override;
KWin uses kdelibs coding style.
2011-01-30 14:34:42 +00:00
void checkActiveModal();
Move struts logic to AbstractClient
2020-08-17 13:14:20 +00:00
StrutRect strutRect(StrutArea area) const override;
Move hasStrut from Client to AbstractClient Base implementation returns false.
2015-06-19 22:14:15 +00:00
bool hasStrut() const override;
KWin uses kdelibs coding style.
2011-01-30 14:34:42 +00:00
Overhaul doxygen comments Summary: We have a mix of different doxygen comment styles, e.g. /*! Foo bar. */ /** * Foo bar. */ /** Foo bar. */ /** * Foo bar. */ /** * Foo bar. **/ To make the code more consistent, this change updates the style of all doxygen comments to the last one. Test Plan: Compiles. Reviewers: #kwin, davidedmundson Reviewed By: #kwin, davidedmundson Subscribers: kwin Tags: #kwin Differential Revision: https://phabricator.kde.org/D18683
2019-02-02 18:17:44 +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.
Use more traditional doxygen style Summary: So far we were following a bit unique and rare doxygen comment style: /** * Contents of the comment. **/ Doxygen comments with this style look balanced and neat, but many people that contribute to KWin don't follow this style. Instead, they prefer more traditional doxygen comment style, i.e. /** * Contents of the comment. */ Reviewing such changes has been a bit frustrating for me (so selfish!) and for other contributors. This change switches doxygen comment style in KWin to a more traditional style. The main reason for doing this is to make code review process easier for new contributors as well us. Reviewers: #kwin, davidedmundson Reviewed By: #kwin, davidedmundson Subscribers: kwin Tags: #kwin Differential Revision: https://phabricator.kde.org/D22812
2019-07-29 18:58:33 +00:00
*/
Port TabGroup from Client to AbstractClient First step towards a return of window tabbing.
2018-05-05 10:06:24 +00:00
void setClientShown(bool shown) override;
KWin uses kdelibs coding style.
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;
Decoration can announce whether it currently requires an alpha channel A decoration can provide the AbilityAnnounceAlphaChannel in addition to AbilityUsesAlphaChannel. If this ability is provided the decoration can enable/disable the use of the alpha channel through setAlphaEnabled(). The base idea behind this mechanism is to be able to tell the compositor that currently alpha is not needed. An example is the maximized state in which the decoration is fully opaque so that there is no need to use the translucency code path which would render all windows behind the deco. In addition also the blur effect honors this setting so that behind a known opaque decoration no blurring is performed. Oxygen is adjusted to disable translucency in maximized state and Aurorae is adjusted to allow themes to enable/disable translucency. For Plastik translucency and with that also blurring is disabled. REVIEW: 106810
2012-10-12 09:34:05 +00:00
Split Client::updateFirstInTabBox into two parts
2015-01-15 15:14:28 +00:00
Xcb::Property fetchFirstInTabBox() const;
void readFirstInTabBox(Xcb::Property &property);
Support for sticky items in TabBox list This is needed for Plasma Active's home screen which should always be the first element in the list.
2011-12-01 12:15:11 +00:00
void updateFirstInTabBox();
Refactor color scheme related code Currently, we have two functions that update the color scheme for a client - updateColorScheme(QString) and updateColorScheme(). Even though they both share the same name, they do different things. The first one sets the specified color scheme, while the other determines the color scheme preferred by the client and assigns it. This change refactors the color scheme initialization code so we no longer need those two methods. The setColorScheme() method sets the specified color scheme, and the preferredColorScheme() method returns the color scheme preferred by the client. Sub-classes of AbstractClient can override the preferredColorScheme() method in order to add support for platform-specific color scheme protocols. The end result: color scheme related code is a bit more comprehensible.
2020-08-19 09:21:00 +00:00
Xcb::StringProperty fetchPreferredColorScheme() const;
QString readPreferredColorScheme(Xcb::StringProperty &property) const;
QString preferredColorScheme() const override;
KWin uses kdelibs coding style.
2011-01-30 14:34:42 +00:00
fix showing of window on inactive activities during session save This is what 7ce380497f tried to do (and got reverted by my previous commit). The approach is basically the same, just temporarily fake that the window is on all activities, thus it will be temporarily shown for the session interact, but this time there seem to be no broken side-effects (and if there are, they'll be at least limited to activities and not break virtual desktops). Also, 'needsSessionInteract' was a misnomer - it certainly wasn't set for all windows that needed session interaction. Just call it what it really is. Differential Revision: https://phabricator.kde.org/D5614
2017-04-27 10:18:41 +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;
KWin uses kdelibs coding style.
2011-01-30 14:34:42 +00:00
Replacement for XEvent queue inspection in FocusOut event case Instead of inspecting the XEvent queue we create a Timer with a singleshot of 0 msec to move the setActive(false) call to the end of the event handling. In case there is a matching FocusIn event this will be handled before the timer fired and can cancel the timer.
2013-08-05 07:48:14 +00:00
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.
Use more traditional doxygen style Summary: So far we were following a bit unique and rare doxygen comment style: /** * Contents of the comment. **/ Doxygen comments with this style look balanced and neat, but many people that contribute to KWin don't follow this style. Instead, they prefer more traditional doxygen comment style, i.e. /** * Contents of the comment. */ Reviewing such changes has been a bit frustrating for me (so selfish!) and for other contributors. This change switches doxygen comment style in KWin to a more traditional style. The main reason for doing this is to make code review process easier for new contributors as well us. Reviewers: #kwin, davidedmundson Reviewed By: #kwin, davidedmundson Subscribers: kwin Tags: #kwin Differential Revision: https://phabricator.kde.org/D22812
2019-07-29 18:58:33 +00:00
*/
Implement show on screen edge for Wayland Summary: This change ports ScreenEdges to operate on AbstractClient instead of Client. For this AbstractClient gained a new pure virtual method showOnScreenEdge which is also implemented in ShellClient. In ShellClient the functionality is bound for the case windows can cover a panel. If triggered the panel gets raised again. The auto hiding panel, though, is not yet implemented. For that the protocol needs to be adjusted to give a hint to the compositor when to hide and hint back to the panel when it was shown. This needs a change in KWayland and thus is not 5.8 material. Test Plan: See added test case Reviewers: #kwin, #plasma_on_wayland Subscribers: plasma-devel, kwin Tags: #plasma_on_wayland, #kwin Differential Revision: https://phabricator.kde.org/D2793
2016-09-15 19:03:40 +00:00
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
Restore global menu support This brings back global menu support in KWin. The DBusMenu infrastructure is different that we just read the DBus service name and menu object path from the windows rather than passing around window IDs on DBus which won't work on Wayland. Differential Revision: https://phabricator.kde.org/D3089
2017-01-11 09:21:03 +00:00
Xcb::StringProperty fetchApplicationMenuServiceName() const;
void readApplicationMenuServiceName(Xcb::StringProperty &property);
void checkApplicationMenuServiceName();
Xcb::StringProperty fetchApplicationMenuObjectPath() const;
void readApplicationMenuObjectPath(Xcb::StringProperty &property);
void checkApplicationMenuObjectPath();
Create a dedicated X11Filter for Client sync events and move it to X11 platform Summary: On Wayland we have the sync disabled as it doesn't work properly. This allows us to also move the sync event handling into the X11 standalone platform. The code is slightly refactored: instead of passing the event to each Client, we search for the matching Client. For that the SyncAlaram struct is added to public section of Client. The method to handle the sync doesn't need the event any more and is moved from events.cpp to client.cpp. Test Plan: Run Xephyr+kwin_x11, resized a window and verified through gdb breakpoint that the sync still works Reviewers: #kwin, #plasma Subscribers: plasma-devel Tags: #plasma Differential Revision: https://phabricator.kde.org/D7942
2017-09-22 18:35:50 +00:00
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;
};
Rename X11Client::getSyncRequest() to X11Client::syncRequest() Getter methods should not have "get" prefix.
2020-01-28 19:46:09 +00:00
const SyncRequest &syncRequest() const {
return m_syncRequest;
Create a dedicated X11Filter for Client sync events and move it to X11 platform Summary: On Wayland we have the sync disabled as it doesn't work properly. This allows us to also move the sync event handling into the X11 standalone platform. The code is slightly refactored: instead of passing the event to each Client, we search for the matching Client. For that the SyncAlaram struct is added to public section of Client. The method to handle the sync doesn't need the event any more and is moved from events.cpp to client.cpp. Test Plan: Run Xephyr+kwin_x11, resized a window and verified through gdb breakpoint that the sync still works Reviewers: #kwin, #plasma Subscribers: plasma-devel Tags: #plasma Differential Revision: https://phabricator.kde.org/D7942
2017-09-22 18:35:50 +00:00
}
[x11] Disable synchronized resizing for Xwayland < 1.21 In case Xwayland does not use multiple buffers, the currently attached buffer is going to be destroyed if the frame window is resized. It may render the previous and the current window pixmap invalid and thus result in visual artifacts when an X11 client is being interactively resized. In order to avoid the visual artifacts, this change disables support for synchronized resizing for X11 clients if the version of Xwayland is less than the version in which Xwayland started using multiple buffers, i.e. 1.21. Differential Revision: https://phabricator.kde.org/D29250
2020-04-27 18:44:12 +00:00
virtual bool wantsSyncCounter() const;
Create a dedicated X11Filter for Client sync events and move it to X11 platform Summary: On Wayland we have the sync disabled as it doesn't work properly. This allows us to also move the sync event handling into the X11 standalone platform. The code is slightly refactored: instead of passing the event to each Client, we search for the matching Client. For that the SyncAlaram struct is added to public section of Client. The method to handle the sync doesn't need the event any more and is moved from events.cpp to client.cpp. Test Plan: Run Xephyr+kwin_x11, resized a window and verified through gdb breakpoint that the sync still works Reviewers: #kwin, #plasma Subscribers: plasma-devel Tags: #plasma Differential Revision: https://phabricator.kde.org/D7942
2017-09-22 18:35:50 +00:00
void handleSync();
Replace AbstractClient::doPerformInteractiveMoveResize() with a simpler solution AbstractClient::doPerformInteractiveMoveResize() is only used by the X11Client to reset a boolean flag when the client doesn't support sync counters. X11Client can call performInteractiveMoveResize() only in two cases: the sync request timer expires or the client increments the sync counter. This change removes the AbstractClient::doPerformInteractiveMoveResize() function and adds a function to handle the case where the sync timer expires explicitly. This removes a virtual function in the AbstractClient and makes code more readable.
2021-05-25 06:32:55 +00:00
void handleSyncTimeout();
Create a dedicated X11Filter for Client sync events and move it to X11 platform Summary: On Wayland we have the sync disabled as it doesn't work properly. This allows us to also move the sync event handling into the X11 standalone platform. The code is slightly refactored: instead of passing the event to each Client, we search for the matching Client. For that the SyncAlaram struct is added to public section of Client. The method to handle the sync doesn't need the event any more and is moved from events.cpp to client.cpp. Test Plan: Run Xephyr+kwin_x11, resized a window and verified through gdb breakpoint that the sync still works Reviewers: #kwin, #plasma Subscribers: plasma-devel Tags: #plasma Differential Revision: https://phabricator.kde.org/D7942
2017-09-22 18:35:50 +00:00
Destroy static Client helper window before application goes down Summary: Client uses a static Xcb::Window helper. This so far didn't get explicitly destroyed, so the application finalize cleaned it up. To destroy the window the xcb_connection_t* is used which the QGuiApplication already destroyed. This change ensures that the window gets destroyed before the xcb connection gets destroyed. In addition an assert is added to KWin::connection() to ensure that we still have the QGuiApplication::instance() when it's invoked. This way we'll notice if we have more cases where we call into xcb after the application went down. Reviewers: #plasma Subscribers: plasma-devel Projects: #plasma Differential Revision: https://phabricator.kde.org/D1573
2016-05-09 14:01:49 +00:00
static void cleanupX11();
Use Q_SLOTS and Q_SIGNALS instead of slots and signals Fixes compilation with Qt5/KF5 setup.
2013-07-22 14:07:39 +00:00
public Q_SLOTS:
Introduce an AbstractClient base class for Client (and ShellClient) The idea for this base class is to provide access to all elements which make up a managed "Client" being it X11 or Wayland. They share a lot, like they have a caption, they can be minimized, etc. etc. Of course it would have also been possible to derive a new class from Client, but that looks like the more difficult task as Client is very X11 specific. So far only a very small interface is extracted with pure-virtual methods. This is going to change by moving the functionality up into the AbstractClient. The interface extracted so far is inspired by the usage of FocusChain and users of FocusChain.
2015-03-05 09:21:03 +00:00
void closeWindow() override;
Implement the shortcut caption suffix for Wayland windows Summary: The generation of the shortcut caption part is moved from Client to AbstractClient. The ShellClient also has a captionSuffix and implements the full part in caption. Overall this needs more refactoring to support more sharing between the two implementations. But one step at a time. Reviewers: #kwin, #plasma Subscribers: plasma-devel Tags: #plasma Differential Revision: https://phabricator.kde.org/D7093
2017-08-03 05:11:40 +00:00
void updateCaption() override;
Make closeWindow() a public slot For JavaScript bindings.
2012-01-03 17:32:05 +00:00
KWin uses kdelibs coding style.
2011-01-30 14:34:42 +00:00
private:
// Handlers for X11 events
Enable map request event handling in Client
2013-07-26 11:46:06 +00:00
bool mapRequestEvent(xcb_map_request_event_t *e);
Enable unmap notify event handling in Client Interestingly the attribute send_event from XUnmapEvent does not exist in xcb_unmap_notify_event_t and also the X protocol doesn't know anything about send event.
2013-07-26 11:34:54 +00:00
void unmapNotifyEvent(xcb_unmap_notify_event_t *e);
Enable destroy notify event handling in Client
2013-07-26 11:40:43 +00:00
void destroyNotifyEvent(xcb_destroy_notify_event_t *e);
Enable configure request event handling in Client Still needs to port an XConfigureWindow to XCB.
2013-07-26 11:56:16 +00:00
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;
[xwayland] Add support for WL_SURFACE_ID When XWayland associates a Wayland surface with an X window it sends a WL_SURFACE_ID client message to the window manager. KWin listens for this client message in Toplevel and provides it as a member in Toplevel. This requires KWin to actually start a Wayland server (and XWayland) to make proper use of the information.
2015-01-09 10:16:57 +00:00
void clientMessageEvent(xcb_client_message_event_t *e) override;
Enable enter notify event handling in Client
2013-07-26 12:22:43 +00:00
void enterNotifyEvent(xcb_enter_notify_event_t *e);
Enable leave notify event handling in Client Still has an XQueryPointer which needs to be ported.
2013-07-26 12:29:47 +00:00
void leaveNotifyEvent(xcb_leave_notify_event_t *e);
Enable focus in event handling in Client
2013-07-26 12:35:28 +00:00
void focusInEvent(xcb_focus_in_event_t *e);
Enable focus out event handling in Client Focus out handling used to check the event queue for a matching focus in event to prevent short flickers when no window is active. This is not possible with XCB and needs a replacement. Maybe a short timer event.
2013-07-26 12:51:56 +00:00
void focusOutEvent(xcb_focus_out_event_t *e);
scene: Introduce window items Currently, dealing with sub-surfaces is very difficult due to the scene design being heavily influenced by X11 requirements. The goal of this change is to re-work scene abstractions to make improving the wayland support easier. The Item class is based on the QQuickItem class. My hope is that one day we will be able to transition to QtQuick for painting scene, but in meanwhile it makes more sense to have a minimalistic internal item class. The WindowItem class represents a window. The SurfaceItem class represents the contents of either an X11, or a Wayland, or an internal surface. The DecorationItem and the ShadowItem class represent the server-side deco and drop-shadow, respectively. At the moment, the SurfaceItem is bound to the scene window, but the long term plan is to break that connection so we could re-use the SurfaceItem for things such as software cursors and drag-and-drop additional icons. One of the responsibilities of the Item is to schedule repaints as needed. Ideally, there shouldn't be any addRepaint() calls in the core code. The Item class schedules repaints on geometry updates. In the future, it also has to request an update if its opacity or visibility changes.
2021-02-04 09:07:20 +00:00
void damageNotifyEvent();
branches/work/kwin_composite becomes new trunk kwin. svn path=/trunk/KDE/kdebase/workspace/; revision=659202
2007-04-29 17:35:43 +00:00
Improve updating user timestamp Use the timestamp from the xcb event which triggers the update whenever possible. If we don't have access to the latest event, let's at least update our own xTime prior to using it. Slightly unrelated change included: Group switches the userTime from XLib datatype to xcb datatype. BUG: 335637 REVIEW: 118456
2014-06-01 15:57:51 +00:00
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);
Client's button(Press|Release)Event and motionNotifyEvent accept xcb_window_t
2013-05-03 08:32:18 +00:00
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);
KWin uses kdelibs coding style.
2011-01-30 14:34:42 +00:00
protected:
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;
Implement AbstractClient::isActive and ::setActive Moves the implmentation to AbstractClient. Methods are no longer virtual, setActive calls a virtual protected method which is implemented in Client for Client specific activation code.
2015-03-12 15:08:19 +00:00
void doSetActive() override;
Implement keepAbove and keepBelow in AbstractClient Moves the properties and the base implementation into AbstractClient. Methods invoke a new protected virtual method which is implemented in Client to update the TabGroup.
2015-03-13 08:36:43 +00:00
void doSetKeepAbove() override;
void doSetKeepBelow() override;
Move core shade code to AbstractClient Summary: In order to allow shading wayland clients, this change moves core shade code from X11Client to AbstractClient. Test Plan: Shading still works on X11. Reviewers: #kwin, cblack Reviewed By: cblack Subscribers: cblack, kwin Tags: #kwin Differential Revision: https://phabricator.kde.org/D29512
2020-05-07 16:26:24 +00:00
void doSetShade(ShadeMode previousShadeMode) override;
Don't pass any arguments to AbstractClient::doSetDesktop() Summary: We don't use them anywhere. Subscribers: kwin Tags: #kwin Differential Revision: https://phabricator.kde.org/D27121
2020-02-03 00:19:46 +00:00
void doSetDesktop() override;
Move minimize implementation to AbstractClient
2015-03-13 13:45:21 +00:00
void doMinimize() override;
Move skipPager from Client to AbstractClient
2015-06-06 19:17:23 +00:00
void doSetSkipPager() override;
Move skipTaskbar from Client to AbstractClient At the same time the functionality for the "original_skip_taskbar" is splitted out. This removes the weird API with two boolean arguments to the set method. Instead there is a dedicated method for the orignal skip taskbar state which delegates to regular skipTaksbar.
2015-06-06 20:08:12 +00:00
void doSetSkipTaskbar() override;
Revert "Revert "Add "SkipSwitcher" to API"" This reverts commit 5ef119044df1b7eada7d4b6bf560bf5dd9fd7dbf.
2018-05-24 04:33:39 +00:00
void doSetSkipSwitcher() override;
Introduce AbstractClient::doSetDemandsAttention() Subscribers: kwin Tags: #kwin Differential Revision: https://phabricator.kde.org/D27119
2020-02-02 23:23:47 +00:00
void doSetDemandsAttention() override;
Move layer functionality to AbstractClient Merges together the code from ShellClient and Client and removes the starting differences. Long term it's better to have only one implementation to prevent diversions in the implementation. As it doesn't match exactly protected virtual methods are called which allow more specific implementations for a certain aspect of the layer resolving.
2015-09-17 09:06:59 +00:00
bool belongsToDesktop() 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
bool doStartInteractiveMoveResize() override;
bool isWaitingForInteractiveMoveResizeSync() const override;
void doInteractiveResizeSync() override;
Move implementation of (shrow|grow)(Horizontal|Vertical) to AbstractClient Methods are no longer virtual. The only x11 specific usage in these methods (resizeInc) is replaced by a virtual method. Default resize increments is QSize(1,1) for AbstractClient.
2015-10-26 14:49:03 +00:00
QSize resizeIncrements() const override;
Introduce pure virtual, protectd AbstractClient::acceptsFocus -> bool Replacement for calls to info->input() which is only valid for the Client sub class, but not for ShellClient. In ShellClient the implementation is swapped with wantsInput() and wantsInput() has a new implementation which properly delegates to rules() just like Client does.
2015-12-07 15:18:30 +00:00
bool acceptsFocus() const 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;
KWin uses kdelibs coding style.
2011-01-30 14:34:42 +00:00
Trembles the weave as the clock ticks, attain another microstate. Every disorder causes every duration, which ensures the one that stays. reality is relative. natural is disorder. [R]obinhood[P]andey Merging scripting from ^/branches/work/kwin_scripting TO ^/trunk svn path=/trunk/KDE/kdebase/workspace/; revision=1177865
2010-09-21 14:31:40 +00:00
//Signals for the scripting interface
Fix typos reported by Krazy SVN_SILENT svn path=/trunk/KDE/kdebase/workspace/; revision=1210596
2011-01-01 09:39:02 +00:00
//Signals make an excellent way for communication
Trembles the weave as the clock ticks, attain another microstate. Every disorder causes every duration, which ensures the one that stays. reality is relative. natural is disorder. [R]obinhood[P]andey Merging scripting from ^/branches/work/kwin_scripting TO ^/trunk svn path=/trunk/KDE/kdebase/workspace/; revision=1177865
2010-09-21 14:31:40 +00:00
//in between objects as compared to simple function
//calls
Use Q_SLOTS and Q_SIGNALS instead of slots and signals Fixes compilation with Qt5/KF5 setup.
2013-07-22 14:07:39 +00:00
Q_SIGNALS:
Rename Client to X11Client Summary: Currently each managed X11 client is represented with an instance of Client class, however the name of that class is very generic and the only reason why it's called that way is because historically kwin was created as an x11 window manager, so "Client" was a sensible choice. With introduction of wayland support, things had changed and therefore Client needs to be renamed to X11Client in order to better reflect what that class stands for. Renaming of Client to X11Client was agreed upon during the last KWin sprint. Test Plan: Compiles, the test suite is still green. Reviewers: #kwin, romangg Reviewed By: #kwin, romangg Subscribers: romangg, davidedmundson, kwin Tags: #kwin Differential Revision: https://phabricator.kde.org/D24184
2019-09-24 08:48:08 +00:00
void clientManaging(KWin::X11Client *);
void clientFullScreenSet(KWin::X11Client *, bool, bool);
Notify when the client palette changes and proxy this to kdecoration BUG: 341921 REVIEW: 121917
2015-01-08 11:45:40 +00:00
GUI: Kwin appmenu support: - Add support for application menu button in Kwin - Add kded appmenu configuration in kcm_style
2012-11-09 12:44:50 +00:00
/**
* Emitted whenever the Client want to show it menu
Use more traditional doxygen style Summary: So far we were following a bit unique and rare doxygen comment style: /** * Contents of the comment. **/ Doxygen comments with this style look balanced and neat, but many people that contribute to KWin don't follow this style. Instead, they prefer more traditional doxygen comment style, i.e. /** * Contents of the comment. */ Reviewing such changes has been a bit frustrating for me (so selfish!) and for other contributors. This change switches doxygen comment style in KWin to a more traditional style. The main reason for doing this is to make code review process easier for new contributors as well us. Reviewers: #kwin, davidedmundson Reviewed By: #kwin, davidedmundson Subscribers: kwin Tags: #kwin Differential Revision: https://phabricator.kde.org/D22812
2019-07-29 18:58:33 +00:00
*/
GUI: Kwin appmenu support: - Add support for application menu button in Kwin - Add kded appmenu configuration in kcm_style
2012-11-09 12:44:50 +00:00
void showRequest();
/**
* Emitted whenever the Client's menu is closed
Use more traditional doxygen style Summary: So far we were following a bit unique and rare doxygen comment style: /** * Contents of the comment. **/ Doxygen comments with this style look balanced and neat, but many people that contribute to KWin don't follow this style. Instead, they prefer more traditional doxygen comment style, i.e. /** * Contents of the comment. */ Reviewing such changes has been a bit frustrating for me (so selfish!) and for other contributors. This change switches doxygen comment style in KWin to a more traditional style. The main reason for doing this is to make code review process easier for new contributors as well us. Reviewers: #kwin, davidedmundson Reviewed By: #kwin, davidedmundson Subscribers: kwin Tags: #kwin Differential Revision: https://phabricator.kde.org/D22812
2019-07-29 18:58:33 +00:00
*/
GUI: Kwin appmenu support: - Add support for application menu button in Kwin - Add kded appmenu configuration in kcm_style
2012-11-09 12:44:50 +00:00
void menuHidden();
/**
* Emitted whenever the Client's menu is available
Use more traditional doxygen style Summary: So far we were following a bit unique and rare doxygen comment style: /** * Contents of the comment. **/ Doxygen comments with this style look balanced and neat, but many people that contribute to KWin don't follow this style. Instead, they prefer more traditional doxygen comment style, i.e. /** * Contents of the comment. */ Reviewing such changes has been a bit frustrating for me (so selfish!) and for other contributors. This change switches doxygen comment style in KWin to a more traditional style. The main reason for doing this is to make code review process easier for new contributors as well us. Reviewers: #kwin, davidedmundson Reviewed By: #kwin, davidedmundson Subscribers: kwin Tags: #kwin Differential Revision: https://phabricator.kde.org/D22812
2019-07-29 18:58:33 +00:00
*/
GUI: Kwin appmenu support: - Add support for application menu button in Kwin - Add kded appmenu configuration in kcm_style
2012-11-09 12:44:50 +00:00
void appMenuAvailable();
/**
* Emitted whenever the Client's menu is unavailable
Use more traditional doxygen style Summary: So far we were following a bit unique and rare doxygen comment style: /** * Contents of the comment. **/ Doxygen comments with this style look balanced and neat, but many people that contribute to KWin don't follow this style. Instead, they prefer more traditional doxygen comment style, i.e. /** * Contents of the comment. */ Reviewing such changes has been a bit frustrating for me (so selfish!) and for other contributors. This change switches doxygen comment style in KWin to a more traditional style. The main reason for doing this is to make code review process easier for new contributors as well us. Reviewers: #kwin, davidedmundson Reviewed By: #kwin, davidedmundson Subscribers: kwin Tags: #kwin Differential Revision: https://phabricator.kde.org/D22812
2019-07-29 18:58:33 +00:00
*/
GUI: Kwin appmenu support: - Add support for application menu button in Kwin - Add kded appmenu configuration in kcm_style
2012-11-09 12:44:50 +00:00
void appMenuUnavailable();
Export blocking compositing as a Client's Q_PROPERTY Allows to block compositing on Client's from scripts. Usecase: window rule cannot properly identify buggy clients and scripting allows to just act on fullscreen windows. BUG: 297146 FIXED-IN: 4.9.0 REVIEW: 104448
2012-03-31 17:09:00 +00:00
/**
* Emitted whenever the Client's block compositing state changes.
Use more traditional doxygen style Summary: So far we were following a bit unique and rare doxygen comment style: /** * Contents of the comment. **/ Doxygen comments with this style look balanced and neat, but many people that contribute to KWin don't follow this style. Instead, they prefer more traditional doxygen comment style, i.e. /** * Contents of the comment. */ Reviewing such changes has been a bit frustrating for me (so selfish!) and for other contributors. This change switches doxygen comment style in KWin to a more traditional style. The main reason for doing this is to make code review process easier for new contributors as well us. Reviewers: #kwin, davidedmundson Reviewed By: #kwin, davidedmundson Subscribers: kwin Tags: #kwin Differential Revision: https://phabricator.kde.org/D22812
2019-07-29 18:58:33 +00:00
*/
Rename Client to X11Client Summary: Currently each managed X11 client is represented with an instance of Client class, however the name of that class is very generic and the only reason why it's called that way is because historically kwin was created as an x11 window manager, so "Client" was a sensible choice. With introduction of wayland support, things had changed and therefore Client needs to be renamed to X11Client in order to better reflect what that class stands for. Renaming of Client to X11Client was agreed upon during the last KWin sprint. Test Plan: Compiles, the test suite is still green. Reviewers: #kwin, romangg Reviewed By: #kwin, romangg Subscribers: romangg, davidedmundson, kwin Tags: #kwin Differential Revision: https://phabricator.kde.org/D24184
2019-09-24 08:48:08 +00:00
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();
KWin uses kdelibs coding style.
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;
Improve sharing of maximize between Client and ShellClient The changeMaximize method is added as a pure virtual protected method to AbstractClient. This replaces the previous pure virtual maximize method. Which is now directly implemented in AbstractClient (reusing the implementation previously in Client).
2015-10-13 08:22:18 +00:00
void changeMaximize(bool horizontal, bool vertical, bool adjust) override;
KWin uses kdelibs coding style.
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);
Drop some custom list typedefs Summary: Qt has its own thing where a type might also have corresponding list alias, e.g. QObject and QObjectList, QWidget and QWidgetList. I don't know why Qt does that, maybe for some historical reasons, but what matters is that we copy this pattern here in KWin. While this pattern might be useful with some long list types, for example QList<QWeakPointer<TabBoxClient>> TabBoxClientList in general, it causes more harm than good. For example, we've got two new client types, do we need corresponding list typedefs for them? If no, why do we have ClientList and so on? Another problem with these typedefs is that you need to include utils.h header in order to use them. A better way to handle such things is to just forward declare a client class (if that's possible) and use it directly with QList or QVector. This way translation units don't get "bloated" with utils.h stuff for no apparent reason. So, in order to make code more consistent and easier to follow, this change drops some of our custom typedefs. Namely ConstClientList, ClientList, DeletedList, UnmanagedList, ToplevelList, and GroupList. Test Plan: Compiles. Reviewers: #kwin Subscribers: kwin Tags: #kwin Differential Revision: https://phabricator.kde.org/D24950
2019-10-16 09:11:04 +00:00
bool hasTransientInternal(const X11Client *c, bool indirect, QList<const X11Client *> &set) const;
Implement support for window shortcuts for Wayland windows Summary: Moves most of the implementation from Client to AbstractClient, so that it can be used for both Client and ShellClient. Only the X11 specific code is kept in Client. Not yet implemented is updating the window caption. Unfortunately the testing of this feature showed that setting a window shortcut is not working on Wayland at all (the Qt widget doesn't properly catch the shortcut). So this feature is currently only of erm theoretical use. Test Plan: Added new test case. No testing in real world as explained. Reviewers: #kwin, #plasma Subscribers: plasma-devel, kwin Tags: #kwin Differential Revision: https://phabricator.kde.org/D6818
2017-07-21 18:22:56 +00:00
void setShortcutInternal() override;
KWin uses kdelibs coding style.
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();
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 leaveInteractiveMoveResize() override;
Provide positionGeometryTip() as virtual method in AbstractClient The implementation of positionGeometryTip is X specific, we need to figure out whether that one makes sense for Wayland. Given that, let's have it virtual to ease the transition of code which calls it.
2015-10-23 10:27:06 +00:00
void positionGeometryTip() override;
Grab all possible keyboard modifiers for window commands BUG: 424272 FIXED-IN: 5.19.4
2020-07-16 11:01:08 +00:00
void establishCommandWindowGrab(uint8_t button);
void establishCommandAllGrab(uint8_t button);
Drop size from Client::resizeDecoration No longer used.
2014-07-25 11:14:53 +00:00
void resizeDecoration();
Introduce AbstractClient::createDecoration() Summary: We have duplicated code in InternalClient and XdgShellClient to create decorations. In order to get rid of the code duplication, this change introduces a method that AbstractClient subclasses can call to create a window decoration. Test Plan: Tests pass. Reviewers: #kwin, apol Reviewed By: apol Subscribers: apol, kwin Tags: #kwin Differential Revision: https://phabricator.kde.org/D27822
2020-02-25 12:57:44 +00:00
void createDecoration(const QRect &oldgeom) override;
KWin uses kdelibs coding style.
2011-01-30 14:34:42 +00:00
void pingWindow();
Client::killProcess takes xcb_timestamp_t as argument
2013-05-03 09:02:06 +00:00
void killProcess(bool ask, xcb_timestamp_t timestamp = XCB_TIME_CURRENT_TIME);
KWin uses kdelibs coding style.
2011-01-30 14:34:42 +00:00
void updateUrgency();
Port Client::sendClientMessage to XCB
2013-05-03 08:55:37 +00:00
static void sendClientMessage(xcb_window_t w, xcb_atom_t a, xcb_atom_t protocol,
[x11] Send a valid timestamp in TakeFocus messages Kwin sends out undated WM_TAKE_FOCUS client messages. Gtk based applications such as Firefox react to these by handing focus to one of their subwindows using XSetInputFocus(), and pass on the null time field that they received in the client message to XSetInputFocus(). If for whatever reason the application (firefox) is slow to process the event, it might issue that XSetInputFocus() message at a time when it has already lost focus to the next application. This results in Firefox stealing back the focus from the next application. Normally, such an occurrence would not happen, as the server could tell by the time field that the message is stale. Until 2016 (e73e331f35b9da4bbb99c80c5c1eedd2ae99422b) kwin *used* to send a valid timestamp, but this got deliberately broken to appease some Java Applications which were "extremely picky" and would refuse focus. This was based on the assumption that no other toolkit used the timestamp from take focus events which is now proven to be false. ICCCM document states: Windows with the atom WM_TAKE_FOCUS in their WM_PROTOCOLS property may receive a ClientMessage event from the window manager (as described in section 4.2.8) with WM_TAKE_FOCUS in its data[0] field and a valid timestamp (i.e. not CurrentTime ) in its data[1] field." BUG: 421068
2020-05-22 12:56:20 +00:00
uint32_t data1 = 0, uint32_t data2 = 0, uint32_t data3 = 0);
KWin uses kdelibs coding style.
2011-01-30 14:34:42 +00:00
Port Client::manage away from XGetWindowAttributes Replaced by Xcb::WindowAttributes and Xcb::WindowGeometry. Also arguments of Client::embedClient are adjusted to take the required values directly.
2014-04-25 11:42:52 +00:00
void embedClient(xcb_window_t w, xcb_visualid_t visualid, xcb_colormap_t colormap, uint8_t depth);
KWin uses kdelibs coding style.
2011-01-30 14:34:42 +00:00
void detectNoBorder();
Move the KDecoration2::Decoration to AbstractClient This includes the methods: * decoration() * decoration() const * isDecorated() const In addition new protected methods are added to destroy the Decoration and to set it. Usage of m_decoration in Client code is adjusted.
2015-12-03 12:24:44 +00:00
void destroyDecoration() override;
KWin uses kdelibs coding style.
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);
KWin uses kdelibs coding style.
2011-01-30 14:34:42 +00:00
Remove YesIKnowWhatImDoing from internal API No need to have Allowed everywhere. REVIEW: 110197
2013-04-26 07:47:45 +00:00
void internalShow();
void internalHide();
void internalKeep();
void map();
void unmap();
KWin uses kdelibs coding style.
2011-01-30 14:34:42 +00:00
void updateHiddenPreview();
Revert the fix for the texture bleeding issue This reverts commit 9151bb7b9e71fdfeb3d3682ee8a42d796fa315e9. This reverts commit ac4dce1c20a1cbfd3974bf8da6dd7557d35a4ca1. This reverts commit 754b72d155820a6c8a9ba94b2c0960da1b2f86ce. In order to make the fix work, we need to redirect the client window instead of the frame window. However, we cannot to do that because Xwayland expects the toplevel window(in our case, the frame window) to be redirected. Another solution to the texture bleeding issue must be found. CCBUG: 257566 CCBUG: 360549
2019-12-02 17:36:13 +00:00
KWin uses kdelibs coding style.
2011-01-30 14:34:42 +00:00
void updateInputShape();
[x11] Make geometry updates in X11Client more comprehensible Summary: This change makes geometry updates in the X11Client class simpler and also fixes a bug in the move() method. Test Plan: All tests pass. Reviewers: #kwin Subscribers: kwin Tags: #kwin Differential Revision: https://phabricator.kde.org/D25710
2019-12-03 07:33:14 +00:00
void updateServerGeometry();
Remove Scene::Window::{discard,update}Pixmap They are used only by X11Client, so make X11Client call relevants methods on the surface item directly instead. In hindsight, it will be a really good idea to make SurfaceItemX11 and SurfaceItemXwayland(?) automatically manage the window pixmap. However, it can be done once an item freezing api is added and we fix the cross-fade animation.
2021-05-19 06:22:05 +00:00
void discardWindowPixmap();
[x11] Fix visual artifacts during interactive resize Summary: When a window is being interactively resized, its contents may jump. The reason why that happens is because KWin renders partially resized client window. Composite extension spec says that a window will get a new pixmap each time it is resized or mapped. This applies to the frame window, but not to the client window itself. If the client window is resized, off-screen storage for the frame window won't be reallocated. Therefore, KWin may render partially resized client window if the client doesn't attempt to be in sync with our rendering loop. Currently, the only way to do that is to use extended frame counters, which are not supported by KWin. So, in order to fix visual artifacts during interactive resize, we need somehow forcefully re-allocate off-screen storage for the frame window. Unfortunately, Composite extension doesn't provide any request to do that, so the only option we have is to resize the frame window. BUG: 415839 FIXED-IN: 5.18.0 Reviewers: #kwin Subscribers: davidedmundson, ngraham, alexde, fredrik, kwin Tags: #kwin Differential Revision: https://phabricator.kde.org/D26914
2020-02-03 11:29:43 +00:00
void updateWindowPixmap();
KWin uses kdelibs coding style.
2011-01-30 14:34:42 +00:00
Client's userTime related code ported over to XCB At same time variable user_time renamed to m_userTime to follow naming scheme.
2013-05-03 09:29:50 +00:00
xcb_timestamp_t readUserTimeMapTimestamp(const KStartupInfoId* asn_id, const KStartupInfoData* asn_data,
KWin uses kdelibs coding style.
2011-01-30 14:34:42 +00:00
bool session) const;
Client's userTime related code ported over to XCB At same time variable user_time renamed to m_userTime to follow naming scheme.
2013-05-03 09:29:50 +00:00
xcb_timestamp_t readUserCreationTime() const;
KWin uses kdelibs coding style.
2011-01-30 14:34:42 +00:00
void startupIdChanged();
kwin: Insert an input-only window above each decorated client This input-only window is used to capture events above the client window and preventing them from reaching the client. It is currently used to enlarge the borders by an invisible amount, using the ExtendedBorderRegion provided by the decoration.
2011-11-09 19:39:13 +00:00
void updateInputWindow();
Split Client::updateShowOnScreenEdge into two parts
2015-01-15 14:51:21 +00:00
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.
Use more traditional doxygen style Summary: So far we were following a bit unique and rare doxygen comment style: /** * Contents of the comment. **/ Doxygen comments with this style look balanced and neat, but many people that contribute to KWin don't follow this style. Instead, they prefer more traditional doxygen comment style, i.e. /** * Contents of the comment. */ Reviewing such changes has been a bit frustrating for me (so selfish!) and for other contributors. This change switches doxygen comment style in KWin to a more traditional style. The main reason for doing this is to make code review process easier for new contributors as well us. Reviewers: #kwin, davidedmundson Reviewed By: #kwin, davidedmundson Subscribers: kwin Tags: #kwin Differential Revision: https://phabricator.kde.org/D22812
2019-07-29 18:58:33 +00:00
*/
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();
Move decoration renderer to decoration item Currently, the implementation of the DecoratedClient and the decoration renderer are strongly coupled. This poses a problem with the item based design as the ultimate goal is to have scene items construct paint nodes which are then fed to the renderer. The DecorationItem has to have control over the decoration texture. Another issue is that the scene cannot smoothly cross-fade between two window states if the decoration is removed, e.g. from fullscreen mode to normal and vice versa. This change moves the decoration renderer to the decoration item. With the introduction of a generic scene texture atlas, we hope to get rid of the decoration renderer altogether.
2021-04-26 16:38:40 +00:00
void maybeCreateX11DecorationRenderer();
void maybeDestroyX11DecorationRenderer();
Remove updateDecoration() in AbstractClient
2021-12-08 13:28:43 +00:00
void updateDecoration(bool check_workspace_pos, bool force = false);
Move decoration renderer to decoration item Currently, the implementation of the DecoratedClient and the decoration renderer are strongly coupled. This poses a problem with the item based design as the ultimate goal is to have scene items construct paint nodes which are then fed to the renderer. The DecorationItem has to have control over the decoration texture. Another issue is that the scene cannot smoothly cross-fade between two window states if the decoration is removed, e.g. from fullscreen mode to normal and vice versa. This change moves the decoration renderer to the decoration item. With the introduction of a generic scene texture atlas, we hope to get rid of the decoration renderer altogether.
2021-04-26 16:38:40 +00:00
Use Xcb::Window wrapper class for Client::m_client Now we can use the wrapper for the client which we manage.
2013-09-10 05:27:39 +00:00
Xcb::Window m_client;
Use an Xcb::Window for Client::wrapper The Xcb::Window nicely encapsulates the created wrapper window. As almost all code is adjusted, the variable is also renamed to m_wrapper to follow the normal naming scheme.
2013-05-02 16:26:05 +00:00
Xcb::Window m_wrapper;
Toplevel::frameId() becomes virtual The frameId only makes sense for a Client, in case of Unmanaged the same window id is used as for the window() handle. Client creates the frame and destroys it. Given that it makes sense to let Client manage the frame properly. The ::frameId() is therefore virtual and as base implementation it returns the client id. Client reimplements it and returns the proper frame id. Method is also implemented in Deleted as it used to be passed to deleted.
2013-09-10 06:13:33 +00:00
Xcb::Window m_frame;
KWin uses kdelibs coding style.
2011-01-30 14:34:42 +00:00
QStringList activityList;
use QWidgetAction for activity setting in alt+f3 not that i really like using QWidgetAction, but it'll prevent the popup from autoclosing. Introduce activityUpdateBlocking to prevent users from removing the popup under their fingertips BUG: 283309 FIXED-IN: 4.10.2 REVIEW: 107762
2013-03-24 20:57:26 +00:00
int m_activityUpdatesBlocked;
bool m_blockedActivityUpdatesRequireTransients;
Port Client's move resize grab window to XCB Using Xcb::Window to wrap this helper window and port all the used XLib calls to XCB. Also renaming the variable to m_ and camel case to follow general naming scheme.
2013-05-02 17:04:43 +00:00
Xcb::Window m_moveResizeGrabWindow;
KWin uses kdelibs coding style.
2011-01-30 14:34:42 +00:00
bool move_resize_has_keyboard_grab;
substitute mapping_state == Withdrawn by m_managed as the flamewar pointed out, resetShowingDesktop invalidly keeps hidden windows the reason is that there're several updateVisiblity calls (notably one from the compositor) which break the showingDesktop state as a side effect (before ::manage() does it's thing) Since they also invalidate the Withdrawn mapping state, that will fail as isManaged() test (it's also invalidly used by the compositor to set up the decoration, isManaged() used to be true because of the updateVisibility() call before) since the result is never Withdrawn CCBUG: 299655 REVIEW: 105303
2012-06-19 21:12:37 +00:00
bool m_managed;
KWin uses kdelibs coding style.
2011-01-30 14:34:42 +00:00
Use Xcb::GeometryHints instead of XGetWMNormalHints Xcb::GeometryHints is a convenient wrapper around the size hints as described in ICCCM combined with the sanity checks so far applied by KWin after reading the property. Instead of accessing the members of the property structure, we are now using the convenience methods. During ::manage no further actions are triggered when reading the size hints. Only when they are read later on the previous checks are applied. During ::manage they can be ignored as it had a dedicated isManaged check. The method ::resizeWithCheck got a new argument of type xcb_gravity_t which defaults to 0. This is needed from ::configureRequest which so far temporarily changed the xSizeHints structure. By passing as an argument this is no longer needed. REVIEW: 122185
2015-01-21 15:05:29 +00:00
Xcb::GeometryHints m_geometryHints;
KWin uses kdelibs coding style.
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;
Split Client::readTransient into two parts
2015-01-15 15:23:29 +00:00
Xcb::TransientFor fetchTransient() const;
void readTransientProperty(Xcb::TransientFor &transientFor);
KWin uses kdelibs coding style.
2011-01-30 14:34:42 +00:00
void readTransient();
Port Client::transient_for handling to XCB The type of the transient_for related variables are changed to xcb_window_t. They cannot be Xcb::Window as we don't take ownership over the transient for window. Variables are renamed to m_camelCase to follow naming scheme. A wrapper for retrieving the TransientFor hint is added to the Xcb Wrappers.
2013-05-03 06:53:35 +00:00
xcb_window_t verifyTransientFor(xcb_window_t transient_for, bool set);
Move transients from Client to AbstractClient Unfortunately introduces a few casts to Client again.
2015-09-14 08:55:27 +00:00
void addTransient(AbstractClient* cl) override;
void removeTransient(AbstractClient* cl) override;
KWin uses kdelibs coding style.
2011-01-30 14:34:42 +00:00
void removeFromMainClients();
void cleanGrouping();
void checkGroupTransients();
Port Client::transient_for handling to XCB The type of the transient_for related variables are changed to xcb_window_t. They cannot be Xcb::Window as we don't take ownership over the transient for window. Variables are renamed to m_camelCase to follow naming scheme. A wrapper for retrieving the TransientFor hint is added to the Xcb Wrappers.
2013-05-03 06:53:35 +00:00
void setTransient(xcb_window_t new_transient_for_id);
xcb_window_t m_transientForId;
xcb_window_t m_originalTransientForId;
Rename Client to X11Client Summary: Currently each managed X11 client is represented with an instance of Client class, however the name of that class is very generic and the only reason why it's called that way is because historically kwin was created as an x11 window manager, so "Client" was a sensible choice. With introduction of wayland support, things had changed and therefore Client needs to be renamed to X11Client in order to better reflect what that class stands for. Renaming of Client to X11Client was agreed upon during the last KWin sprint. Test Plan: Compiles, the test suite is still green. Reviewers: #kwin, romangg Reviewed By: #kwin, romangg Subscribers: romangg, davidedmundson, kwin Tags: #kwin Differential Revision: https://phabricator.kde.org/D24184
2019-09-24 08:48:08 +00:00
X11Client *shade_below;
Port reading Motif hints to XCB A wrapper class for MotifHints is added to xcbutils. This class manages the information about the read Motif hints, so that Client doesn't need to have a copy of the read states. The class is designed in a way that during Client::manage we get rid of another roundtrip. REVIEW: 122378
2015-02-02 13:56:21 +00:00
Xcb::MotifHints m_motif;
KWin uses kdelibs coding style.
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
add rule/property based composite blocking
2011-03-20 14:42:05 +00:00
bool blocks_compositing;
Remove Client fullscreen hack Summary: This hack seems to be deactivated by default nowadays and I did not find an option in the KCMs to activate it. Git blame shows some last commits from around 2012 to the functions, but they only deal with code style. Also even if it would be enabled, in light of Wayland we don't want some roque XWayland client go bonkers via this hack. This patch removes the code path in order to decrease complexity and ease future changes to the fullscreen handling overall. Test Plan: Manually and autotests pass. Reviewers: #kwin, zzag Reviewed By: #kwin, zzag Subscribers: zzag, graesslin, kwin Tags: #kwin Maniphest Tasks: T11098 Differential Revision: https://phabricator.kde.org/D18157
2019-01-10 15:01:42 +00:00
KWin uses kdelibs coding style.
2011-01-30 14:34:42 +00:00
enum FullScreenMode {
FullScreenNone,
Remove Client fullscreen hack Summary: This hack seems to be deactivated by default nowadays and I did not find an option in the KCMs to activate it. Git blame shows some last commits from around 2012 to the functions, but they only deal with code style. Also even if it would be enabled, in light of Wayland we don't want some roque XWayland client go bonkers via this hack. This patch removes the code path in order to decrease complexity and ease future changes to the fullscreen handling overall. Test Plan: Manually and autotests pass. Reviewers: #kwin, zzag Reviewed By: #kwin, zzag Subscribers: zzag, graesslin, kwin Tags: #kwin Maniphest Tasks: T11098 Differential Revision: https://phabricator.kde.org/D18157
2019-01-10 15:01:42 +00:00
FullScreenNormal
} m_fullscreenMode;
KWin uses kdelibs coding style.
2011-01-30 14:34:42 +00:00
MaximizeMode max_mode;
Change Client's clormap to xcb_colormap_t At same time also renaming variable to follow naming scheme and have a sensible name. Also moved default value initialization into initializer list. REVIEW: 110283
2013-05-03 09:46:18 +00:00
xcb_colormap_t m_colormap;
Drop Client::cap_deco as it's nowhere used Summary: cap_deco was only used in the caption with stripped arg case which was unused and thus removed. Now cap_deco is completely unused. Due to that we can also remove the stripped client script which only manipulated the cap_deco. Test Plan: Compiles Reviewers: #kwin, #plasma Subscribers: plasma-devel, kwin Tags: #kwin Differential Revision: https://phabricator.kde.org/D7077
2017-08-02 16:41:38 +00:00
QString cap_normal, cap_iconic, cap_suffix;
KWin uses kdelibs coding style.
2011-01-30 14:34:42 +00:00
Group* in_group;
QTimer* ping_timer;
detach killHelper process from KWin BUG: 295940 FIXED-IN: 4.9 REVIEW: 104627
2012-04-16 21:52:13 +00:00
qint64 m_killHelperPID;
Use xcb_timestamp_t for ping window functionality At same time rename the variable to follow m_camelCase naming scheme and initialise the variable with default value in ctor.
2013-05-03 09:35:46 +00:00
xcb_timestamp_t m_pingTimestamp;
Client's userTime related code ported over to XCB At same time variable user_time renamed to m_userTime to follow naming scheme.
2013-05-03 09:29:50 +00:00
xcb_timestamp_t m_userTime;
Adjust kde-workspace to introduction of flags in NET classes
2014-02-03 08:37:08 +00:00
NET::Actions allowed_actions;
KWin uses kdelibs coding style.
2011-01-30 14:34:42 +00:00
bool shade_geometry_change;
Rename X11Client::getSyncRequest() to X11Client::syncRequest() Getter methods should not have "get" prefix.
2020-01-28 19:46:09 +00:00
SyncRequest m_syncRequest;
Rename Client to X11Client Summary: Currently each managed X11 client is represented with an instance of Client class, however the name of that class is very generic and the only reason why it's called that way is because historically kwin was created as an x11 window manager, so "Client" was a sensible choice. With introduction of wayland support, things had changed and therefore Client needs to be renamed to X11Client in order to better reflect what that class stands for. Renaming of Client to X11Client was agreed upon during the last KWin sprint. Test Plan: Compiles, the test suite is still green. Reviewers: #kwin, romangg Reviewed By: #kwin, romangg Subscribers: romangg, davidedmundson, kwin Tags: #kwin Differential Revision: https://phabricator.kde.org/D24184
2019-09-24 08:48:08 +00:00
static bool check_active_modal; ///< \see X11Client::checkActiveModal()
KWin uses kdelibs coding style.
2011-01-30 14:34:42 +00:00
int sm_stacking_order;
friend struct ResetupRulesProcedure;
friend bool performTransiencyCheck();
Split Client::checkActivities into two parts REVIEW: 122087 CCBUG: 329979
2015-01-15 15:31:20 +00:00
Xcb::StringProperty fetchActivities() const;
void readActivities(Xcb::StringProperty &property);
KWin uses kdelibs coding style.
2011-01-30 14:34:42 +00:00
void checkActivities();
bool activitiesDefined; //whether the x property was actually set
fix showing of window on inactive activities during session save This is what 7ce380497f tried to do (and got reverted by my previous commit). The approach is basically the same, just temporarily fake that the window is on all activities, thus it will be temporarily shown for the session interact, but this time there seem to be no broken side-effects (and if there are, they'll be at least limited to activities and not break virtual desktops). Also, 'needsSessionInteract' was a misnomer - it certainly wasn't set for all windows that needed session interaction. Just call it what it really is. Differential Revision: https://phabricator.kde.org/D5614
2017-04-27 10:18:41 +00:00
bool sessionActivityOverride;
Optimize away XMoveWindow() calls in the common click-and-drag case This implements an optimization similar to one in compiz which defers updating the backing X window during a window move until the move is terminated. This helps alleviate some choppiness when using composite + vsync. REVIEW: 107256
2012-11-07 23:54:05 +00:00
bool needsXWindowMove;
kwin: Insert an input-only window above each decorated client This input-only window is used to capture events above the client window and preventing them from reaching the client. It is currently used to enlarge the borders by an invisible amount, using the ExtendedBorderRegion provided by the decoration.
2011-11-09 19:39:13 +00:00
Port Client's decoration resize extend input window to XCB Using Xcb::Window to manage the xcb_window_t and simplify the code - no longer need to check whether the input_window is valid before calling e.g. map, as that's handled in Xcb::Window. One XLib usage for setting cursor is still present. This will be ported once all the QCursor::handle() get removed. REVIEW: 108771
2013-02-04 10:20:15 +00:00
Xcb::Window m_decoInputExtent;
kwin: Insert an input-only window above each decorated client This input-only window is used to capture events above the client window and preventing them from reaching the client. It is currently used to enlarge the borders by an invisible amount, using the ExtendedBorderRegion provided by the decoration.
2011-11-09 19:39:13 +00:00
QPoint input_offset;
Replacement for XEvent queue inspection in FocusOut event case Instead of inspecting the XEvent queue we create a Timer with a singleshot of 0 msec to move the setActive(false) call to the end of the event handling. In case there is a matching FocusIn event this will be handled before the timer fired and can cancel the timer.
2013-08-05 07:48:14 +00:00
QTimer *m_focusOutTimer;
[kwin] Client supports an X property for color scheme The X property _KDE_NET_WM_COLOR_SCHEME can be set on a window and specifies the absolute path to a .color file describing the color scheme of the managed client. The Client reads this property and creates a QPalette from it. If the property is not set or the value is incorrect, the Client uses KWin's default palette. The idea behind this property is to allow an application with a custom color scheme to tell KWin which color scheme the window decoration should use. So that the window looks as a solid pattern again.
2013-10-14 05:17:07 +00:00
Add hint similar to autohide to raise/lower a window Add action type to screen edge show to allow raise/lower as well as autohide Add an action type to screen edge show to allow raise/lower as well as autohide. This uses the same atom, using a mask to separate type and location. The logic for handling geometry changes is moved from the screenedge to the client so that we can handle both types without screenedge needing to know what the raise is for. REVIEW: 124272
2015-10-11 20:48:29 +00:00
QMetaObject::Connection m_edgeRemoveConnection;
support for auto-hidden windows to resize Summary: auto hidden windows were shown again when their geometry changed, this was done for being as easy as possible as the unhide zone changed, but the behavior looked very annoying as autohide panels with an self resize taskbar would unhide themselves every time any window gets open or closed. This makes the edge keep track of windows that can resize/move themselves while auto hidden Test Plan: a self-resizing autohidden panel with a taskbar in it doesn't auto unhide anymore when a window is opened or closed. the unhide area gets properly updated Reviewers: graesslin, #plasma Reviewed By: graesslin, #plasma Subscribers: luebking, plasma-devel, kwin, #kwin Tags: #kwin Differential Revision: https://phabricator.kde.org/D4718
2017-03-08 22:54:58 +00:00
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;
x11: Pick better names for geometries before blocking The new names express better what "geometries before update blocking" are.
2021-05-28 05:47:05 +00:00
QRect m_lastBufferGeometry;
QRect m_lastFrameGeometry;
QRect m_lastClientGeometry;
Move decoration renderer to decoration item Currently, the implementation of the DecoratedClient and the decoration renderer are strongly coupled. This poses a problem with the item based design as the ultimate goal is to have scene items construct paint nodes which are then fed to the renderer. The DecorationItem has to have control over the decoration texture. Another issue is that the scene cannot smoothly cross-fade between two window states if the decoration is removed, e.g. from fullscreen mode to normal and vice versa. This change moves the decoration renderer to the decoration item. With the introduction of a generic scene texture atlas, we hope to get rid of the decoration renderer altogether.
2021-04-26 16:38:40 +00:00
QScopedPointer<X11DecorationRenderer> m_decorationRenderer;
KWin uses kdelibs coding style.
2011-01-30 14:34:42 +00:00
};
branches/work/kwin_composite becomes new trunk kwin. svn path=/trunk/KDE/kdebase/workspace/; revision=659202
2007-04-29 17:35:43 +00:00
Rename Client to X11Client Summary: Currently each managed X11 client is represented with an instance of Client class, however the name of that class is very generic and the only reason why it's called that way is because historically kwin was created as an x11 window manager, so "Client" was a sensible choice. With introduction of wayland support, things had changed and therefore Client needs to be renamed to X11Client in order to better reflect what that class stands for. Renaming of Client to X11Client was agreed upon during the last KWin sprint. Test Plan: Compiles, the test suite is still green. Reviewers: #kwin, romangg Reviewed By: #kwin, romangg Subscribers: romangg, davidedmundson, kwin Tags: #kwin Differential Revision: https://phabricator.kde.org/D24184
2019-09-24 08:48:08 +00:00
inline xcb_window_t X11Client::wrapperId() const
KWin uses kdelibs coding style.
2011-01-30 14:34:42 +00:00
{
Use an Xcb::Window for Client::wrapper The Xcb::Window nicely encapsulates the created wrapper window. As almost all code is adjusted, the variable is also renamed to m_wrapper to follow the normal naming scheme.
2013-05-02 16:26:05 +00:00
return m_wrapper;
KWin uses kdelibs coding style.
2011-01-30 14:34:42 +00:00
}
branches/work/kwin_composite becomes new trunk kwin. svn path=/trunk/KDE/kdebase/workspace/; revision=659202
2007-04-29 17:35:43 +00:00
Rename Client to X11Client Summary: Currently each managed X11 client is represented with an instance of Client class, however the name of that class is very generic and the only reason why it's called that way is because historically kwin was created as an x11 window manager, so "Client" was a sensible choice. With introduction of wayland support, things had changed and therefore Client needs to be renamed to X11Client in order to better reflect what that class stands for. Renaming of Client to X11Client was agreed upon during the last KWin sprint. Test Plan: Compiles, the test suite is still green. Reviewers: #kwin, romangg Reviewed By: #kwin, romangg Subscribers: romangg, davidedmundson, kwin Tags: #kwin Differential Revision: https://phabricator.kde.org/D24184
2019-09-24 08:48:08 +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
}
Rename Client to X11Client Summary: Currently each managed X11 client is represented with an instance of Client class, however the name of that class is very generic and the only reason why it's called that way is because historically kwin was created as an x11 window manager, so "Client" was a sensible choice. With introduction of wayland support, things had changed and therefore Client needs to be renamed to X11Client in order to better reflect what that class stands for. Renaming of Client to X11Client was agreed upon during the last KWin sprint. Test Plan: Compiles, the test suite is still green. Reviewers: #kwin, romangg Reviewed By: #kwin, romangg Subscribers: romangg, davidedmundson, kwin Tags: #kwin Differential Revision: https://phabricator.kde.org/D24184
2019-09-24 08:48:08 +00:00
inline bool X11Client::groupTransient() const
KWin uses kdelibs coding style.
2011-01-30 14:34:42 +00:00
{
Port Client::transient_for handling to XCB The type of the transient_for related variables are changed to xcb_window_t. They cannot be Xcb::Window as we don't take ownership over the transient for window. Variables are renamed to m_camelCase to follow naming scheme. A wrapper for retrieving the TransientFor hint is added to the Xcb Wrappers.
2013-05-03 06:53:35 +00:00
return m_transientForId == rootWindow();
KWin uses kdelibs coding style.
2011-01-30 14:34:42 +00:00
}
branches/work/kwin_composite becomes new trunk kwin. svn path=/trunk/KDE/kdebase/workspace/; revision=659202
2007-04-29 17:35:43 +00:00
SVN_SILENT Standardize coding style on client.* and workspace.* svn path=/trunk/KDE/kdebase/workspace/; revision=898612
2008-12-18 13:50:57 +00:00
// Needed because verifyTransientFor() may set transient_for_id to root window,
branches/work/kwin_composite becomes new trunk kwin. svn path=/trunk/KDE/kdebase/workspace/; revision=659202
2007-04-29 17:35:43 +00:00
// if the original value has a problem (window doesn't exist, etc.)
Rename Client to X11Client Summary: Currently each managed X11 client is represented with an instance of Client class, however the name of that class is very generic and the only reason why it's called that way is because historically kwin was created as an x11 window manager, so "Client" was a sensible choice. With introduction of wayland support, things had changed and therefore Client needs to be renamed to X11Client in order to better reflect what that class stands for. Renaming of Client to X11Client was agreed upon during the last KWin sprint. Test Plan: Compiles, the test suite is still green. Reviewers: #kwin, romangg Reviewed By: #kwin, romangg Subscribers: romangg, davidedmundson, kwin Tags: #kwin Differential Revision: https://phabricator.kde.org/D24184
2019-09-24 08:48:08 +00:00
inline bool X11Client::wasOriginallyGroupTransient() const
KWin uses kdelibs coding style.
2011-01-30 14:34:42 +00:00
{
Port Client::transient_for handling to XCB The type of the transient_for related variables are changed to xcb_window_t. They cannot be Xcb::Window as we don't take ownership over the transient for window. Variables are renamed to m_camelCase to follow naming scheme. A wrapper for retrieving the TransientFor hint is added to the Xcb Wrappers.
2013-05-03 06:53:35 +00:00
return m_originalTransientForId == rootWindow();
KWin uses kdelibs coding style.
2011-01-30 14:34:42 +00:00
}
branches/work/kwin_composite becomes new trunk kwin. svn path=/trunk/KDE/kdebase/workspace/; revision=659202
2007-04-29 17:35:43 +00:00
Rename Client to X11Client Summary: Currently each managed X11 client is represented with an instance of Client class, however the name of that class is very generic and the only reason why it's called that way is because historically kwin was created as an x11 window manager, so "Client" was a sensible choice. With introduction of wayland support, things had changed and therefore Client needs to be renamed to X11Client in order to better reflect what that class stands for. Renaming of Client to X11Client was agreed upon during the last KWin sprint. Test Plan: Compiles, the test suite is still green. Reviewers: #kwin, romangg Reviewed By: #kwin, romangg Subscribers: romangg, davidedmundson, kwin Tags: #kwin Differential Revision: https://phabricator.kde.org/D24184
2019-09-24 08:48:08 +00:00
inline bool X11Client::isTransient() const
KWin uses kdelibs coding style.
2011-01-30 14:34:42 +00:00
{
Port Client::transient_for handling to XCB The type of the transient_for related variables are changed to xcb_window_t. They cannot be Xcb::Window as we don't take ownership over the transient for window. Variables are renamed to m_camelCase to follow naming scheme. A wrapper for retrieving the TransientFor hint is added to the Xcb Wrappers.
2013-05-03 06:53:35 +00:00
return m_transientForId != XCB_WINDOW_NONE;
KWin uses kdelibs coding style.
2011-01-30 14:34:42 +00:00
}
branches/work/kwin_composite becomes new trunk kwin. svn path=/trunk/KDE/kdebase/workspace/; revision=659202
2007-04-29 17:35:43 +00:00
Rename Client to X11Client Summary: Currently each managed X11 client is represented with an instance of Client class, however the name of that class is very generic and the only reason why it's called that way is because historically kwin was created as an x11 window manager, so "Client" was a sensible choice. With introduction of wayland support, things had changed and therefore Client needs to be renamed to X11Client in order to better reflect what that class stands for. Renaming of Client to X11Client was agreed upon during the last KWin sprint. Test Plan: Compiles, the test suite is still green. Reviewers: #kwin, romangg Reviewed By: #kwin, romangg Subscribers: romangg, davidedmundson, kwin Tags: #kwin Differential Revision: https://phabricator.kde.org/D24184
2019-09-24 08:48:08 +00:00
inline const Group* X11Client::group() const
KWin uses kdelibs coding style.
2011-01-30 14:34:42 +00:00
{
branches/work/kwin_composite becomes new trunk kwin. svn path=/trunk/KDE/kdebase/workspace/; revision=659202
2007-04-29 17:35:43 +00:00
return in_group;
KWin uses kdelibs coding style.
2011-01-30 14:34:42 +00:00
}
branches/work/kwin_composite becomes new trunk kwin. svn path=/trunk/KDE/kdebase/workspace/; revision=659202
2007-04-29 17:35:43 +00:00
Rename Client to X11Client Summary: Currently each managed X11 client is represented with an instance of Client class, however the name of that class is very generic and the only reason why it's called that way is because historically kwin was created as an x11 window manager, so "Client" was a sensible choice. With introduction of wayland support, things had changed and therefore Client needs to be renamed to X11Client in order to better reflect what that class stands for. Renaming of Client to X11Client was agreed upon during the last KWin sprint. Test Plan: Compiles, the test suite is still green. Reviewers: #kwin, romangg Reviewed By: #kwin, romangg Subscribers: romangg, davidedmundson, kwin Tags: #kwin Differential Revision: https://phabricator.kde.org/D24184
2019-09-24 08:48:08 +00:00
inline Group* X11Client::group()
KWin uses kdelibs coding style.
2011-01-30 14:34:42 +00:00
{
branches/work/kwin_composite becomes new trunk kwin. svn path=/trunk/KDE/kdebase/workspace/; revision=659202
2007-04-29 17:35:43 +00:00
return in_group;
KWin uses kdelibs coding style.
2011-01-30 14:34:42 +00:00
}
branches/work/kwin_composite becomes new trunk kwin. svn path=/trunk/KDE/kdebase/workspace/; revision=659202
2007-04-29 17:35:43 +00:00
Remove boolean trap in AbstractClient::isShown() Check shaded state where needed.
2021-11-23 12:13:56 +00:00
inline bool X11Client::isShown() const
KWin uses kdelibs coding style.
2011-01-30 14:34:42 +00:00
{
Remove boolean trap in AbstractClient::isShown() Check shaded state where needed.
2021-11-23 12:13:56 +00:00
return !isMinimized() && !hidden;
KWin uses kdelibs coding style.
2011-01-30 14:34:42 +00:00
}
branches/work/kwin_composite becomes new trunk kwin. svn path=/trunk/KDE/kdebase/workspace/; revision=659202
2007-04-29 17:35:43 +00:00
Rename Client to X11Client Summary: Currently each managed X11 client is represented with an instance of Client class, however the name of that class is very generic and the only reason why it's called that way is because historically kwin was created as an x11 window manager, so "Client" was a sensible choice. With introduction of wayland support, things had changed and therefore Client needs to be renamed to X11Client in order to better reflect what that class stands for. Renaming of Client to X11Client was agreed upon during the last KWin sprint. Test Plan: Compiles, the test suite is still green. Reviewers: #kwin, romangg Reviewed By: #kwin, romangg Subscribers: romangg, davidedmundson, kwin Tags: #kwin Differential Revision: https://phabricator.kde.org/D24184
2019-09-24 08:48:08 +00:00
inline bool X11Client::isHiddenInternal() const
KWin uses kdelibs coding style.
2011-01-30 14:34:42 +00:00
{
Don't paint windows that have been hidden by KWin itself. svn path=/trunk/KDE/kdebase/workspace/; revision=778351
2008-02-23 13:41:53 +00:00
return hidden;
KWin uses kdelibs coding style.
2011-01-30 14:34:42 +00:00
}
Don't paint windows that have been hidden by KWin itself. svn path=/trunk/KDE/kdebase/workspace/; revision=778351
2008-02-23 13:41:53 +00:00
Rename Client to X11Client Summary: Currently each managed X11 client is represented with an instance of Client class, however the name of that class is very generic and the only reason why it's called that way is because historically kwin was created as an x11 window manager, so "Client" was a sensible choice. With introduction of wayland support, things had changed and therefore Client needs to be renamed to X11Client in order to better reflect what that class stands for. Renaming of Client to X11Client was agreed upon during the last KWin sprint. Test Plan: Compiles, the test suite is still green. Reviewers: #kwin, romangg Reviewed By: #kwin, romangg Subscribers: romangg, davidedmundson, kwin Tags: #kwin Differential Revision: https://phabricator.kde.org/D24184
2019-09-24 08:48:08 +00:00
inline MaximizeMode X11Client::maximizeMode() const
KWin uses kdelibs coding style.
2011-01-30 14:34:42 +00:00
{
branches/work/kwin_composite becomes new trunk kwin. svn path=/trunk/KDE/kdebase/workspace/; revision=659202
2007-04-29 17:35:43 +00:00
return max_mode;
KWin uses kdelibs coding style.
2011-01-30 14:34:42 +00:00
}
branches/work/kwin_composite becomes new trunk kwin. svn path=/trunk/KDE/kdebase/workspace/; revision=659202
2007-04-29 17:35:43 +00:00
Rename Client to X11Client Summary: Currently each managed X11 client is represented with an instance of Client class, however the name of that class is very generic and the only reason why it's called that way is because historically kwin was created as an x11 window manager, so "Client" was a sensible choice. With introduction of wayland support, things had changed and therefore Client needs to be renamed to X11Client in order to better reflect what that class stands for. Renaming of Client to X11Client was agreed upon during the last KWin sprint. Test Plan: Compiles, the test suite is still green. Reviewers: #kwin, romangg Reviewed By: #kwin, romangg Subscribers: romangg, davidedmundson, kwin Tags: #kwin Differential Revision: https://phabricator.kde.org/D24184
2019-09-24 08:48:08 +00:00
inline bool X11Client::isFullScreen() const
KWin uses kdelibs coding style.
2011-01-30 14:34:42 +00:00
{
Correct code style of Client fullscreen control Summary: As a preperational step for future changes obey the code styling guide in Client fullscreen functionality. No functional changes. Test Plan: Manually, autotests pass. Reviewers: #kwin, davidedmundson Reviewed By: #kwin, davidedmundson Subscribers: zzag, graesslin, kwin Tags: #kwin Maniphest Tasks: T11098 Differential Revision: https://phabricator.kde.org/D18153
2019-01-10 12:16:01 +00:00
return m_fullscreenMode != FullScreenNone;
KWin uses kdelibs coding style.
2011-01-30 14:34:42 +00:00
}
branches/work/kwin_composite becomes new trunk kwin. svn path=/trunk/KDE/kdebase/workspace/; revision=659202
2007-04-29 17:35:43 +00:00
Rename Client to X11Client Summary: Currently each managed X11 client is represented with an instance of Client class, however the name of that class is very generic and the only reason why it's called that way is because historically kwin was created as an x11 window manager, so "Client" was a sensible choice. With introduction of wayland support, things had changed and therefore Client needs to be renamed to X11Client in order to better reflect what that class stands for. Renaming of Client to X11Client was agreed upon during the last KWin sprint. Test Plan: Compiles, the test suite is still green. Reviewers: #kwin, romangg Reviewed By: #kwin, romangg Subscribers: romangg, davidedmundson, kwin Tags: #kwin Differential Revision: https://phabricator.kde.org/D24184
2019-09-24 08:48:08 +00:00
inline bool X11Client::hasNETSupport() const
KWin uses kdelibs coding style.
2011-01-30 14:34:42 +00:00
{
branches/work/kwin_composite becomes new trunk kwin. svn path=/trunk/KDE/kdebase/workspace/; revision=659202
2007-04-29 17:35:43 +00:00
return info->hasNETSupport();
KWin uses kdelibs coding style.
2011-01-30 14:34:42 +00:00
}
branches/work/kwin_composite becomes new trunk kwin. svn path=/trunk/KDE/kdebase/workspace/; revision=659202
2007-04-29 17:35:43 +00:00
Rename Client to X11Client Summary: Currently each managed X11 client is represented with an instance of Client class, however the name of that class is very generic and the only reason why it's called that way is because historically kwin was created as an x11 window manager, so "Client" was a sensible choice. With introduction of wayland support, things had changed and therefore Client needs to be renamed to X11Client in order to better reflect what that class stands for. Renaming of Client to X11Client was agreed upon during the last KWin sprint. Test Plan: Compiles, the test suite is still green. Reviewers: #kwin, romangg Reviewed By: #kwin, romangg Subscribers: romangg, davidedmundson, kwin Tags: #kwin Differential Revision: https://phabricator.kde.org/D24184
2019-09-24 08:48:08 +00:00
inline xcb_colormap_t X11Client::colormap() const
KWin uses kdelibs coding style.
2011-01-30 14:34:42 +00:00
{
Change Client's clormap to xcb_colormap_t At same time also renaming variable to follow naming scheme and have a sensible name. Also moved default value initialization into initializer list. REVIEW: 110283
2013-05-03 09:46:18 +00:00
return m_colormap;
KWin uses kdelibs coding style.
2011-01-30 14:34:42 +00:00
}
branches/work/kwin_composite becomes new trunk kwin. svn path=/trunk/KDE/kdebase/workspace/; revision=659202
2007-04-29 17:35:43 +00:00
Rename Client to X11Client Summary: Currently each managed X11 client is represented with an instance of Client class, however the name of that class is very generic and the only reason why it's called that way is because historically kwin was created as an x11 window manager, so "Client" was a sensible choice. With introduction of wayland support, things had changed and therefore Client needs to be renamed to X11Client in order to better reflect what that class stands for. Renaming of Client to X11Client was agreed upon during the last KWin sprint. Test Plan: Compiles, the test suite is still green. Reviewers: #kwin, romangg Reviewed By: #kwin, romangg Subscribers: romangg, davidedmundson, kwin Tags: #kwin Differential Revision: https://phabricator.kde.org/D24184
2019-09-24 08:48:08 +00:00
inline int X11Client::sessionStackingOrder() const
KWin uses kdelibs coding style.
2011-01-30 14:34:42 +00:00
{
branches/work/kwin_composite becomes new trunk kwin. svn path=/trunk/KDE/kdebase/workspace/; revision=659202
2007-04-29 17:35:43 +00:00
return sm_stacking_order;
KWin uses kdelibs coding style.
2011-01-30 14:34:42 +00:00
}
branches/work/kwin_composite becomes new trunk kwin. svn path=/trunk/KDE/kdebase/workspace/; revision=659202
2007-04-29 17:35:43 +00:00
Rename Client to X11Client Summary: Currently each managed X11 client is represented with an instance of Client class, however the name of that class is very generic and the only reason why it's called that way is because historically kwin was created as an x11 window manager, so "Client" was a sensible choice. With introduction of wayland support, things had changed and therefore Client needs to be renamed to X11Client in order to better reflect what that class stands for. Renaming of Client to X11Client was agreed upon during the last KWin sprint. Test Plan: Compiles, the test suite is still green. Reviewers: #kwin, romangg Reviewed By: #kwin, romangg Subscribers: romangg, davidedmundson, kwin Tags: #kwin Differential Revision: https://phabricator.kde.org/D24184
2019-09-24 08:48:08 +00:00
inline bool X11Client::isManaged() const
KWin uses kdelibs coding style.
2011-01-30 14:34:42 +00:00
{
substitute mapping_state == Withdrawn by m_managed as the flamewar pointed out, resetShowingDesktop invalidly keeps hidden windows the reason is that there're several updateVisiblity calls (notably one from the compositor) which break the showingDesktop state as a side effect (before ::manage() does it's thing) Since they also invalidate the Withdrawn mapping state, that will fail as isManaged() test (it's also invalidly used by the compositor to set up the decoration, isManaged() used to be true because of the updateVisibility() call before) since the result is never Withdrawn CCBUG: 299655 REVIEW: 105303
2012-06-19 21:12:37 +00:00
return m_managed;
KWin uses kdelibs coding style.
2011-01-30 14:34:42 +00:00
}
branches/work/kwin_composite becomes new trunk kwin. svn path=/trunk/KDE/kdebase/workspace/; revision=659202
2007-04-29 17:35:43 +00:00
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
inline void X11Client::resizeWithChecks(const QSize &s)
Add resizeWithChecks to AbstractClient The virtual method does not take the xcb_gravity_t - that's only added in a variant in Client.
2015-05-27 09:48:33 +00:00
{
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
resizeWithChecks(s.width(), s.height(), XCB_GRAVITY_BIT_FORGET);
Add resizeWithChecks to AbstractClient The virtual method does not take the xcb_gravity_t - that's only added in a variant in Client.
2015-05-27 09:48:33 +00:00
}
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
inline void X11Client::resizeWithChecks(const QSize& s, xcb_gravity_t gravity)
KWin uses kdelibs coding style.
2011-01-30 14:34:42 +00:00
{
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
resizeWithChecks(s.width(), s.height(), gravity);
KWin uses kdelibs coding style.
2011-01-30 14:34:42 +00:00
}
branches/work/kwin_composite becomes new trunk kwin. svn path=/trunk/KDE/kdebase/workspace/; revision=659202
2007-04-29 17:35:43 +00:00
Rename Client to X11Client Summary: Currently each managed X11 client is represented with an instance of Client class, however the name of that class is very generic and the only reason why it's called that way is because historically kwin was created as an x11 window manager, so "Client" was a sensible choice. With introduction of wayland support, things had changed and therefore Client needs to be renamed to X11Client in order to better reflect what that class stands for. Renaming of Client to X11Client was agreed upon during the last KWin sprint. Test Plan: Compiles, the test suite is still green. Reviewers: #kwin, romangg Reviewed By: #kwin, romangg Subscribers: romangg, davidedmundson, kwin Tags: #kwin Differential Revision: https://phabricator.kde.org/D24184
2019-09-24 08:48:08 +00:00
inline bool X11Client::hasUserTimeSupport() const
KWin uses kdelibs coding style.
2011-01-30 14:34:42 +00:00
{
branches/work/kwin_composite becomes new trunk kwin. svn path=/trunk/KDE/kdebase/workspace/; revision=659202
2007-04-29 17:35:43 +00:00
return info->userTime() != -1U;
KWin uses kdelibs coding style.
2011-01-30 14:34:42 +00:00
}
SVN_SILENT Standardize coding style on client.* and workspace.* svn path=/trunk/KDE/kdebase/workspace/; revision=898612
2008-12-18 13:50:57 +00:00
Rename Client to X11Client Summary: Currently each managed X11 client is represented with an instance of Client class, however the name of that class is very generic and the only reason why it's called that way is because historically kwin was created as an x11 window manager, so "Client" was a sensible choice. With introduction of wayland support, things had changed and therefore Client needs to be renamed to X11Client in order to better reflect what that class stands for. Renaming of Client to X11Client was agreed upon during the last KWin sprint. Test Plan: Compiles, the test suite is still green. Reviewers: #kwin, romangg Reviewed By: #kwin, romangg Subscribers: romangg, davidedmundson, kwin Tags: #kwin Differential Revision: https://phabricator.kde.org/D24184
2019-09-24 08:48:08 +00:00
inline xcb_window_t X11Client::moveResizeGrabWindow() const
KWin uses kdelibs coding style.
2011-01-30 14:34:42 +00:00
{
Port Client's move resize grab window to XCB Using Xcb::Window to wrap this helper window and port all the used XLib calls to XCB. Also renaming the variable to m_ and camel case to follow general naming scheme.
2013-05-02 17:04:43 +00:00
return m_moveResizeGrabWindow;
KWin uses kdelibs coding style.
2011-01-30 14:34:42 +00:00
}
branches/work/kwin_composite becomes new trunk kwin. svn path=/trunk/KDE/kdebase/workspace/; revision=659202
2007-04-29 17:35:43 +00:00
Rename Client to X11Client Summary: Currently each managed X11 client is represented with an instance of Client class, however the name of that class is very generic and the only reason why it's called that way is because historically kwin was created as an x11 window manager, so "Client" was a sensible choice. With introduction of wayland support, things had changed and therefore Client needs to be renamed to X11Client in order to better reflect what that class stands for. Renaming of Client to X11Client was agreed upon during the last KWin sprint. Test Plan: Compiles, the test suite is still green. Reviewers: #kwin, romangg Reviewed By: #kwin, romangg Subscribers: romangg, davidedmundson, kwin Tags: #kwin Differential Revision: https://phabricator.kde.org/D24184
2019-09-24 08:48:08 +00:00
inline bool X11Client::hiddenPreview() const
KWin uses kdelibs coding style.
2011-01-30 14:34:42 +00:00
{
Rework handling of mapping and unmapping windows, in particular: - the NormalState/IconicState things in ICCCM need to match exactly the real mapping state, so ensure that, no matter how superfluous that is - extend the option for having live window previews either for all windows or for only all shown windows (default) FEATURE: 163385 svn path=/trunk/KDE/kdebase/workspace/; revision=845772
2008-08-12 11:02:58 +00:00
return mapping_state == Kept;
KWin uses kdelibs coding style.
2011-01-30 14:34:42 +00:00
}
Support for having previews even for unmapped windows - they're actually kept mapped, so that they still have the backing pixmap. Plus some small tricks to prevent such windows from interfering. Only two basic modes are implemented right now. svn path=/trunk/KDE/kdebase/workspace/; revision=683156
2007-07-04 09:51:10 +00:00
branches/work/kwin_composite becomes new trunk kwin. svn path=/trunk/KDE/kdebase/workspace/; revision=659202
2007-04-29 17:35:43 +00:00
} // namespace
Rename Client to X11Client Summary: Currently each managed X11 client is represented with an instance of Client class, however the name of that class is very generic and the only reason why it's called that way is because historically kwin was created as an x11 window manager, so "Client" was a sensible choice. With introduction of wayland support, things had changed and therefore Client needs to be renamed to X11Client in order to better reflect what that class stands for. Renaming of Client to X11Client was agreed upon during the last KWin sprint. Test Plan: Compiles, the test suite is still green. Reviewers: #kwin, romangg Reviewed By: #kwin, romangg Subscribers: romangg, davidedmundson, kwin Tags: #kwin Differential Revision: https://phabricator.kde.org/D24184
2019-09-24 08:48:08 +00:00
Q_DECLARE_METATYPE(KWin::X11Client *)
Q_DECLARE_METATYPE(QList<KWin::X11Client *>)
Reference in a new issue Copy permalink