kwin/autotests/integration/window_rules_test.cpp

208 lines
7.3 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: 2016 Martin Gräßlin <mgraesslin@kde.org>
2020-08-02 22:22:19 +00:00
SPDX-License-Identifier: GPL-2.0-or-later
*/
#include "kwin_wayland_test.h"
#include "atoms.h"
#include "core/output.h"
#include "pointer_input.h"
#include "rules.h"
#include "wayland_server.h"
#include "workspace.h"
#include "x11window.h"
#include <netwm.h>
#include <xcb/xcb_icccm.h>
namespace KWin
{
static const QString s_socketName = QStringLiteral("wayland_test_kwin_window_rules-0");
class WindowRuleTest : public QObject
{
Q_OBJECT
private Q_SLOTS:
void initTestCase();
void init();
void cleanup();
void testApplyInitialMaximizeVert();
Re-evaluate the window rules when the window class of a Client changes Summary: So far KWin did not re-evaluate the window rules when the Client's window class changes. Window class is the main (static) feature the rule selection is based on. For dynamic changing mapping features like caption KWin does re-evaluate the rules. The reason for KWin to not evaluate when the class changes is that KWin expects the class not to change. From ICCCM section 4.1.2.5: > This property must be present when the window leaves the Withdrawn > state and may be changed only while the window is in the Withdrawn > state. Window managers may examine the property only when they start > up and when the window leaves the Withdrawn state, but there should be > no need for a client to change its state dynamically. Unfortunately there are prominent applications such as Spotify which violate this rule and do change the window class dynamically. While this is a clear ICCCM violation there is nothing which really forbids it (may not != must not) and nothing which forbids KWin to react on changes. As also libtaskmanager started to react on it, it makes sense to also hook up the required bits for window rules. After all KWin detects changes to the window class for some time already and has the functionality to evaluate the rules. So all there is, is one connect which improves the situation for our users, while at the same time it should be rather risk free. If a setup window rule breaks after this change it's due to the client not being ICCCM compliant. Test Plan: I don't use any of the affected applications, so it's only tested with the new added unit test. Reviewers: #kwin Subscribers: kwin Tags: #kwin Differential Revision: https://phabricator.kde.org/D16670
2018-11-04 19:23:00 +00:00
void testWindowClassChange();
};
void WindowRuleTest::initTestCase()
{
2022-04-22 17:39:12 +00:00
qRegisterMetaType<KWin::Window *>();
QSignalSpy applicationStartedSpy(kwinApp(), &Application::started);
QVERIFY(waylandServer()->init(s_socketName));
Test::setOutputConfig({
QRect(0, 0, 1280, 1024),
QRect(1280, 0, 1280, 1024),
});
kwinApp()->start();
QVERIFY(applicationStartedSpy.wait());
const auto outputs = workspace()->outputs();
QCOMPARE(outputs.count(), 2);
QCOMPARE(outputs[0]->geometry(), QRect(0, 0, 1280, 1024));
QCOMPARE(outputs[1]->geometry(), QRect(1280, 0, 1280, 1024));
setenv("QT_QPA_PLATFORM", "wayland", true);
}
void WindowRuleTest::init()
{
workspace()->setActiveOutput(QPoint(640, 512));
input()->pointer()->warp(QPoint(640, 512));
QVERIFY(waylandServer()->windows().isEmpty());
}
void WindowRuleTest::cleanup()
{
// discards old rules
2022-07-30 22:40:49 +00:00
workspace()->rulebook()->load();
}
struct XcbConnectionDeleter
{
void operator()(xcb_connection_t *pointer)
{
xcb_disconnect(pointer);
}
};
void WindowRuleTest::testApplyInitialMaximizeVert()
{
// this test creates the situation of BUG 367554: creates a window and initial apply maximize vertical
// the window is matched by class and role
// load the rule
workspace()->rulebook()->setConfig(KSharedConfig::openConfig(QFINDTESTDATA("./data/rules/maximize-vert-apply-initial"), KConfig::SimpleConfig));
workspace()->slotReconfigure();
// create the test window
Test::XcbConnectionPtr c = Test::createX11Connection();
QVERIFY(!xcb_connection_has_error(c.get()));
xcb_window_t windowId = xcb_generate_id(c.get());
const QRect windowGeometry = QRect(0, 0, 10, 20);
const uint32_t values[] = {
XCB_EVENT_MASK_ENTER_WINDOW | XCB_EVENT_MASK_LEAVE_WINDOW};
xcb_create_window(c.get(), XCB_COPY_FROM_PARENT, windowId, rootWindow(),
windowGeometry.x(),
windowGeometry.y(),
windowGeometry.width(),
windowGeometry.height(),
0, XCB_WINDOW_CLASS_INPUT_OUTPUT, XCB_COPY_FROM_PARENT, XCB_CW_EVENT_MASK, values);
xcb_size_hints_t hints;
memset(&hints, 0, sizeof(hints));
xcb_icccm_size_hints_set_position(&hints, 1, windowGeometry.x(), windowGeometry.y());
xcb_icccm_size_hints_set_size(&hints, 1, windowGeometry.width(), windowGeometry.height());
xcb_icccm_set_wm_normal_hints(c.get(), windowId, &hints);
xcb_icccm_set_wm_class(c.get(), windowId, 9, "kpat\0kpat");
const QByteArray role = QByteArrayLiteral("mainwindow");
xcb_change_property(c.get(), XCB_PROP_MODE_REPLACE, windowId, atoms->wm_window_role, XCB_ATOM_STRING, 8, role.length(), role.constData());
NETWinInfo info(c.get(), windowId, rootWindow(), NET::WMAllProperties, NET::WM2AllProperties);
info.setWindowType(NET::Normal);
xcb_map_window(c.get(), windowId);
xcb_flush(c.get());
QSignalSpy windowCreatedSpy(workspace(), &Workspace::windowAdded);
QVERIFY(windowCreatedSpy.wait());
2022-04-23 19:51:16 +00:00
X11Window *window = windowCreatedSpy.last().first().value<X11Window *>();
QVERIFY(window);
QVERIFY(window->isDecorated());
QVERIFY(!window->hasStrut());
QVERIFY(!window->readyForPainting());
QMetaObject::invokeMethod(window, "setReadyForPainting");
QVERIFY(window->readyForPainting());
QVERIFY(Test::waitForWaylandSurface(window));
QCOMPARE(window->maximizeMode(), MaximizeVertical);
// destroy window again
QSignalSpy windowClosedSpy(window, &X11Window::closed);
xcb_unmap_window(c.get(), windowId);
xcb_destroy_window(c.get(), windowId);
xcb_flush(c.get());
QVERIFY(windowClosedSpy.wait());
}
Re-evaluate the window rules when the window class of a Client changes Summary: So far KWin did not re-evaluate the window rules when the Client's window class changes. Window class is the main (static) feature the rule selection is based on. For dynamic changing mapping features like caption KWin does re-evaluate the rules. The reason for KWin to not evaluate when the class changes is that KWin expects the class not to change. From ICCCM section 4.1.2.5: > This property must be present when the window leaves the Withdrawn > state and may be changed only while the window is in the Withdrawn > state. Window managers may examine the property only when they start > up and when the window leaves the Withdrawn state, but there should be > no need for a client to change its state dynamically. Unfortunately there are prominent applications such as Spotify which violate this rule and do change the window class dynamically. While this is a clear ICCCM violation there is nothing which really forbids it (may not != must not) and nothing which forbids KWin to react on changes. As also libtaskmanager started to react on it, it makes sense to also hook up the required bits for window rules. After all KWin detects changes to the window class for some time already and has the functionality to evaluate the rules. So all there is, is one connect which improves the situation for our users, while at the same time it should be rather risk free. If a setup window rule breaks after this change it's due to the client not being ICCCM compliant. Test Plan: I don't use any of the affected applications, so it's only tested with the new added unit test. Reviewers: #kwin Subscribers: kwin Tags: #kwin Differential Revision: https://phabricator.kde.org/D16670
2018-11-04 19:23:00 +00:00
void WindowRuleTest::testWindowClassChange()
{
KSharedConfig::Ptr config = KSharedConfig::openConfig(QString(), KConfig::SimpleConfig);
config->group(QStringLiteral("General")).writeEntry("count", 1);
Re-evaluate the window rules when the window class of a Client changes Summary: So far KWin did not re-evaluate the window rules when the Client's window class changes. Window class is the main (static) feature the rule selection is based on. For dynamic changing mapping features like caption KWin does re-evaluate the rules. The reason for KWin to not evaluate when the class changes is that KWin expects the class not to change. From ICCCM section 4.1.2.5: > This property must be present when the window leaves the Withdrawn > state and may be changed only while the window is in the Withdrawn > state. Window managers may examine the property only when they start > up and when the window leaves the Withdrawn state, but there should be > no need for a client to change its state dynamically. Unfortunately there are prominent applications such as Spotify which violate this rule and do change the window class dynamically. While this is a clear ICCCM violation there is nothing which really forbids it (may not != must not) and nothing which forbids KWin to react on changes. As also libtaskmanager started to react on it, it makes sense to also hook up the required bits for window rules. After all KWin detects changes to the window class for some time already and has the functionality to evaluate the rules. So all there is, is one connect which improves the situation for our users, while at the same time it should be rather risk free. If a setup window rule breaks after this change it's due to the client not being ICCCM compliant. Test Plan: I don't use any of the affected applications, so it's only tested with the new added unit test. Reviewers: #kwin Subscribers: kwin Tags: #kwin Differential Revision: https://phabricator.kde.org/D16670
2018-11-04 19:23:00 +00:00
auto group = config->group(QStringLiteral("1"));
Re-evaluate the window rules when the window class of a Client changes Summary: So far KWin did not re-evaluate the window rules when the Client's window class changes. Window class is the main (static) feature the rule selection is based on. For dynamic changing mapping features like caption KWin does re-evaluate the rules. The reason for KWin to not evaluate when the class changes is that KWin expects the class not to change. From ICCCM section 4.1.2.5: > This property must be present when the window leaves the Withdrawn > state and may be changed only while the window is in the Withdrawn > state. Window managers may examine the property only when they start > up and when the window leaves the Withdrawn state, but there should be > no need for a client to change its state dynamically. Unfortunately there are prominent applications such as Spotify which violate this rule and do change the window class dynamically. While this is a clear ICCCM violation there is nothing which really forbids it (may not != must not) and nothing which forbids KWin to react on changes. As also libtaskmanager started to react on it, it makes sense to also hook up the required bits for window rules. After all KWin detects changes to the window class for some time already and has the functionality to evaluate the rules. So all there is, is one connect which improves the situation for our users, while at the same time it should be rather risk free. If a setup window rule breaks after this change it's due to the client not being ICCCM compliant. Test Plan: I don't use any of the affected applications, so it's only tested with the new added unit test. Reviewers: #kwin Subscribers: kwin Tags: #kwin Differential Revision: https://phabricator.kde.org/D16670
2018-11-04 19:23:00 +00:00
group.writeEntry("above", true);
group.writeEntry("aboverule", 2);
group.writeEntry("wmclass", "org.kde.foo");
group.writeEntry("wmclasscomplete", false);
group.writeEntry("wmclassmatch", 1);
group.sync();
2022-07-30 22:40:49 +00:00
workspace()->rulebook()->setConfig(config);
Re-evaluate the window rules when the window class of a Client changes Summary: So far KWin did not re-evaluate the window rules when the Client's window class changes. Window class is the main (static) feature the rule selection is based on. For dynamic changing mapping features like caption KWin does re-evaluate the rules. The reason for KWin to not evaluate when the class changes is that KWin expects the class not to change. From ICCCM section 4.1.2.5: > This property must be present when the window leaves the Withdrawn > state and may be changed only while the window is in the Withdrawn > state. Window managers may examine the property only when they start > up and when the window leaves the Withdrawn state, but there should be > no need for a client to change its state dynamically. Unfortunately there are prominent applications such as Spotify which violate this rule and do change the window class dynamically. While this is a clear ICCCM violation there is nothing which really forbids it (may not != must not) and nothing which forbids KWin to react on changes. As also libtaskmanager started to react on it, it makes sense to also hook up the required bits for window rules. After all KWin detects changes to the window class for some time already and has the functionality to evaluate the rules. So all there is, is one connect which improves the situation for our users, while at the same time it should be rather risk free. If a setup window rule breaks after this change it's due to the client not being ICCCM compliant. Test Plan: I don't use any of the affected applications, so it's only tested with the new added unit test. Reviewers: #kwin Subscribers: kwin Tags: #kwin Differential Revision: https://phabricator.kde.org/D16670
2018-11-04 19:23:00 +00:00
workspace()->slotReconfigure();
// create the test window
Test::XcbConnectionPtr c = Test::createX11Connection();
QVERIFY(!xcb_connection_has_error(c.get()));
Re-evaluate the window rules when the window class of a Client changes Summary: So far KWin did not re-evaluate the window rules when the Client's window class changes. Window class is the main (static) feature the rule selection is based on. For dynamic changing mapping features like caption KWin does re-evaluate the rules. The reason for KWin to not evaluate when the class changes is that KWin expects the class not to change. From ICCCM section 4.1.2.5: > This property must be present when the window leaves the Withdrawn > state and may be changed only while the window is in the Withdrawn > state. Window managers may examine the property only when they start > up and when the window leaves the Withdrawn state, but there should be > no need for a client to change its state dynamically. Unfortunately there are prominent applications such as Spotify which violate this rule and do change the window class dynamically. While this is a clear ICCCM violation there is nothing which really forbids it (may not != must not) and nothing which forbids KWin to react on changes. As also libtaskmanager started to react on it, it makes sense to also hook up the required bits for window rules. After all KWin detects changes to the window class for some time already and has the functionality to evaluate the rules. So all there is, is one connect which improves the situation for our users, while at the same time it should be rather risk free. If a setup window rule breaks after this change it's due to the client not being ICCCM compliant. Test Plan: I don't use any of the affected applications, so it's only tested with the new added unit test. Reviewers: #kwin Subscribers: kwin Tags: #kwin Differential Revision: https://phabricator.kde.org/D16670
2018-11-04 19:23:00 +00:00
xcb_window_t windowId = xcb_generate_id(c.get());
Re-evaluate the window rules when the window class of a Client changes Summary: So far KWin did not re-evaluate the window rules when the Client's window class changes. Window class is the main (static) feature the rule selection is based on. For dynamic changing mapping features like caption KWin does re-evaluate the rules. The reason for KWin to not evaluate when the class changes is that KWin expects the class not to change. From ICCCM section 4.1.2.5: > This property must be present when the window leaves the Withdrawn > state and may be changed only while the window is in the Withdrawn > state. Window managers may examine the property only when they start > up and when the window leaves the Withdrawn state, but there should be > no need for a client to change its state dynamically. Unfortunately there are prominent applications such as Spotify which violate this rule and do change the window class dynamically. While this is a clear ICCCM violation there is nothing which really forbids it (may not != must not) and nothing which forbids KWin to react on changes. As also libtaskmanager started to react on it, it makes sense to also hook up the required bits for window rules. After all KWin detects changes to the window class for some time already and has the functionality to evaluate the rules. So all there is, is one connect which improves the situation for our users, while at the same time it should be rather risk free. If a setup window rule breaks after this change it's due to the client not being ICCCM compliant. Test Plan: I don't use any of the affected applications, so it's only tested with the new added unit test. Reviewers: #kwin Subscribers: kwin Tags: #kwin Differential Revision: https://phabricator.kde.org/D16670
2018-11-04 19:23:00 +00:00
const QRect windowGeometry = QRect(0, 0, 10, 20);
const uint32_t values[] = {
XCB_EVENT_MASK_ENTER_WINDOW | XCB_EVENT_MASK_LEAVE_WINDOW};
xcb_create_window(c.get(), XCB_COPY_FROM_PARENT, windowId, rootWindow(),
Re-evaluate the window rules when the window class of a Client changes Summary: So far KWin did not re-evaluate the window rules when the Client's window class changes. Window class is the main (static) feature the rule selection is based on. For dynamic changing mapping features like caption KWin does re-evaluate the rules. The reason for KWin to not evaluate when the class changes is that KWin expects the class not to change. From ICCCM section 4.1.2.5: > This property must be present when the window leaves the Withdrawn > state and may be changed only while the window is in the Withdrawn > state. Window managers may examine the property only when they start > up and when the window leaves the Withdrawn state, but there should be > no need for a client to change its state dynamically. Unfortunately there are prominent applications such as Spotify which violate this rule and do change the window class dynamically. While this is a clear ICCCM violation there is nothing which really forbids it (may not != must not) and nothing which forbids KWin to react on changes. As also libtaskmanager started to react on it, it makes sense to also hook up the required bits for window rules. After all KWin detects changes to the window class for some time already and has the functionality to evaluate the rules. So all there is, is one connect which improves the situation for our users, while at the same time it should be rather risk free. If a setup window rule breaks after this change it's due to the client not being ICCCM compliant. Test Plan: I don't use any of the affected applications, so it's only tested with the new added unit test. Reviewers: #kwin Subscribers: kwin Tags: #kwin Differential Revision: https://phabricator.kde.org/D16670
2018-11-04 19:23:00 +00:00
windowGeometry.x(),
windowGeometry.y(),
windowGeometry.width(),
windowGeometry.height(),
0, XCB_WINDOW_CLASS_INPUT_OUTPUT, XCB_COPY_FROM_PARENT, XCB_CW_EVENT_MASK, values);
xcb_size_hints_t hints;
memset(&hints, 0, sizeof(hints));
xcb_icccm_size_hints_set_position(&hints, 1, windowGeometry.x(), windowGeometry.y());
xcb_icccm_size_hints_set_size(&hints, 1, windowGeometry.width(), windowGeometry.height());
xcb_icccm_set_wm_normal_hints(c.get(), windowId, &hints);
xcb_icccm_set_wm_class(c.get(), windowId, 23, "org.kde.bar\0org.kde.bar");
Re-evaluate the window rules when the window class of a Client changes Summary: So far KWin did not re-evaluate the window rules when the Client's window class changes. Window class is the main (static) feature the rule selection is based on. For dynamic changing mapping features like caption KWin does re-evaluate the rules. The reason for KWin to not evaluate when the class changes is that KWin expects the class not to change. From ICCCM section 4.1.2.5: > This property must be present when the window leaves the Withdrawn > state and may be changed only while the window is in the Withdrawn > state. Window managers may examine the property only when they start > up and when the window leaves the Withdrawn state, but there should be > no need for a client to change its state dynamically. Unfortunately there are prominent applications such as Spotify which violate this rule and do change the window class dynamically. While this is a clear ICCCM violation there is nothing which really forbids it (may not != must not) and nothing which forbids KWin to react on changes. As also libtaskmanager started to react on it, it makes sense to also hook up the required bits for window rules. After all KWin detects changes to the window class for some time already and has the functionality to evaluate the rules. So all there is, is one connect which improves the situation for our users, while at the same time it should be rather risk free. If a setup window rule breaks after this change it's due to the client not being ICCCM compliant. Test Plan: I don't use any of the affected applications, so it's only tested with the new added unit test. Reviewers: #kwin Subscribers: kwin Tags: #kwin Differential Revision: https://phabricator.kde.org/D16670
2018-11-04 19:23:00 +00:00
NETWinInfo info(c.get(), windowId, rootWindow(), NET::WMAllProperties, NET::WM2AllProperties);
Re-evaluate the window rules when the window class of a Client changes Summary: So far KWin did not re-evaluate the window rules when the Client's window class changes. Window class is the main (static) feature the rule selection is based on. For dynamic changing mapping features like caption KWin does re-evaluate the rules. The reason for KWin to not evaluate when the class changes is that KWin expects the class not to change. From ICCCM section 4.1.2.5: > This property must be present when the window leaves the Withdrawn > state and may be changed only while the window is in the Withdrawn > state. Window managers may examine the property only when they start > up and when the window leaves the Withdrawn state, but there should be > no need for a client to change its state dynamically. Unfortunately there are prominent applications such as Spotify which violate this rule and do change the window class dynamically. While this is a clear ICCCM violation there is nothing which really forbids it (may not != must not) and nothing which forbids KWin to react on changes. As also libtaskmanager started to react on it, it makes sense to also hook up the required bits for window rules. After all KWin detects changes to the window class for some time already and has the functionality to evaluate the rules. So all there is, is one connect which improves the situation for our users, while at the same time it should be rather risk free. If a setup window rule breaks after this change it's due to the client not being ICCCM compliant. Test Plan: I don't use any of the affected applications, so it's only tested with the new added unit test. Reviewers: #kwin Subscribers: kwin Tags: #kwin Differential Revision: https://phabricator.kde.org/D16670
2018-11-04 19:23:00 +00:00
info.setWindowType(NET::Normal);
xcb_map_window(c.get(), windowId);
xcb_flush(c.get());
Re-evaluate the window rules when the window class of a Client changes Summary: So far KWin did not re-evaluate the window rules when the Client's window class changes. Window class is the main (static) feature the rule selection is based on. For dynamic changing mapping features like caption KWin does re-evaluate the rules. The reason for KWin to not evaluate when the class changes is that KWin expects the class not to change. From ICCCM section 4.1.2.5: > This property must be present when the window leaves the Withdrawn > state and may be changed only while the window is in the Withdrawn > state. Window managers may examine the property only when they start > up and when the window leaves the Withdrawn state, but there should be > no need for a client to change its state dynamically. Unfortunately there are prominent applications such as Spotify which violate this rule and do change the window class dynamically. While this is a clear ICCCM violation there is nothing which really forbids it (may not != must not) and nothing which forbids KWin to react on changes. As also libtaskmanager started to react on it, it makes sense to also hook up the required bits for window rules. After all KWin detects changes to the window class for some time already and has the functionality to evaluate the rules. So all there is, is one connect which improves the situation for our users, while at the same time it should be rather risk free. If a setup window rule breaks after this change it's due to the client not being ICCCM compliant. Test Plan: I don't use any of the affected applications, so it's only tested with the new added unit test. Reviewers: #kwin Subscribers: kwin Tags: #kwin Differential Revision: https://phabricator.kde.org/D16670
2018-11-04 19:23:00 +00:00
QSignalSpy windowCreatedSpy(workspace(), &Workspace::windowAdded);
Re-evaluate the window rules when the window class of a Client changes Summary: So far KWin did not re-evaluate the window rules when the Client's window class changes. Window class is the main (static) feature the rule selection is based on. For dynamic changing mapping features like caption KWin does re-evaluate the rules. The reason for KWin to not evaluate when the class changes is that KWin expects the class not to change. From ICCCM section 4.1.2.5: > This property must be present when the window leaves the Withdrawn > state and may be changed only while the window is in the Withdrawn > state. Window managers may examine the property only when they start > up and when the window leaves the Withdrawn state, but there should be > no need for a client to change its state dynamically. Unfortunately there are prominent applications such as Spotify which violate this rule and do change the window class dynamically. While this is a clear ICCCM violation there is nothing which really forbids it (may not != must not) and nothing which forbids KWin to react on changes. As also libtaskmanager started to react on it, it makes sense to also hook up the required bits for window rules. After all KWin detects changes to the window class for some time already and has the functionality to evaluate the rules. So all there is, is one connect which improves the situation for our users, while at the same time it should be rather risk free. If a setup window rule breaks after this change it's due to the client not being ICCCM compliant. Test Plan: I don't use any of the affected applications, so it's only tested with the new added unit test. Reviewers: #kwin Subscribers: kwin Tags: #kwin Differential Revision: https://phabricator.kde.org/D16670
2018-11-04 19:23:00 +00:00
QVERIFY(windowCreatedSpy.wait());
2022-04-23 19:51:16 +00:00
X11Window *window = windowCreatedSpy.last().first().value<X11Window *>();
QVERIFY(window);
QVERIFY(window->isDecorated());
QVERIFY(!window->hasStrut());
QVERIFY(!window->readyForPainting());
QMetaObject::invokeMethod(window, "setReadyForPainting");
QVERIFY(window->readyForPainting());
QVERIFY(Test::waitForWaylandSurface(window));
QCOMPARE(window->keepAbove(), false);
Re-evaluate the window rules when the window class of a Client changes Summary: So far KWin did not re-evaluate the window rules when the Client's window class changes. Window class is the main (static) feature the rule selection is based on. For dynamic changing mapping features like caption KWin does re-evaluate the rules. The reason for KWin to not evaluate when the class changes is that KWin expects the class not to change. From ICCCM section 4.1.2.5: > This property must be present when the window leaves the Withdrawn > state and may be changed only while the window is in the Withdrawn > state. Window managers may examine the property only when they start > up and when the window leaves the Withdrawn state, but there should be > no need for a client to change its state dynamically. Unfortunately there are prominent applications such as Spotify which violate this rule and do change the window class dynamically. While this is a clear ICCCM violation there is nothing which really forbids it (may not != must not) and nothing which forbids KWin to react on changes. As also libtaskmanager started to react on it, it makes sense to also hook up the required bits for window rules. After all KWin detects changes to the window class for some time already and has the functionality to evaluate the rules. So all there is, is one connect which improves the situation for our users, while at the same time it should be rather risk free. If a setup window rule breaks after this change it's due to the client not being ICCCM compliant. Test Plan: I don't use any of the affected applications, so it's only tested with the new added unit test. Reviewers: #kwin Subscribers: kwin Tags: #kwin Differential Revision: https://phabricator.kde.org/D16670
2018-11-04 19:23:00 +00:00
// now change class
2022-04-23 19:51:16 +00:00
QSignalSpy windowClassChangedSpy{window, &X11Window::windowClassChanged};
xcb_icccm_set_wm_class(c.get(), windowId, 23, "org.kde.foo\0org.kde.foo");
xcb_flush(c.get());
Re-evaluate the window rules when the window class of a Client changes Summary: So far KWin did not re-evaluate the window rules when the Client's window class changes. Window class is the main (static) feature the rule selection is based on. For dynamic changing mapping features like caption KWin does re-evaluate the rules. The reason for KWin to not evaluate when the class changes is that KWin expects the class not to change. From ICCCM section 4.1.2.5: > This property must be present when the window leaves the Withdrawn > state and may be changed only while the window is in the Withdrawn > state. Window managers may examine the property only when they start > up and when the window leaves the Withdrawn state, but there should be > no need for a client to change its state dynamically. Unfortunately there are prominent applications such as Spotify which violate this rule and do change the window class dynamically. While this is a clear ICCCM violation there is nothing which really forbids it (may not != must not) and nothing which forbids KWin to react on changes. As also libtaskmanager started to react on it, it makes sense to also hook up the required bits for window rules. After all KWin detects changes to the window class for some time already and has the functionality to evaluate the rules. So all there is, is one connect which improves the situation for our users, while at the same time it should be rather risk free. If a setup window rule breaks after this change it's due to the client not being ICCCM compliant. Test Plan: I don't use any of the affected applications, so it's only tested with the new added unit test. Reviewers: #kwin Subscribers: kwin Tags: #kwin Differential Revision: https://phabricator.kde.org/D16670
2018-11-04 19:23:00 +00:00
QVERIFY(windowClassChangedSpy.wait());
2022-04-23 19:51:16 +00:00
QCOMPARE(window->keepAbove(), true);
Re-evaluate the window rules when the window class of a Client changes Summary: So far KWin did not re-evaluate the window rules when the Client's window class changes. Window class is the main (static) feature the rule selection is based on. For dynamic changing mapping features like caption KWin does re-evaluate the rules. The reason for KWin to not evaluate when the class changes is that KWin expects the class not to change. From ICCCM section 4.1.2.5: > This property must be present when the window leaves the Withdrawn > state and may be changed only while the window is in the Withdrawn > state. Window managers may examine the property only when they start > up and when the window leaves the Withdrawn state, but there should be > no need for a client to change its state dynamically. Unfortunately there are prominent applications such as Spotify which violate this rule and do change the window class dynamically. While this is a clear ICCCM violation there is nothing which really forbids it (may not != must not) and nothing which forbids KWin to react on changes. As also libtaskmanager started to react on it, it makes sense to also hook up the required bits for window rules. After all KWin detects changes to the window class for some time already and has the functionality to evaluate the rules. So all there is, is one connect which improves the situation for our users, while at the same time it should be rather risk free. If a setup window rule breaks after this change it's due to the client not being ICCCM compliant. Test Plan: I don't use any of the affected applications, so it's only tested with the new added unit test. Reviewers: #kwin Subscribers: kwin Tags: #kwin Differential Revision: https://phabricator.kde.org/D16670
2018-11-04 19:23:00 +00:00
// destroy window
QSignalSpy windowClosedSpy(window, &X11Window::closed);
xcb_unmap_window(c.get(), windowId);
xcb_destroy_window(c.get(), windowId);
xcb_flush(c.get());
Re-evaluate the window rules when the window class of a Client changes Summary: So far KWin did not re-evaluate the window rules when the Client's window class changes. Window class is the main (static) feature the rule selection is based on. For dynamic changing mapping features like caption KWin does re-evaluate the rules. The reason for KWin to not evaluate when the class changes is that KWin expects the class not to change. From ICCCM section 4.1.2.5: > This property must be present when the window leaves the Withdrawn > state and may be changed only while the window is in the Withdrawn > state. Window managers may examine the property only when they start > up and when the window leaves the Withdrawn state, but there should be > no need for a client to change its state dynamically. Unfortunately there are prominent applications such as Spotify which violate this rule and do change the window class dynamically. While this is a clear ICCCM violation there is nothing which really forbids it (may not != must not) and nothing which forbids KWin to react on changes. As also libtaskmanager started to react on it, it makes sense to also hook up the required bits for window rules. After all KWin detects changes to the window class for some time already and has the functionality to evaluate the rules. So all there is, is one connect which improves the situation for our users, while at the same time it should be rather risk free. If a setup window rule breaks after this change it's due to the client not being ICCCM compliant. Test Plan: I don't use any of the affected applications, so it's only tested with the new added unit test. Reviewers: #kwin Subscribers: kwin Tags: #kwin Differential Revision: https://phabricator.kde.org/D16670
2018-11-04 19:23:00 +00:00
QVERIFY(windowClosedSpy.wait());
}
}
WAYLANDTEST_MAIN(KWin::WindowRuleTest)
#include "window_rules_test.moc"