vitalif
/
kwin
1
0
Fork 0
Code Issues Pull Requests Projects Releases Wiki Activity
kwin/decorations/decoratedclient.h

126 lines
4.0 KiB
C
Raw Normal View History

Initial import of support for new KDecoration2 based decorations NOTE: this is not working completely yet, lots of code is still ifdefed other parts are still broken. The main difference for the new decoration API is that it is neither QWidget nor QWindow based. It's just a QObject which processes input events and has a paint method to render the decoration. This means all the workarounds for the QWidget interception are removed. Also the paint redirector is removed. Instead each compositor has now its own renderer which can be optimized for the specific case. E.g. the OpenGL compositor renders to a scratch image which gets copied into the combined texture, the XRender compositor copies into the XPixmaps. Input events are also changed. The events are composed into QMouseEvents and passed through the decoration, which might accept them. If they are not accpted we assume that it's a press on the decoration area allowing us to resize/move the window. Input events are not completely working yet, e.g. wheel events are not yet processed and double click on deco is not yet working. Overall KDecoration2 is way more stateful and KWin core needs more adjustments for it. E.g. borders are allowed to be disabled at any time.
2014-07-22 15:11:19 +04:00
/********************************************************************
KWin - the KDE window manager
This file is part of the KDE project.
Copyright (C) 2014 Martin Gräßlin <mgraesslin@kde.org>
This program is free software; you can redistribute it and/or modify
it under the terms of the GNU General Public License as published by
the Free Software Foundation; either version 2 of the License, or
(at your option) any later version.
This program is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
GNU General Public License for more details.
You should have received a copy of the GNU General Public License
along with this program. If not, see <http://www.gnu.org/licenses/>.
*********************************************************************/
#ifndef KWIN_DECORATED_CLIENT_H
#define KWIN_DECORATED_CLIENT_H
Delay maximize button click to next event cycle Summary: The delay to next cycle dance is needed for Aurorae. Maximizing a window can result in the decoration being destroyed, in which case QtQuick can trigger a crash. A test case is added to simulate the situation and ensure that maximize still works also after the change. BUG: 362772 FIXED-IN: 5.6.5 Reviewers: #plasma Subscribers: plasma-devel Projects: #plasma Differential Revision: https://phabricator.kde.org/D1586
2016-05-11 14:33:03 +03:00
#include "options.h"
Initial import of support for new KDecoration2 based decorations NOTE: this is not working completely yet, lots of code is still ifdefed other parts are still broken. The main difference for the new decoration API is that it is neither QWidget nor QWindow based. It's just a QObject which processes input events and has a paint method to render the decoration. This means all the workarounds for the QWidget interception are removed. Also the paint redirector is removed. Instead each compositor has now its own renderer which can be optimized for the specific case. E.g. the OpenGL compositor renders to a scratch image which gets copied into the combined texture, the XRender compositor copies into the XPixmaps. Input events are also changed. The events are composed into QMouseEvents and passed through the decoration, which might accept them. If they are not accpted we assume that it's a press on the decoration area allowing us to resize/move the window. Input events are not completely working yet, e.g. wheel events are not yet processed and double click on deco is not yet working. Overall KDecoration2 is way more stateful and KWin core needs more adjustments for it. E.g. borders are allowed to be disabled at any time.
2014-07-22 15:11:19 +04:00
#include <KDecoration2/Private/DecoratedClientPrivate>
Improve tooltips behavior Summary: Window buttons tooltips used to appear on hover immediately. As the result, they mostly appeared when not needed e.g. when user was closing a window, or when the mouse pointer slightly touched a button while being moved elsewhere. This commit changes the tooltips behavior to WakeUp-FallAsleep approach used by Widgets. BUG: 392765 FIXED-IN: 5.13 Reviewers: #kwin, graesslin, broulik, #plasma Reviewed By: #kwin, graesslin, #plasma Subscribers: zzag, broulik, kwin, hein Tags: #kwin Differential Revision: https://phabricator.kde.org/D12404
2018-04-22 20:40:54 +03:00
#include <QDeadlineTimer>
Initial import of support for new KDecoration2 based decorations NOTE: this is not working completely yet, lots of code is still ifdefed other parts are still broken. The main difference for the new decoration API is that it is neither QWidget nor QWindow based. It's just a QObject which processes input events and has a paint method to render the decoration. This means all the workarounds for the QWidget interception are removed. Also the paint redirector is removed. Instead each compositor has now its own renderer which can be optimized for the specific case. E.g. the OpenGL compositor renders to a scratch image which gets copied into the combined texture, the XRender compositor copies into the XPixmaps. Input events are also changed. The events are composed into QMouseEvents and passed through the decoration, which might accept them. If they are not accpted we assume that it's a press on the decoration area allowing us to resize/move the window. Input events are not completely working yet, e.g. wheel events are not yet processed and double click on deco is not yet working. Overall KDecoration2 is way more stateful and KWin core needs more adjustments for it. E.g. borders are allowed to be disabled at any time.
2014-07-22 15:11:19 +04:00
#include <QObject>
Improve tooltips behavior Summary: Window buttons tooltips used to appear on hover immediately. As the result, they mostly appeared when not needed e.g. when user was closing a window, or when the mouse pointer slightly touched a button while being moved elsewhere. This commit changes the tooltips behavior to WakeUp-FallAsleep approach used by Widgets. BUG: 392765 FIXED-IN: 5.13 Reviewers: #kwin, graesslin, broulik, #plasma Reviewed By: #kwin, graesslin, #plasma Subscribers: zzag, broulik, kwin, hein Tags: #kwin Differential Revision: https://phabricator.kde.org/D12404
2018-04-22 20:40:54 +03:00
#include <QTimer>
Initial import of support for new KDecoration2 based decorations NOTE: this is not working completely yet, lots of code is still ifdefed other parts are still broken. The main difference for the new decoration API is that it is neither QWidget nor QWindow based. It's just a QObject which processes input events and has a paint method to render the decoration. This means all the workarounds for the QWidget interception are removed. Also the paint redirector is removed. Instead each compositor has now its own renderer which can be optimized for the specific case. E.g. the OpenGL compositor renders to a scratch image which gets copied into the combined texture, the XRender compositor copies into the XPixmaps. Input events are also changed. The events are composed into QMouseEvents and passed through the decoration, which might accept them. If they are not accpted we assume that it's a press on the decoration area allowing us to resize/move the window. Input events are not completely working yet, e.g. wheel events are not yet processed and double click on deco is not yet working. Overall KDecoration2 is way more stateful and KWin core needs more adjustments for it. E.g. borders are allowed to be disabled at any time.
2014-07-22 15:11:19 +04:00
namespace KWin
{
DecoratedClientImpl::client returns AbstractClient* instead of Client*
2015-12-03 19:12:25 +03:00
class AbstractClient;
Initial import of support for new KDecoration2 based decorations NOTE: this is not working completely yet, lots of code is still ifdefed other parts are still broken. The main difference for the new decoration API is that it is neither QWidget nor QWindow based. It's just a QObject which processes input events and has a paint method to render the decoration. This means all the workarounds for the QWidget interception are removed. Also the paint redirector is removed. Instead each compositor has now its own renderer which can be optimized for the specific case. E.g. the OpenGL compositor renders to a scratch image which gets copied into the combined texture, the XRender compositor copies into the XPixmaps. Input events are also changed. The events are composed into QMouseEvents and passed through the decoration, which might accept them. If they are not accpted we assume that it's a press on the decoration area allowing us to resize/move the window. Input events are not completely working yet, e.g. wheel events are not yet processed and double click on deco is not yet working. Overall KDecoration2 is way more stateful and KWin core needs more adjustments for it. E.g. borders are allowed to be disabled at any time.
2014-07-22 15:11:19 +04:00
namespace Decoration
{
class Renderer;
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 12:21:03 +03:00
class DecoratedClientImpl : public QObject, public KDecoration2::ApplicationMenuEnabledDecoratedClientPrivate
Initial import of support for new KDecoration2 based decorations NOTE: this is not working completely yet, lots of code is still ifdefed other parts are still broken. The main difference for the new decoration API is that it is neither QWidget nor QWindow based. It's just a QObject which processes input events and has a paint method to render the decoration. This means all the workarounds for the QWidget interception are removed. Also the paint redirector is removed. Instead each compositor has now its own renderer which can be optimized for the specific case. E.g. the OpenGL compositor renders to a scratch image which gets copied into the combined texture, the XRender compositor copies into the XPixmaps. Input events are also changed. The events are composed into QMouseEvents and passed through the decoration, which might accept them. If they are not accpted we assume that it's a press on the decoration area allowing us to resize/move the window. Input events are not completely working yet, e.g. wheel events are not yet processed and double click on deco is not yet working. Overall KDecoration2 is way more stateful and KWin core needs more adjustments for it. E.g. borders are allowed to be disabled at any time.
2014-07-22 15:11:19 +04:00
{
Q_OBJECT
public:
DecoratedClientImpl switches from operating on Client to AbstractClient
2015-12-03 19:29:06 +03:00
explicit DecoratedClientImpl(AbstractClient *client, KDecoration2::DecoratedClient *decoratedClient, KDecoration2::Decoration *decoration);
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 19:52:26 +03:00
~DecoratedClientImpl() override;
Initial import of support for new KDecoration2 based decorations NOTE: this is not working completely yet, lots of code is still ifdefed other parts are still broken. The main difference for the new decoration API is that it is neither QWidget nor QWindow based. It's just a QObject which processes input events and has a paint method to render the decoration. This means all the workarounds for the QWidget interception are removed. Also the paint redirector is removed. Instead each compositor has now its own renderer which can be optimized for the specific case. E.g. the OpenGL compositor renders to a scratch image which gets copied into the combined texture, the XRender compositor copies into the XPixmaps. Input events are also changed. The events are composed into QMouseEvents and passed through the decoration, which might accept them. If they are not accpted we assume that it's a press on the decoration area allowing us to resize/move the window. Input events are not completely working yet, e.g. wheel events are not yet processed and double click on deco is not yet working. Overall KDecoration2 is way more stateful and KWin core needs more adjustments for it. E.g. borders are allowed to be disabled at any time.
2014-07-22 15:11:19 +04:00
QString caption() const override;
WId decorationId() const override;
int desktop() const override;
int height() const override;
QIcon icon() const override;
bool isActive() const override;
bool isCloseable() const override;
bool isKeepAbove() const override;
bool isKeepBelow() const override;
Adjust DecoratedClientImpl to changes in DecoratedClientPrivate
2014-10-23 12:56:43 +04:00
bool isMaximizeable() const override;
Initial import of support for new KDecoration2 based decorations NOTE: this is not working completely yet, lots of code is still ifdefed other parts are still broken. The main difference for the new decoration API is that it is neither QWidget nor QWindow based. It's just a QObject which processes input events and has a paint method to render the decoration. This means all the workarounds for the QWidget interception are removed. Also the paint redirector is removed. Instead each compositor has now its own renderer which can be optimized for the specific case. E.g. the OpenGL compositor renders to a scratch image which gets copied into the combined texture, the XRender compositor copies into the XPixmaps. Input events are also changed. The events are composed into QMouseEvents and passed through the decoration, which might accept them. If they are not accpted we assume that it's a press on the decoration area allowing us to resize/move the window. Input events are not completely working yet, e.g. wheel events are not yet processed and double click on deco is not yet working. Overall KDecoration2 is way more stateful and KWin core needs more adjustments for it. E.g. borders are allowed to be disabled at any time.
2014-07-22 15:11:19 +04:00
bool isMaximized() const override;
bool isMaximizedHorizontally() const override;
bool isMaximizedVertically() const override;
Adjust DecoratedClientImpl to changes in DecoratedClientPrivate
2014-10-23 12:56:43 +04:00
bool isMinimizeable() const override;
Initial import of support for new KDecoration2 based decorations NOTE: this is not working completely yet, lots of code is still ifdefed other parts are still broken. The main difference for the new decoration API is that it is neither QWidget nor QWindow based. It's just a QObject which processes input events and has a paint method to render the decoration. This means all the workarounds for the QWidget interception are removed. Also the paint redirector is removed. Instead each compositor has now its own renderer which can be optimized for the specific case. E.g. the OpenGL compositor renders to a scratch image which gets copied into the combined texture, the XRender compositor copies into the XPixmaps. Input events are also changed. The events are composed into QMouseEvents and passed through the decoration, which might accept them. If they are not accpted we assume that it's a press on the decoration area allowing us to resize/move the window. Input events are not completely working yet, e.g. wheel events are not yet processed and double click on deco is not yet working. Overall KDecoration2 is way more stateful and KWin core needs more adjustments for it. E.g. borders are allowed to be disabled at any time.
2014-07-22 15:11:19 +04:00
bool isModal() const override;
Adjust DecoratedClientImpl to changes in DecoratedClientPrivate
2014-10-23 12:56:43 +04:00
bool isMoveable() const override;
Initial import of support for new KDecoration2 based decorations NOTE: this is not working completely yet, lots of code is still ifdefed other parts are still broken. The main difference for the new decoration API is that it is neither QWidget nor QWindow based. It's just a QObject which processes input events and has a paint method to render the decoration. This means all the workarounds for the QWidget interception are removed. Also the paint redirector is removed. Instead each compositor has now its own renderer which can be optimized for the specific case. E.g. the OpenGL compositor renders to a scratch image which gets copied into the combined texture, the XRender compositor copies into the XPixmaps. Input events are also changed. The events are composed into QMouseEvents and passed through the decoration, which might accept them. If they are not accpted we assume that it's a press on the decoration area allowing us to resize/move the window. Input events are not completely working yet, e.g. wheel events are not yet processed and double click on deco is not yet working. Overall KDecoration2 is way more stateful and KWin core needs more adjustments for it. E.g. borders are allowed to be disabled at any time.
2014-07-22 15:11:19 +04:00
bool isOnAllDesktops() const override;
Adjust DecoratedClientImpl to changes in DecoratedClientPrivate
2014-10-23 12:56:43 +04:00
bool isResizeable() const override;
Initial import of support for new KDecoration2 based decorations NOTE: this is not working completely yet, lots of code is still ifdefed other parts are still broken. The main difference for the new decoration API is that it is neither QWidget nor QWindow based. It's just a QObject which processes input events and has a paint method to render the decoration. This means all the workarounds for the QWidget interception are removed. Also the paint redirector is removed. Instead each compositor has now its own renderer which can be optimized for the specific case. E.g. the OpenGL compositor renders to a scratch image which gets copied into the combined texture, the XRender compositor copies into the XPixmaps. Input events are also changed. The events are composed into QMouseEvents and passed through the decoration, which might accept them. If they are not accpted we assume that it's a press on the decoration area allowing us to resize/move the window. Input events are not completely working yet, e.g. wheel events are not yet processed and double click on deco is not yet working. Overall KDecoration2 is way more stateful and KWin core needs more adjustments for it. E.g. borders are allowed to be disabled at any time.
2014-07-22 15:11:19 +04:00
bool isShadeable() const override;
bool isShaded() const override;
QPalette palette() const override;
Adapt to KDecoration API changes Adapt to API changes introduced by b62e8888cd39301e00ad98dfe791fa66676408fb. It adds DecoratedClient::color(group, role) for getting colors that are not included in QPalette. Breeze used to read these colors from kdeglobals, breaking per window color schemes. KWin now handles reading these colors along with QPalette loading with DecorationPalette. REVIEW: 122883
2015-03-31 16:26:42 +03:00
QColor color(KDecoration2::ColorGroup group, KDecoration2::ColorRole role) const override;
Initial import of support for new KDecoration2 based decorations NOTE: this is not working completely yet, lots of code is still ifdefed other parts are still broken. The main difference for the new decoration API is that it is neither QWidget nor QWindow based. It's just a QObject which processes input events and has a paint method to render the decoration. This means all the workarounds for the QWidget interception are removed. Also the paint redirector is removed. Instead each compositor has now its own renderer which can be optimized for the specific case. E.g. the OpenGL compositor renders to a scratch image which gets copied into the combined texture, the XRender compositor copies into the XPixmaps. Input events are also changed. The events are composed into QMouseEvents and passed through the decoration, which might accept them. If they are not accpted we assume that it's a press on the decoration area allowing us to resize/move the window. Input events are not completely working yet, e.g. wheel events are not yet processed and double click on deco is not yet working. Overall KDecoration2 is way more stateful and KWin core needs more adjustments for it. E.g. borders are allowed to be disabled at any time.
2014-07-22 15:11:19 +04:00
bool providesContextHelp() const override;
[decoration] Implement the size property Summary: See D26937 Reviewers: #kwin, davidedmundson Reviewed By: #kwin, davidedmundson Subscribers: kwin Tags: #kwin Differential Revision: https://phabricator.kde.org/D26939
2020-01-27 16:16:02 +03:00
QSize size() const override;
Initial import of support for new KDecoration2 based decorations NOTE: this is not working completely yet, lots of code is still ifdefed other parts are still broken. The main difference for the new decoration API is that it is neither QWidget nor QWindow based. It's just a QObject which processes input events and has a paint method to render the decoration. This means all the workarounds for the QWidget interception are removed. Also the paint redirector is removed. Instead each compositor has now its own renderer which can be optimized for the specific case. E.g. the OpenGL compositor renders to a scratch image which gets copied into the combined texture, the XRender compositor copies into the XPixmaps. Input events are also changed. The events are composed into QMouseEvents and passed through the decoration, which might accept them. If they are not accpted we assume that it's a press on the decoration area allowing us to resize/move the window. Input events are not completely working yet, e.g. wheel events are not yet processed and double click on deco is not yet working. Overall KDecoration2 is way more stateful and KWin core needs more adjustments for it. E.g. borders are allowed to be disabled at any time.
2014-07-22 15:11:19 +04:00
int width() const override;
WId windowId() const override;
Rename DecoratedClient::borderingScreenEdges to adjacentScreenEdges
2014-11-11 16:33:31 +03:00
Qt::Edges adjacentScreenEdges() const override;
Implement borderingScreenEdges for the DecoratedClientImpl Uses the QuickTileMode of the Client to indicate which borders to remove. This could be extended to be in general when a window borders the screen edge and not just for quick tile mode.
2014-07-25 13:20:34 +04: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 12:21:03 +03:00
bool hasApplicationMenu() const override;
bool isApplicationMenuActive() const override;
KWin: tooltips Summary: BUG: 383040 KDecoration part of the patch: https://phabricator.kde.org/D7246 Reviewers: graesslin Reviewed By: graesslin Subscribers: cfeck, graesslin, luebking, broulik, kwin, #kwin Tags: #kwin Differential Revision: https://phabricator.kde.org/D9294
2018-01-18 21:59:17 +03:00
void requestShowToolTip(const QString &text) override;
void requestHideToolTip() override;
Initial import of support for new KDecoration2 based decorations NOTE: this is not working completely yet, lots of code is still ifdefed other parts are still broken. The main difference for the new decoration API is that it is neither QWidget nor QWindow based. It's just a QObject which processes input events and has a paint method to render the decoration. This means all the workarounds for the QWidget interception are removed. Also the paint redirector is removed. Instead each compositor has now its own renderer which can be optimized for the specific case. E.g. the OpenGL compositor renders to a scratch image which gets copied into the combined texture, the XRender compositor copies into the XPixmaps. Input events are also changed. The events are composed into QMouseEvents and passed through the decoration, which might accept them. If they are not accpted we assume that it's a press on the decoration area allowing us to resize/move the window. Input events are not completely working yet, e.g. wheel events are not yet processed and double click on deco is not yet working. Overall KDecoration2 is way more stateful and KWin core needs more adjustments for it. E.g. borders are allowed to be disabled at any time.
2014-07-22 15:11:19 +04:00
void requestClose() override;
void requestContextHelp() override;
s/requestMaximize/requestToggleMaximization/g
2014-11-11 11:53:54 +03:00
void requestToggleMaximization(Qt::MouseButtons buttons) override;
Initial import of support for new KDecoration2 based decorations NOTE: this is not working completely yet, lots of code is still ifdefed other parts are still broken. The main difference for the new decoration API is that it is neither QWidget nor QWindow based. It's just a QObject which processes input events and has a paint method to render the decoration. This means all the workarounds for the QWidget interception are removed. Also the paint redirector is removed. Instead each compositor has now its own renderer which can be optimized for the specific case. E.g. the OpenGL compositor renders to a scratch image which gets copied into the combined texture, the XRender compositor copies into the XPixmaps. Input events are also changed. The events are composed into QMouseEvents and passed through the decoration, which might accept them. If they are not accpted we assume that it's a press on the decoration area allowing us to resize/move the window. Input events are not completely working yet, e.g. wheel events are not yet processed and double click on deco is not yet working. Overall KDecoration2 is way more stateful and KWin core needs more adjustments for it. E.g. borders are allowed to be disabled at any time.
2014-07-22 15:11:19 +04:00
void requestMinimize() override;
void requestShowWindowMenu() override;
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 12:21:03 +03:00
void requestShowApplicationMenu(const QRect &rect, int actionId) override;
Initial import of support for new KDecoration2 based decorations NOTE: this is not working completely yet, lots of code is still ifdefed other parts are still broken. The main difference for the new decoration API is that it is neither QWidget nor QWindow based. It's just a QObject which processes input events and has a paint method to render the decoration. This means all the workarounds for the QWidget interception are removed. Also the paint redirector is removed. Instead each compositor has now its own renderer which can be optimized for the specific case. E.g. the OpenGL compositor renders to a scratch image which gets copied into the combined texture, the XRender compositor copies into the XPixmaps. Input events are also changed. The events are composed into QMouseEvents and passed through the decoration, which might accept them. If they are not accpted we assume that it's a press on the decoration area allowing us to resize/move the window. Input events are not completely working yet, e.g. wheel events are not yet processed and double click on deco is not yet working. Overall KDecoration2 is way more stateful and KWin core needs more adjustments for it. E.g. borders are allowed to be disabled at any time.
2014-07-22 15:11:19 +04:00
void requestToggleKeepAbove() override;
void requestToggleKeepBelow() override;
void requestToggleOnAllDesktops() override;
void requestToggleShade() override;
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 19:52:26 +03:00
void showApplicationMenu(int actionId) override;
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 12:21:03 +03:00
DecoratedClientImpl::client returns AbstractClient* instead of Client*
2015-12-03 19:12:25 +03:00
AbstractClient *client() {
Initial import of support for new KDecoration2 based decorations NOTE: this is not working completely yet, lots of code is still ifdefed other parts are still broken. The main difference for the new decoration API is that it is neither QWidget nor QWindow based. It's just a QObject which processes input events and has a paint method to render the decoration. This means all the workarounds for the QWidget interception are removed. Also the paint redirector is removed. Instead each compositor has now its own renderer which can be optimized for the specific case. E.g. the OpenGL compositor renders to a scratch image which gets copied into the combined texture, the XRender compositor copies into the XPixmaps. Input events are also changed. The events are composed into QMouseEvents and passed through the decoration, which might accept them. If they are not accpted we assume that it's a press on the decoration area allowing us to resize/move the window. Input events are not completely working yet, e.g. wheel events are not yet processed and double click on deco is not yet working. Overall KDecoration2 is way more stateful and KWin core needs more adjustments for it. E.g. borders are allowed to be disabled at any time.
2014-07-22 15:11:19 +04:00
return m_client;
}
Renderer *renderer() {
return m_renderer;
}
KDecoration2::DecoratedClient *decoratedClient() {
return KDecoration2::DecoratedClientPrivate::client();
}
emit shadeChanged before calculating unshaded size Otherwise the old (shaded) border sizes will be invoked, causing a shrinkage of the window BUG: 357669 FIXED-IN: 5.6 REVIEW: 126671
2016-01-08 01:12:40 +03:00
void signalShadeChange();
Delay maximize button click to next event cycle Summary: The delay to next cycle dance is needed for Aurorae. Maximizing a window can result in the decoration being destroyed, in which case QtQuick can trigger a crash. A test case is added to simulate the situation and ensure that maximize still works also after the change. BUG: 362772 FIXED-IN: 5.6.5 Reviewers: #plasma Subscribers: plasma-devel Projects: #plasma Differential Revision: https://phabricator.kde.org/D1586
2016-05-11 14:33:03 +03:00
private Q_SLOTS:
void delayedRequestToggleMaximization(Options::WindowOperation operation);
Initial import of support for new KDecoration2 based decorations NOTE: this is not working completely yet, lots of code is still ifdefed other parts are still broken. The main difference for the new decoration API is that it is neither QWidget nor QWindow based. It's just a QObject which processes input events and has a paint method to render the decoration. This means all the workarounds for the QWidget interception are removed. Also the paint redirector is removed. Instead each compositor has now its own renderer which can be optimized for the specific case. E.g. the OpenGL compositor renders to a scratch image which gets copied into the combined texture, the XRender compositor copies into the XPixmaps. Input events are also changed. The events are composed into QMouseEvents and passed through the decoration, which might accept them. If they are not accpted we assume that it's a press on the decoration area allowing us to resize/move the window. Input events are not completely working yet, e.g. wheel events are not yet processed and double click on deco is not yet working. Overall KDecoration2 is way more stateful and KWin core needs more adjustments for it. E.g. borders are allowed to be disabled at any time.
2014-07-22 15:11:19 +04:00
private:
void createRenderer();
Don't destroy DecorationRenderer in setup/finish compositing Summary: Currently, KWin/Wayland crashes when the compositor is reinitialized. The reason for that is ShellClient's DecorationRenderer gets destroyed when the scene is already gone, thus there is no current OpenGL context. Client works around that issue by destroying scene-specific DecorationRender in finishCompositing. Such a workaround could be applied to ShellClient as well, but it would make code more confusing because DecoratedClientImpl also tries to destroy DecorationRenderer. A better approach would be to notify DecoratedClientImpl that compositing is about to be finished, so it can destroy the decoration renderer when the scene is still alive. This not only fixes the previously mentioned issue in ShellClient, but also makes code a little bit tidier. Test Plan: Start Plasma on Wayland session, change any compositor settings (e.g. animation speed). Reviewers: #kwin, davidedmundson Reviewed By: #kwin, davidedmundson Subscribers: davidedmundson, kwin Tags: #kwin Differential Revision: https://phabricator.kde.org/D18921
2019-02-20 16:09:37 +03:00
void destroyRenderer();
DecoratedClientImpl::client returns AbstractClient* instead of Client*
2015-12-03 19:12:25 +03:00
AbstractClient *m_client;
Cache the clientSize in DecoratedClientImpl Summary: So far whenever the window geometry changed the widthChanged and heightChanged signals were emitted even if they did not change. E.g. while moving a window this resulted in the signal being emitted after every step, although from decoration point of view nothing changed. The decoration performed costly tasks like re-layout the window buttons. With this change the client size is cached and the widthChanged signal is only emitted if the width actually changed. Same for heightChanged. This results in the decoration only re-layouting the buttons if the window is resized horizontally. All other geometry changes no longer result in a re-layout. Reviewers: #kwin, #plasma Subscribers: kwin Tags: #kwin Differential Revision: https://phabricator.kde.org/D2389
2016-08-10 11:48:55 +03:00
QSize m_clientSize;
Initial import of support for new KDecoration2 based decorations NOTE: this is not working completely yet, lots of code is still ifdefed other parts are still broken. The main difference for the new decoration API is that it is neither QWidget nor QWindow based. It's just a QObject which processes input events and has a paint method to render the decoration. This means all the workarounds for the QWidget interception are removed. Also the paint redirector is removed. Instead each compositor has now its own renderer which can be optimized for the specific case. E.g. the OpenGL compositor renders to a scratch image which gets copied into the combined texture, the XRender compositor copies into the XPixmaps. Input events are also changed. The events are composed into QMouseEvents and passed through the decoration, which might accept them. If they are not accpted we assume that it's a press on the decoration area allowing us to resize/move the window. Input events are not completely working yet, e.g. wheel events are not yet processed and double click on deco is not yet working. Overall KDecoration2 is way more stateful and KWin core needs more adjustments for it. E.g. borders are allowed to be disabled at any time.
2014-07-22 15:11:19 +04:00
Renderer *m_renderer;
[decorations] Don't recreate Renderer once the Compositor is destroyed If we get a compositingToggled because the Compositor is going down we don't need to recreate the Renderer as KWin as a whole is going down. Thus we disconnect the compositingToggled connection when the Compositor is about to be destroyed.
2016-05-23 10:28:27 +03:00
QMetaObject::Connection m_compositorToggledConnection;
Improve tooltips behavior Summary: Window buttons tooltips used to appear on hover immediately. As the result, they mostly appeared when not needed e.g. when user was closing a window, or when the mouse pointer slightly touched a button while being moved elsewhere. This commit changes the tooltips behavior to WakeUp-FallAsleep approach used by Widgets. BUG: 392765 FIXED-IN: 5.13 Reviewers: #kwin, graesslin, broulik, #plasma Reviewed By: #kwin, graesslin, #plasma Subscribers: zzag, broulik, kwin, hein Tags: #kwin Differential Revision: https://phabricator.kde.org/D12404
2018-04-22 20:40:54 +03:00
QString m_toolTipText;
QTimer m_toolTipWakeUp;
QDeadlineTimer m_toolTipFallAsleep;
Hide decoration tooltip when the decoration gets destroyed Summary: BUG: 394977 FIXED-IN: 5.13.1 Test Plan: Manual testing Reviewers: #kwin, #plasma Subscribers: kwin Tags: #kwin Differential Revision: https://phabricator.kde.org/D13299
2018-06-03 14:29:36 +03:00
bool m_toolTipShowing = false;
Initial import of support for new KDecoration2 based decorations NOTE: this is not working completely yet, lots of code is still ifdefed other parts are still broken. The main difference for the new decoration API is that it is neither QWidget nor QWindow based. It's just a QObject which processes input events and has a paint method to render the decoration. This means all the workarounds for the QWidget interception are removed. Also the paint redirector is removed. Instead each compositor has now its own renderer which can be optimized for the specific case. E.g. the OpenGL compositor renders to a scratch image which gets copied into the combined texture, the XRender compositor copies into the XPixmaps. Input events are also changed. The events are composed into QMouseEvents and passed through the decoration, which might accept them. If they are not accpted we assume that it's a press on the decoration area allowing us to resize/move the window. Input events are not completely working yet, e.g. wheel events are not yet processed and double click on deco is not yet working. Overall KDecoration2 is way more stateful and KWin core needs more adjustments for it. E.g. borders are allowed to be disabled at any time.
2014-07-22 15:11:19 +04:00
};
}
}
#endif