kwin/src/internal_client.cpp

542 lines
13 KiB
C++
Raw Normal View History

2020-08-02 22:22:19 +00:00
/*
KWin - the KDE window manager
This file is part of the KDE project.
2020-08-02 22:22:19 +00:00
SPDX-FileCopyrightText: 2019 Martin Flöser <mgraesslin@kde.org>
SPDX-FileCopyrightText: 2019 Vlad Zahorodnii <vlad.zahorodnii@kde.org>
2020-08-02 22:22:19 +00:00
SPDX-License-Identifier: GPL-2.0-or-later
*/
#include "internal_client.h"
#include "decorations/decorationbridge.h"
#include "deleted.h"
#include "surfaceitem.h"
#include "workspace.h"
#include <KDecoration2/Decoration>
#include <QMouseEvent>
#include <QOpenGLFramebufferObject>
#include <QWindow>
Q_DECLARE_METATYPE(NET::WindowType)
static const QByteArray s_skipClosePropertyName = QByteArrayLiteral("KWIN_SKIP_CLOSE_ANIMATION");
static const QByteArray s_shadowEnabledPropertyName = QByteArrayLiteral("kwin_shadow_enabled");
namespace KWin
{
InternalClient::InternalClient(QWindow *window)
: m_internalWindow(window)
, m_internalWindowFlags(window->flags())
{
connect(m_internalWindow, &QWindow::xChanged, this, &InternalClient::updateInternalWindowGeometry);
connect(m_internalWindow, &QWindow::yChanged, this, &InternalClient::updateInternalWindowGeometry);
connect(m_internalWindow, &QWindow::widthChanged, this, &InternalClient::updateInternalWindowGeometry);
connect(m_internalWindow, &QWindow::heightChanged, this, &InternalClient::updateInternalWindowGeometry);
connect(m_internalWindow, &QWindow::windowTitleChanged, this, &InternalClient::setCaption);
connect(m_internalWindow, &QWindow::opacityChanged, this, &InternalClient::setOpacity);
connect(m_internalWindow, &QWindow::destroyed, this, &InternalClient::destroyClient);
const QVariant windowType = m_internalWindow->property("kwin_windowType");
if (!windowType.isNull()) {
m_windowType = windowType.value<NET::WindowType>();
}
setCaption(m_internalWindow->title());
setIcon(QIcon::fromTheme(QStringLiteral("kwin")));
setOnAllDesktops(true);
setOpacity(m_internalWindow->opacity());
setSkipCloseAnimation(m_internalWindow->property(s_skipClosePropertyName).toBool());
// Create scene window, effect window, and update server-side shadow.
setupCompositing();
updateColorScheme();
blockGeometryUpdates(true);
commitGeometry(m_internalWindow->geometry());
updateDecoration(true);
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
moveResize(clientRectToFrameRect(m_internalWindow->geometry()));
blockGeometryUpdates(false);
m_internalWindow->installEventFilter(this);
}
InternalClient::~InternalClient()
{
}
bool InternalClient::isClient() const
{
return true;
}
bool InternalClient::hitTest(const QPoint &point) const
{
if (!AbstractClient::hitTest(point)) {
return false;
}
const QRegion mask = m_internalWindow->mask();
if (!mask.isEmpty() && !mask.contains(mapToLocal(point))) {
return false;
} else if (m_internalWindow->property("outputOnly").toBool()) {
return false;
}
return true;
}
void InternalClient::pointerEnterEvent(const QPoint &globalPos)
{
AbstractClient::pointerEnterEvent(globalPos);
QEnterEvent enterEvent(pos(), pos(), globalPos);
QCoreApplication::sendEvent(m_internalWindow, &enterEvent);
}
void InternalClient::pointerLeaveEvent()
{
AbstractClient::pointerLeaveEvent();
QEvent event(QEvent::Leave);
QCoreApplication::sendEvent(m_internalWindow, &event);
}
bool InternalClient::eventFilter(QObject *watched, QEvent *event)
{
if (watched == m_internalWindow && event->type() == QEvent::DynamicPropertyChange) {
QDynamicPropertyChangeEvent *pe = static_cast<QDynamicPropertyChangeEvent*>(event);
if (pe->propertyName() == s_skipClosePropertyName) {
setSkipCloseAnimation(m_internalWindow->property(s_skipClosePropertyName).toBool());
}
if (pe->propertyName() == s_shadowEnabledPropertyName) {
updateShadow();
}
if (pe->propertyName() == "kwin_windowType") {
m_windowType = m_internalWindow->property("kwin_windowType").value<NET::WindowType>();
workspace()->updateClientArea();
}
}
return false;
}
qreal InternalClient::bufferScale() const
{
if (m_internalWindow) {
return m_internalWindow->devicePixelRatio();
}
return 1;
}
QString InternalClient::captionNormal() const
{
return m_captionNormal;
}
QString InternalClient::captionSuffix() const
{
return m_captionSuffix;
}
QSize InternalClient::minSize() const
{
return m_internalWindow->minimumSize();
}
QSize InternalClient::maxSize() const
{
return m_internalWindow->maximumSize();
}
NET::WindowType InternalClient::windowType(bool direct, int supported_types) const
{
Q_UNUSED(direct)
Q_UNUSED(supported_types)
return m_windowType;
}
void InternalClient::killWindow()
{
// We don't kill our internal windows.
}
bool InternalClient::isPopupWindow() const
{
if (AbstractClient::isPopupWindow()) {
return true;
}
return m_internalWindowFlags.testFlag(Qt::Popup);
}
QByteArray InternalClient::windowRole() const
{
return QByteArray();
}
void InternalClient::closeWindow()
{
if (m_internalWindow) {
m_internalWindow->hide();
}
}
bool InternalClient::isCloseable() const
{
return true;
}
bool InternalClient::isMovable() const
{
return true;
}
bool InternalClient::isMovableAcrossScreens() const
{
return true;
}
bool InternalClient::isResizable() const
{
return true;
}
bool InternalClient::isPlaceable() const
{
return !m_internalWindowFlags.testFlag(Qt::BypassWindowManagerHint) && !m_internalWindowFlags.testFlag(Qt::Popup);
}
bool InternalClient::noBorder() const
{
return m_userNoBorder || m_internalWindowFlags.testFlag(Qt::FramelessWindowHint) || m_internalWindowFlags.testFlag(Qt::Popup);
}
bool InternalClient::userCanSetNoBorder() const
{
return !m_internalWindowFlags.testFlag(Qt::FramelessWindowHint) || m_internalWindowFlags.testFlag(Qt::Popup);
}
bool InternalClient::wantsInput() const
{
return false;
}
bool InternalClient::isInternal() const
{
return true;
}
bool InternalClient::isLockScreen() const
{
if (m_internalWindow) {
return m_internalWindow->property("org_kde_ksld_emergency").toBool();
}
return false;
}
bool InternalClient::isOutline() const
{
if (m_internalWindow) {
return m_internalWindow->property("__kwin_outline").toBool();
}
return false;
}
bool InternalClient::isShown() const
{
return readyForPainting();
}
bool InternalClient::isHiddenInternal() const
{
return false;
}
void InternalClient::hideClient()
{
}
void InternalClient::showClient()
{
}
void InternalClient::resizeWithChecks(const QSize &size)
{
if (!m_internalWindow) {
return;
}
const QRect area = workspace()->clientArea(WorkArea, this);
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
resize(size.boundedTo(area.size()));
}
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 InternalClient::moveResizeInternal(const QRect &rect, MoveResizeMode mode)
{
if (areGeometryUpdatesBlocked()) {
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
setPendingMoveResizeMode(mode);
return;
}
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
const QSize requestedClientSize = frameSizeToClientSize(rect.size());
if (clientSize() == requestedClientSize) {
commitGeometry(rect);
} else {
requestGeometry(rect);
}
}
AbstractClient *InternalClient::findModal(bool allow_itself)
{
Q_UNUSED(allow_itself)
return nullptr;
}
bool InternalClient::takeFocus()
{
return false;
}
void InternalClient::setNoBorder(bool set)
{
if (!userCanSetNoBorder()) {
return;
}
if (m_userNoBorder == set) {
return;
}
m_userNoBorder = set;
updateDecoration(true);
}
void InternalClient::createDecoration(const QRect &oldGeometry)
{
setDecoration(QSharedPointer<KDecoration2::Decoration>(Decoration::DecorationBridge::self()->createDecoration(this)));
moveResize(oldGeometry);
Q_EMIT geometryShapeChanged(this, oldGeometry);
}
void InternalClient::destroyDecoration()
{
const QSize clientSize = frameSizeToClientSize(moveResizeGeometry().size());
setDecoration(nullptr);
resize(clientSize);
}
void InternalClient::updateDecoration(bool check_workspace_pos, bool force)
{
if (!force && isDecorated() == !noBorder()) {
return;
}
GeometryUpdatesBlocker blocker(this);
Make checkWorkspacePosition() work without client geometry A good portion of geometry handling code was written during the X11 times. The main difference between X11 and Wayland is that kwin doesn't know where a window will exactly be after resize() or moveResize(). In order to handle Wayland specifics, every window has a bounding geometry that is being manipulated by move(), resize(), and moveResize(). The frameGeometry(), the clientGeometry(), and the bufferGeometry() are not manipulated by move(), resize(), and moveResize() directly. Almost everything that manipulates geometry should use moveResizeGeometry(). This creates a problem though, since the clientGeometry() will be updated only after the client provides a new buffer, kwin has absolutely no idea what the client geometry for a given move resize geometry will be. Another side of the coin is that decoration updates are performed asynchronously on wayland, meaning that you cannot use border properties for anything related to geometry handling and you should avoid using borderLeft(), borderTop(), borderRight(), and borderBottom() in general. clientGeometry(), bufferGeometry(), and border*() are good only if you want to forward an event or render something. They can't be used for manipulating the geometry. Unfortunately, AbstractClient::checkWorkspacePosition() needs both, which is a bit of a problem. To add more oil to the fire, contents of a decorated window can be snapped to a screen edge. This goes against the nature of geometry updates on wayland, where we try to indicate the bounds of the frame geometry and avoid using client and buffer geometries. In order to make geometry handling more correct on wayland, this change removes the ability to snap the contents of a decorated window to a screen edge. This allows to avoid using the client geometry in checkWorkspacePosition(), which is a very important function that ensures the window is inside the workspace. There is nothing wrong with snapping the frame rather than its contents and that's what kwin used to do. It was changed with the removal of "Display borders on maximized windows" option, the relevant commit didn't provide any reasoning behind the change.
2022-01-14 16:07:44 +00:00
const QRect oldFrameGeometry = frameGeometry();
if (force) {
destroyDecoration();
}
if (!noBorder()) {
Make checkWorkspacePosition() work without client geometry A good portion of geometry handling code was written during the X11 times. The main difference between X11 and Wayland is that kwin doesn't know where a window will exactly be after resize() or moveResize(). In order to handle Wayland specifics, every window has a bounding geometry that is being manipulated by move(), resize(), and moveResize(). The frameGeometry(), the clientGeometry(), and the bufferGeometry() are not manipulated by move(), resize(), and moveResize() directly. Almost everything that manipulates geometry should use moveResizeGeometry(). This creates a problem though, since the clientGeometry() will be updated only after the client provides a new buffer, kwin has absolutely no idea what the client geometry for a given move resize geometry will be. Another side of the coin is that decoration updates are performed asynchronously on wayland, meaning that you cannot use border properties for anything related to geometry handling and you should avoid using borderLeft(), borderTop(), borderRight(), and borderBottom() in general. clientGeometry(), bufferGeometry(), and border*() are good only if you want to forward an event or render something. They can't be used for manipulating the geometry. Unfortunately, AbstractClient::checkWorkspacePosition() needs both, which is a bit of a problem. To add more oil to the fire, contents of a decorated window can be snapped to a screen edge. This goes against the nature of geometry updates on wayland, where we try to indicate the bounds of the frame geometry and avoid using client and buffer geometries. In order to make geometry handling more correct on wayland, this change removes the ability to snap the contents of a decorated window to a screen edge. This allows to avoid using the client geometry in checkWorkspacePosition(), which is a very important function that ensures the window is inside the workspace. There is nothing wrong with snapping the frame rather than its contents and that's what kwin used to do. It was changed with the removal of "Display borders on maximized windows" option, the relevant commit didn't provide any reasoning behind the change.
2022-01-14 16:07:44 +00:00
createDecoration(oldFrameGeometry);
} else {
destroyDecoration();
}
updateShadow();
if (check_workspace_pos) {
Make checkWorkspacePosition() work without client geometry A good portion of geometry handling code was written during the X11 times. The main difference between X11 and Wayland is that kwin doesn't know where a window will exactly be after resize() or moveResize(). In order to handle Wayland specifics, every window has a bounding geometry that is being manipulated by move(), resize(), and moveResize(). The frameGeometry(), the clientGeometry(), and the bufferGeometry() are not manipulated by move(), resize(), and moveResize() directly. Almost everything that manipulates geometry should use moveResizeGeometry(). This creates a problem though, since the clientGeometry() will be updated only after the client provides a new buffer, kwin has absolutely no idea what the client geometry for a given move resize geometry will be. Another side of the coin is that decoration updates are performed asynchronously on wayland, meaning that you cannot use border properties for anything related to geometry handling and you should avoid using borderLeft(), borderTop(), borderRight(), and borderBottom() in general. clientGeometry(), bufferGeometry(), and border*() are good only if you want to forward an event or render something. They can't be used for manipulating the geometry. Unfortunately, AbstractClient::checkWorkspacePosition() needs both, which is a bit of a problem. To add more oil to the fire, contents of a decorated window can be snapped to a screen edge. This goes against the nature of geometry updates on wayland, where we try to indicate the bounds of the frame geometry and avoid using client and buffer geometries. In order to make geometry handling more correct on wayland, this change removes the ability to snap the contents of a decorated window to a screen edge. This allows to avoid using the client geometry in checkWorkspacePosition(), which is a very important function that ensures the window is inside the workspace. There is nothing wrong with snapping the frame rather than its contents and that's what kwin used to do. It was changed with the removal of "Display borders on maximized windows" option, the relevant commit didn't provide any reasoning behind the change.
2022-01-14 16:07:44 +00:00
checkWorkspacePosition(oldFrameGeometry);
}
}
void InternalClient::invalidateDecoration()
{
updateDecoration(true, true);
}
void InternalClient::destroyClient()
{
markAsZombie();
if (isInteractiveMoveResize()) {
leaveInteractiveMoveResize();
Q_EMIT clientFinishUserMovedResized(this);
}
Deleted *deleted = Deleted::create(this);
Q_EMIT windowClosed(this, deleted);
destroyDecoration();
workspace()->removeInternalClient(this);
deleted->unrefWindow();
m_internalWindow = nullptr;
delete this;
}
bool InternalClient::hasPopupGrab() const
{
return !m_internalWindow->flags().testFlag(Qt::WindowTransparentForInput) &&
m_internalWindow->flags().testFlag(Qt::Popup) &&
!m_internalWindow->flags().testFlag(Qt::ToolTip);
}
void InternalClient::popupDone()
{
m_internalWindow->hide();
}
void InternalClient::present(const QSharedPointer<QOpenGLFramebufferObject> fbo)
{
Q_ASSERT(m_internalImage.isNull());
const QSize bufferSize = fbo->size() / bufferScale();
commitGeometry(QRect(pos(), clientSizeToFrameSize(bufferSize)));
markAsMapped();
m_internalFBO = fbo;
setDepth(32);
surfaceItem()->addDamage(surfaceItem()->rect());
}
void InternalClient::present(const QImage &image, const QRegion &damage)
{
Q_ASSERT(m_internalFBO.isNull());
const QSize bufferSize = image.size() / bufferScale();
commitGeometry(QRect(pos(), clientSizeToFrameSize(bufferSize)));
markAsMapped();
m_internalImage = image;
setDepth(32);
surfaceItem()->addDamage(damage);
}
QWindow *InternalClient::internalWindow() const
{
return m_internalWindow;
}
bool InternalClient::acceptsFocus() const
{
return false;
}
bool InternalClient::belongsToSameApplication(const AbstractClient *other, SameApplicationChecks checks) const
{
Q_UNUSED(checks)
const InternalClient *otherInternal = qobject_cast<const InternalClient *>(other);
if (!otherInternal) {
return false;
}
if (otherInternal == this) {
return true;
}
return otherInternal->internalWindow()->isAncestorOf(internalWindow()) ||
internalWindow()->isAncestorOf(otherInternal->internalWindow());
}
void InternalClient::doInteractiveResizeSync()
{
requestGeometry(moveResizeGeometry());
}
void InternalClient::updateCaption()
{
const QString oldSuffix = m_captionSuffix;
const auto shortcut = shortcutCaptionSuffix();
m_captionSuffix = shortcut;
if ((!isSpecialWindow() || isToolbar()) && findClientWithSameCaption()) {
int i = 2;
do {
m_captionSuffix = shortcut + QLatin1String(" <") + QString::number(i) + QLatin1Char('>');
i++;
} while (findClientWithSameCaption());
}
if (m_captionSuffix != oldSuffix) {
Q_EMIT captionChanged();
}
}
void InternalClient::requestGeometry(const QRect &rect)
{
if (m_internalWindow) {
m_internalWindow->setGeometry(frameRectToClientRect(rect));
}
}
void InternalClient::commitGeometry(const QRect &rect)
{
// The client geometry and the buffer geometry are the same.
const QRect oldClientGeometry = m_clientGeometry;
const QRect oldFrameGeometry = m_frameGeometry;
m_clientGeometry = frameRectToClientRect(rect);
m_frameGeometry = rect;
m_bufferGeometry = m_clientGeometry;
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
if (oldClientGeometry == m_clientGeometry && oldFrameGeometry == m_frameGeometry) {
return;
}
syncGeometryToInternalWindow();
if (oldClientGeometry != m_clientGeometry) {
Q_EMIT bufferGeometryChanged(this, oldClientGeometry);
Q_EMIT clientGeometryChanged(this, oldClientGeometry);
}
if (oldFrameGeometry != m_frameGeometry) {
Q_EMIT frameGeometryChanged(this, oldFrameGeometry);
}
Q_EMIT geometryShapeChanged(this, oldFrameGeometry);
}
void InternalClient::setCaption(const QString &caption)
{
if (m_captionNormal == caption) {
return;
}
m_captionNormal = caption;
const QString oldCaptionSuffix = m_captionSuffix;
updateCaption();
if (m_captionSuffix == oldCaptionSuffix) {
Q_EMIT captionChanged();
}
}
void InternalClient::markAsMapped()
{
if (!ready_for_painting) {
setReadyForPainting();
workspace()->addInternalClient(this);
}
}
void InternalClient::syncGeometryToInternalWindow()
{
if (m_internalWindow->geometry() == frameRectToClientRect(frameGeometry())) {
return;
}
QTimer::singleShot(0, this, [this] { requestGeometry(frameGeometry()); });
}
void InternalClient::updateInternalWindowGeometry()
{
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
if (!isInteractiveMoveResize()) {
const QRect rect = clientRectToFrameRect(m_internalWindow->geometry());
setMoveResizeGeometry(rect);
commitGeometry(rect);
}
}
}