kwin/autotests/integration/window_rules_test.cpp

252 lines
9.1 KiB
C++
Raw Normal View History

/********************************************************************
KWin - the KDE window manager
This file is part of the KDE project.
Copyright (C) 2016 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/>.
*********************************************************************/
#include "kwin_wayland_test.h"
#include "platform.h"
#include "atoms.h"
#include "x11client.h"
#include "cursor.h"
#include "deleted.h"
#include "screenedge.h"
#include "screens.h"
#include "rules.h"
#include "wayland_server.h"
#include "workspace.h"
#include "xdgshellclient.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_data();
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()
{
qRegisterMetaType<KWin::XdgShellClient *>();
qRegisterMetaType<KWin::AbstractClient*>();
qRegisterMetaType<KWin::Deleted*>();
QSignalSpy workspaceCreatedSpy(kwinApp(), &Application::workspaceCreated);
QVERIFY(workspaceCreatedSpy.isValid());
kwinApp()->platform()->setInitialWindowSize(QSize(1280, 1024));
QVERIFY(waylandServer()->init(s_socketName.toLocal8Bit()));
QMetaObject::invokeMethod(kwinApp()->platform(), "setVirtualOutputs", Qt::DirectConnection, Q_ARG(int, 2));
kwinApp()->start();
QVERIFY(workspaceCreatedSpy.wait());
QCOMPARE(screens()->count(), 2);
QCOMPARE(screens()->geometry(0), QRect(0, 0, 1280, 1024));
QCOMPARE(screens()->geometry(1), QRect(1280, 0, 1280, 1024));
setenv("QT_QPA_PLATFORM", "wayland", true);
waylandServer()->initWorkspace();
}
void WindowRuleTest::init()
{
screens()->setCurrent(0);
Cursor::setPos(QPoint(640, 512));
QVERIFY(waylandServer()->clients().isEmpty());
}
void WindowRuleTest::cleanup()
{
// discards old rules
RuleBook::self()->load();
}
struct XcbConnectionDeleter
{
static inline void cleanup(xcb_connection_t *pointer)
{
xcb_disconnect(pointer);
}
};
void WindowRuleTest::testApplyInitialMaximizeVert_data()
{
QTest::addColumn<QByteArray>("role");
QTest::newRow("lowercase") << QByteArrayLiteral("mainwindow");
QTest::newRow("CamelCase") << QByteArrayLiteral("MainWindow");
}
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
QFile ruleFile(QFINDTESTDATA("./data/rules/maximize-vert-apply-initial"));
QVERIFY(ruleFile.open(QIODevice::ReadOnly | QIODevice::Text));
QMetaObject::invokeMethod(RuleBook::self(), "temporaryRulesMessage", Q_ARG(QString, QString::fromUtf8(ruleFile.readAll())));
// create the test window
QScopedPointer<xcb_connection_t, XcbConnectionDeleter> c(xcb_connect(nullptr, nullptr));
QVERIFY(!xcb_connection_has_error(c.data()));
xcb_window_t w = xcb_generate_id(c.data());
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.data(), XCB_COPY_FROM_PARENT, w, 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.data(), w, &hints);
xcb_icccm_set_wm_class(c.data(), w, 9, "kpat\0kpat");
QFETCH(QByteArray, role);
xcb_change_property(c.data(), XCB_PROP_MODE_REPLACE, w, atoms->wm_window_role, XCB_ATOM_STRING, 8, role.length(), role.constData());
NETWinInfo info(c.data(), w, rootWindow(), NET::WMAllProperties, NET::WM2AllProperties);
info.setWindowType(NET::Normal);
xcb_map_window(c.data(), w);
xcb_flush(c.data());
QSignalSpy windowCreatedSpy(workspace(), &Workspace::clientAdded);
QVERIFY(windowCreatedSpy.isValid());
QVERIFY(windowCreatedSpy.wait());
X11Client *client = windowCreatedSpy.last().first().value<X11Client *>();
QVERIFY(client);
QVERIFY(client->isDecorated());
QVERIFY(!client->hasStrut());
QVERIFY(!client->isHiddenInternal());
QVERIFY(!client->readyForPainting());
QMetaObject::invokeMethod(client, "setReadyForPainting");
QVERIFY(client->readyForPainting());
QVERIFY(!client->surface());
QSignalSpy surfaceChangedSpy(client, &Toplevel::surfaceChanged);
QVERIFY(surfaceChangedSpy.isValid());
QVERIFY(surfaceChangedSpy.wait());
QVERIFY(client->surface());
QCOMPARE(client->maximizeMode(), MaximizeVertical);
// destroy window again
QSignalSpy windowClosedSpy(client, &X11Client::windowClosed);
QVERIFY(windowClosedSpy.isValid());
xcb_unmap_window(c.data(), w);
xcb_destroy_window(c.data(), w);
xcb_flush(c.data());
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("General").writeEntry("count", 1);
auto group = config->group("1");
group.writeEntry("above", true);
group.writeEntry("aboverule", 2);
group.writeEntry("wmclass", "org.kde.foo");
group.writeEntry("wmclasscomplete", false);
group.writeEntry("wmclassmatch", 1);
group.sync();
RuleBook::self()->setConfig(config);
workspace()->slotReconfigure();
// create the test window
QScopedPointer<xcb_connection_t, XcbConnectionDeleter> c(xcb_connect(nullptr, nullptr));
QVERIFY(!xcb_connection_has_error(c.data()));
xcb_window_t w = xcb_generate_id(c.data());
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.data(), XCB_COPY_FROM_PARENT, w, 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.data(), w, &hints);
xcb_icccm_set_wm_class(c.data(), w, 23, "org.kde.bar\0org.kde.bar");
NETWinInfo info(c.data(), w, rootWindow(), NET::WMAllProperties, NET::WM2AllProperties);
info.setWindowType(NET::Normal);
xcb_map_window(c.data(), w);
xcb_flush(c.data());
QSignalSpy windowCreatedSpy(workspace(), &Workspace::clientAdded);
QVERIFY(windowCreatedSpy.isValid());
QVERIFY(windowCreatedSpy.wait());
X11Client *client = windowCreatedSpy.last().first().value<X11Client *>();
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(client);
QVERIFY(client->isDecorated());
QVERIFY(!client->hasStrut());
QVERIFY(!client->isHiddenInternal());
QVERIFY(!client->readyForPainting());
QMetaObject::invokeMethod(client, "setReadyForPainting");
QVERIFY(client->readyForPainting());
QVERIFY(!client->surface());
QSignalSpy surfaceChangedSpy(client, &Toplevel::surfaceChanged);
QVERIFY(surfaceChangedSpy.isValid());
QVERIFY(surfaceChangedSpy.wait());
QVERIFY(client->surface());
QCOMPARE(client->keepAbove(), false);
// now change class
QSignalSpy windowClassChangedSpy{client, &X11Client::windowClassChanged};
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.isValid());
xcb_icccm_set_wm_class(c.data(), w, 23, "org.kde.foo\0org.kde.foo");
xcb_flush(c.data());
QVERIFY(windowClassChangedSpy.wait());
QCOMPARE(client->keepAbove(), true);
// destroy window
QSignalSpy windowClosedSpy(client, &X11Client::windowClosed);
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.isValid());
xcb_unmap_window(c.data(), w);
xcb_destroy_window(c.data(), w);
xcb_flush(c.data());
QVERIFY(windowClosedSpy.wait());
}
}
WAYLANDTEST_MAIN(KWin::WindowRuleTest)
#include "window_rules_test.moc"