yukijoou/kwin
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions
kwin/autotests/integration/internal_window.cpp

825 lines
27 KiB
C++
Raw Normal View History

Prettify license headers
2020-08-02 22:22:19 +00:00
/*
KWin - the KDE window manager
This file is part of the KDE project.
[autotest] Add a test for a KWin internal QWindow The test creates a QRasterWindow which through KWin's internal QPA is considered an internal window. In the test methods we simulate various pointer events (enter/leave, press/release, wheel).
2016-02-05 14:39:04 +00:00
Prettify license headers
2020-08-02 22:22:19 +00:00
SPDX-FileCopyrightText: 2016 Martin Gräßlin <mgraesslin@kde.org>
[autotest] Add a test for a KWin internal QWindow The test creates a QRasterWindow which through KWin's internal QPA is considered an internal window. In the test methods we simulate various pointer events (enter/leave, press/release, wheel).
2016-02-05 14:39:04 +00:00
Prettify license headers
2020-08-02 22:22:19 +00:00
SPDX-License-Identifier: GPL-2.0-or-later
*/
[autotest] Add a test for a KWin internal QWindow The test creates a QRasterWindow which through KWin's internal QPA is considered an internal window. In the test methods we simulate various pointer events (enter/leave, press/release, wheel).
2016-02-05 14:39:04 +00:00
#include "kwin_wayland_test.h"
Run clang-format The .clang-format file is based on the one in ECM except the following style options: - AlwaysBreakBeforeMultilineStrings - BinPackArguments - BinPackParameters - ColumnLimit - BreakBeforeBraces - KeepEmptyLinesAtTheStartOfBlocks
2022-03-23 10:13:38 +00:00
Move multi-purpose code in its own directory Things such as Output, InputDevice and so on are made to be multi-purpose. In order to make this separation more clear, this change moves that code in the core directory. Some things still link to the abstraction level above (kwin), they can be tackled in future refactors. Ideally code in core/ should depend either on other code in core/ or system libs.
2022-08-29 07:55:49 +00:00
#include "core/output.h"
Add windowsystem plugin for KWin's qpa Summary: KWindowSystem provides a plugin interface to have platform specific implementations. So far KWin relied on the implementation in KWayland-integration repository. This is something I find unsuited, for the following reasons: * any test in KWin for functionality set through the plugin would fail * it's not clear what's going on where * in worst case some code could deadlock * KWin shouldn't use KWindowSystem and only a small subset is allowed to be used The last point needs some further explanation. KWin internally does not and cannot use KWindowSystem. KWindowSystem (especially KWindowInfo) is exposing information which KWin sets. It's more than weird if KWin asks KWindowSystem for the state of a window it set itself. On X11 it's just slow, on Wayland it can result in roundtrips to KWin itself which is dangerous. But due to using Plasma components we have a few areas where we use KWindowSystem. E.g. a Plasma::Dialog sets a window type, the slide in direction, blur and background contrast. This we want to support and need to support. Other API elements we do not want, like for examples the available windows. KWin internal windows either have direct access to KWin or a scripting interface exposed providing (limited) access - there is just no need to have this in KWindowSystem. To make it more clear what KWin supports as API of KWindowSystem for internal windows this change implements a stripped down version of the kwayland-integration plugin. The main difference is that it does not use KWayland at all, but a QWindow internal side channel. To support this EffectWindow provides an accessor for internalWindow and the three already mentioned effects are adjusted to read from the internal QWindow and it's dynamic properties. This change is a first step for a further refactoring. I plan to split the internal window out of ShellClient into a dedicated class. I think there are nowadays too many special cases. If it moves out there is the question whether we really want to use Wayland for the internal windows or whether this is just historic ballast (after all we used to use qwayland for that in the beginning). As the change could introduce regressions I'm targetting 5.16. Test Plan: new test case for window type, manual testing using Alt+Tab for the effects integration. Sliding popups, blur and contrast worked fine. Reviewers: #kwin Subscribers: kwin Tags: #kwin Differential Revision: https://phabricator.kde.org/D18228
2019-01-13 16:50:32 +00:00
#include "effects.h"
Rename InternalClient to InternalWindow The word "client" means different things in wayland and kwin. Use a better word to refer to windows.
2022-04-22 17:45:19 +00:00
#include "internalwindow.h"
Port away from Cursor::setPos() Use input device specific apis to change the position of the cursor. The main reason to do so is to break the assumption that Cursor position is the same as pointer position, which I would like to rely on later to merge tablet and pointer cursors.
2023-02-09 13:07:56 +00:00
#include "pointer_input.h"
wayland: Drop "_interface" from filenames The cpp files in the wayland directory are named after protocol names. "_interface" does not contribute anything new.
2023-09-13 05:52:59 +00:00
#include "wayland/surface.h"
[autotest] Add a test for a KWin internal QWindow The test creates a QRasterWindow which through KWin's internal QPA is considered an internal window. In the test methods we simulate various pointer events (enter/leave, press/release, wheel).
2016-02-05 14:39:04 +00:00
#include "wayland_server.h"
#include "workspace.h"
#include <QPainter>
#include <QRasterWindow>
Don't use QtTest => use QTest + missing include
2023-07-03 19:28:19 +00:00
#include <QSignalSpy>
[autotest] Add a test for a KWin internal QWindow The test creates a QRasterWindow which through KWin's internal QPA is considered an internal window. In the test methods we simulate various pointer events (enter/leave, press/release, wheel).
2016-02-05 14:39:04 +00:00
[wayland] Unset focused keyboard surface when handling key event internally Summary: So far when KWin intercepted a key event a leave was not sent to the Wayland surface currently having keyboard focus. This could result in the Wayland application to start repeating keys. E.g. 1. application gets key press event 2. This triggers an internal window to show 3. key release goes to KWin internal window 4. application starts to repeat key as there is no release With this change whenever KWin intercepts the key event e.g. due to * internal window * Effects grabbing key event * Tabbox the focused keyboard surface is set to null, thus triggering a leave event and the client not starting to repeat the event. Reviewers: #kwin, #plasma_on_wayland Subscribers: plasma-devel, kwin Tags: #plasma_on_wayland, #kwin Differential Revision: https://phabricator.kde.org/D2402
2016-08-11 09:17:09 +00:00
#include <KWayland/Client/keyboard.h>
#include <KWayland/Client/seat.h>
Run clang-format The .clang-format file is based on the one in ECM except the following style options: - AlwaysBreakBeforeMultilineStrings - BinPackArguments - BinPackParameters - ColumnLimit - BreakBeforeBraces - KeepEmptyLinesAtTheStartOfBlocks
2022-03-23 10:13:38 +00:00
#include <KWayland/Client/surface.h>
Add windowsystem plugin for KWin's qpa Summary: KWindowSystem provides a plugin interface to have platform specific implementations. So far KWin relied on the implementation in KWayland-integration repository. This is something I find unsuited, for the following reasons: * any test in KWin for functionality set through the plugin would fail * it's not clear what's going on where * in worst case some code could deadlock * KWin shouldn't use KWindowSystem and only a small subset is allowed to be used The last point needs some further explanation. KWin internally does not and cannot use KWindowSystem. KWindowSystem (especially KWindowInfo) is exposing information which KWin sets. It's more than weird if KWin asks KWindowSystem for the state of a window it set itself. On X11 it's just slow, on Wayland it can result in roundtrips to KWin itself which is dangerous. But due to using Plasma components we have a few areas where we use KWindowSystem. E.g. a Plasma::Dialog sets a window type, the slide in direction, blur and background contrast. This we want to support and need to support. Other API elements we do not want, like for examples the available windows. KWin internal windows either have direct access to KWin or a scripting interface exposed providing (limited) access - there is just no need to have this in KWindowSystem. To make it more clear what KWin supports as API of KWindowSystem for internal windows this change implements a stripped down version of the kwayland-integration plugin. The main difference is that it does not use KWayland at all, but a QWindow internal side channel. To support this EffectWindow provides an accessor for internalWindow and the three already mentioned effects are adjusted to read from the internal QWindow and it's dynamic properties. This change is a first step for a further refactoring. I plan to split the internal window out of ShellClient into a dedicated class. I think there are nowadays too many special cases. If it moves out there is the question whether we really want to use Wayland for the internal windows or whether this is just historic ballast (after all we used to use qwayland for that in the beginning). As the change could introduce regressions I'm targetting 5.16. Test Plan: new test case for window type, manual testing using Alt+Tab for the effects integration. Sliding popups, blur and contrast worked fine. Reviewers: #kwin Subscribers: kwin Tags: #kwin Differential Revision: https://phabricator.kde.org/D18228
2019-01-13 16:50:32 +00:00
#include <KWindowSystem>
[wayland] Unset focused keyboard surface when handling key event internally Summary: So far when KWin intercepted a key event a leave was not sent to the Wayland surface currently having keyboard focus. This could result in the Wayland application to start repeating keys. E.g. 1. application gets key press event 2. This triggers an internal window to show 3. key release goes to KWin internal window 4. application starts to repeat key as there is no release With this change whenever KWin intercepts the key event e.g. due to * internal window * Effects grabbing key event * Tabbox the focused keyboard surface is set to null, thus triggering a leave event and the client not starting to repeat the event. Reviewers: #kwin, #plasma_on_wayland Subscribers: plasma-devel, kwin Tags: #plasma_on_wayland, #kwin Differential Revision: https://phabricator.kde.org/D2402
2016-08-11 09:17:09 +00:00
[autotest] Add a test for a KWin internal QWindow The test creates a QRasterWindow which through KWin's internal QPA is considered an internal window. In the test methods we simulate various pointer events (enter/leave, press/release, wheel).
2016-02-05 14:39:04 +00:00
#include <linux/input.h>
Add windowsystem plugin for KWin's qpa Summary: KWindowSystem provides a plugin interface to have platform specific implementations. So far KWin relied on the implementation in KWayland-integration repository. This is something I find unsuited, for the following reasons: * any test in KWin for functionality set through the plugin would fail * it's not clear what's going on where * in worst case some code could deadlock * KWin shouldn't use KWindowSystem and only a small subset is allowed to be used The last point needs some further explanation. KWin internally does not and cannot use KWindowSystem. KWindowSystem (especially KWindowInfo) is exposing information which KWin sets. It's more than weird if KWin asks KWindowSystem for the state of a window it set itself. On X11 it's just slow, on Wayland it can result in roundtrips to KWin itself which is dangerous. But due to using Plasma components we have a few areas where we use KWindowSystem. E.g. a Plasma::Dialog sets a window type, the slide in direction, blur and background contrast. This we want to support and need to support. Other API elements we do not want, like for examples the available windows. KWin internal windows either have direct access to KWin or a scripting interface exposed providing (limited) access - there is just no need to have this in KWindowSystem. To make it more clear what KWin supports as API of KWindowSystem for internal windows this change implements a stripped down version of the kwayland-integration plugin. The main difference is that it does not use KWayland at all, but a QWindow internal side channel. To support this EffectWindow provides an accessor for internalWindow and the three already mentioned effects are adjusted to read from the internal QWindow and it's dynamic properties. This change is a first step for a further refactoring. I plan to split the internal window out of ShellClient into a dedicated class. I think there are nowadays too many special cases. If it moves out there is the question whether we really want to use Wayland for the internal windows or whether this is just historic ballast (after all we used to use qwayland for that in the beginning). As the change could introduce regressions I'm targetting 5.16. Test Plan: new test case for window type, manual testing using Alt+Tab for the effects integration. Sliding popups, blur and contrast worked fine. Reviewers: #kwin Subscribers: kwin Tags: #kwin Differential Revision: https://phabricator.kde.org/D18228
2019-01-13 16:50:32 +00:00
Q_DECLARE_METATYPE(NET::WindowType);
[autotest] Add a test for a KWin internal QWindow The test creates a QRasterWindow which through KWin's internal QPA is considered an internal window. In the test methods we simulate various pointer events (enter/leave, press/release, wheel).
2016-02-05 14:39:04 +00:00
namespace KWin
{
static const QString s_socketName = QStringLiteral("wayland_test_kwin_internal_window-0");
class InternalWindowTest : public QObject
{
Q_OBJECT
private Q_SLOTS:
void initTestCase();
void init();
[wayland] Unset focused keyboard surface when handling key event internally Summary: So far when KWin intercepted a key event a leave was not sent to the Wayland surface currently having keyboard focus. This could result in the Wayland application to start repeating keys. E.g. 1. application gets key press event 2. This triggers an internal window to show 3. key release goes to KWin internal window 4. application starts to repeat key as there is no release With this change whenever KWin intercepts the key event e.g. due to * internal window * Effects grabbing key event * Tabbox the focused keyboard surface is set to null, thus triggering a leave event and the client not starting to repeat the event. Reviewers: #kwin, #plasma_on_wayland Subscribers: plasma-devel, kwin Tags: #plasma_on_wayland, #kwin Differential Revision: https://phabricator.kde.org/D2402
2016-08-11 09:17:09 +00:00
void cleanup();
[autotest] Add a test for a KWin internal QWindow The test creates a QRasterWindow which through KWin's internal QPA is considered an internal window. In the test methods we simulate various pointer events (enter/leave, press/release, wheel).
2016-02-05 14:39:04 +00:00
void testEnterLeave();
void testPointerPressRelease();
void testPointerAxis();
Improve keyboard handling for internal windows So far the key handler in the InternalWindowEventFilter used the PointerInputRedirection's internal window. This had the result that key events were only delivered to an internal window if the window was under the cursor. This change tries sending the event to the latest created and visible window. Thus e.g. with nested context menus it goes to the current sub menu as expected. The return value of sendEvent is used to filter out the event.
2016-02-17 12:34:24 +00:00
void testKeyboard_data();
[autotests] Test case for key events on internal windows
2016-02-08 14:03:21 +00:00
void testKeyboard();
DebugConsole window does not take keyboard input Summary: In order to add more tabs which can further help monitoring how KWin handles some aspects the DebugConsole is changed to not take keyboard input. This means it can only be navigated using pointer device or touch screen. This is needed for adding a new tab to monitor clipboard changes. On Wayland sometimes windows don't get the clipboard, so it would be helpful to have a debug monitor to see when the clipboard changes. But for that debug console window may not take keyboard events. To support this DebugConsole sets the WA_ShowWithoutActivating attribute which gets honored by the InternalWindowEventFilter and does not forward key events to such windows. Reviewers: #kwin, #plasma_on_wayland Subscribers: plasma-devel, kwin Tags: #plasma_on_wayland, #kwin Differential Revision: https://phabricator.kde.org/D2620
2016-08-29 13:34:02 +00:00
void testKeyboardShowWithoutActivating();
[autotests/integration] Split InternalWindowTest::testKeyboard into two test methods Creating a dedicated method for the leave event on client. This restructuring of the test should hopefully work around the failing test condition on build.kde.org.
2016-08-16 13:39:47 +00:00
void testKeyboardTriggersLeave();
Support touch events on KWin internal windows Summary: Qt's touch event API is rather difficult and complex to implement. As none of KWin's internal windows supports multi-touch gestures yet, this is going the easy route and just simulates a left mouse button press. If in future need arises for touch gesture support on KWin's internal windows, this can be added. Test Plan: Tested on exopc with DebugConsole and auto test Reviewers: #plasma Subscribers: plasma-devel Tags: #plasma Differential Revision: https://phabricator.kde.org/D1661
2016-05-23 15:07:08 +00:00
void testTouch();
Sync opacity from an internal QWindow to its ShellClient Summary: This change adds support for opacity on a KWin internal QWindow. Calling QWindow::setOpacity syncs the value to the ShellClient representation of the QWindow. This is needed for fading out the OnScreenNotification on mouse over. Test Plan: Added auto test and manual test Reviewers: #kwin, #plasma_on_wayland Subscribers: plasma-devel, kwin Tags: #plasma_on_wayland, #kwin Differential Revision: https://phabricator.kde.org/D3928
2017-01-03 06:28:29 +00:00
void testOpacity();
Fix syncing of geometry to internal window when using ::move Summary: The OnScreenNotification gets moved during its placement. This update of the geometry did not get synced to the QWindow's geometry as it should. The reason for this is the rather special implementation of AbstractClient::move. This just modifies the geom variable and does not call into setGeometry at all. Instead a virtual doMove method is invoked to inform the platform specific client implementation about the move of the window. For a "normal" ShellClient that is fine - there is nothing to do. This change adds an implementation of doMove in ShellClient to sync the geometry to the internal window. This is not yet enough to fix the geometry of the OnScreenNotification. It gets placed with a GeometryUpdatesBlocker in place causing the doMove never to be called. Instead setGeometry is invoked again when the geometry updates get unblocked. So far ShellClient did not do anything in this case. This change ensures that at least the doSetGeometry method is performed again. Test Plan: Added test case and manual testing of OnScreenNotification Reviewers: #kwin, #plasma_on_wayland Subscribers: plasma-devel, kwin Tags: #plasma_on_wayland, #kwin Differential Revision: https://phabricator.kde.org/D3963
2017-01-04 16:53:46 +00:00
void testMove();
Add support for skipCloseAnimation for internal windows Summary: We need this to use the new OnScreenNotification in the screenshot effect. Reviewers: #kwin, #plasma_on_wayland Subscribers: plasma-devel, kwin Tags: #plasma_on_wayland, #kwin Differential Revision: https://phabricator.kde.org/D4089
2017-01-11 19:00:40 +00:00
void testSkipCloseAnimation_data();
void testSkipCloseAnimation();
Support modifier mouse/scroll action on internal decorated windows Summary: This fixes the problem that alt+lmb did not start unrestricted move resize for the Debug Console. BUG: 374880 FIXED-IN: 5.12.3 Test Plan: New test case and manual testing whether alt+lmb/rmb works Reviewers: #kwin, #plasma Subscribers: plasma-devel, kwin Tags: #plasma Differential Revision: https://phabricator.kde.org/D10440
2018-02-11 09:49:31 +00:00
void testModifierClickUnrestrictedMove();
void testModifierScroll();
Implement isPopupWindow for internal windows Summary: Just accessing Qt::Popup WindowFlag. BUG: 402852 Test Plan: Not tested for the described problematic case Reviewers: #kwin Subscribers: kwin Tags: #kwin Differential Revision: https://phabricator.kde.org/D17981
2019-01-05 10:10:33 +00:00
void testPopup();
Add high DPI support to internal KWin windows Summary: So far we didn't try to do high DPI on kwin internal windows, such as the user context menu and tab bars and whatever. Due to wayland scaling they were the correct phyiscal size but upscaled. This patch fixes our QPA to enable Qt's high-dpi support. BUG: 402853 Note icons are still low res. This is because the global QGuiApplication::devicePixelRatio which is the max of all connected screens is static for the duration of the app. QIcon uses this when determining the DPR to use. This will require a Qt change. Test Plan: Ran at 2x on my normal DPI screen (as that's easier to see anything) * User action menu is high DPI * Window deco tooltips are still fine * Tab switcher is high DPI * Overlay in present windows Desktop grid are still ok Reviewers: #kwin Subscribers: zzag, kwin Tags: #kwin Differential Revision: https://phabricator.kde.org/D18042
2019-01-11 22:48:04 +00:00
void testScale();
Add windowsystem plugin for KWin's qpa Summary: KWindowSystem provides a plugin interface to have platform specific implementations. So far KWin relied on the implementation in KWayland-integration repository. This is something I find unsuited, for the following reasons: * any test in KWin for functionality set through the plugin would fail * it's not clear what's going on where * in worst case some code could deadlock * KWin shouldn't use KWindowSystem and only a small subset is allowed to be used The last point needs some further explanation. KWin internally does not and cannot use KWindowSystem. KWindowSystem (especially KWindowInfo) is exposing information which KWin sets. It's more than weird if KWin asks KWindowSystem for the state of a window it set itself. On X11 it's just slow, on Wayland it can result in roundtrips to KWin itself which is dangerous. But due to using Plasma components we have a few areas where we use KWindowSystem. E.g. a Plasma::Dialog sets a window type, the slide in direction, blur and background contrast. This we want to support and need to support. Other API elements we do not want, like for examples the available windows. KWin internal windows either have direct access to KWin or a scripting interface exposed providing (limited) access - there is just no need to have this in KWindowSystem. To make it more clear what KWin supports as API of KWindowSystem for internal windows this change implements a stripped down version of the kwayland-integration plugin. The main difference is that it does not use KWayland at all, but a QWindow internal side channel. To support this EffectWindow provides an accessor for internalWindow and the three already mentioned effects are adjusted to read from the internal QWindow and it's dynamic properties. This change is a first step for a further refactoring. I plan to split the internal window out of ShellClient into a dedicated class. I think there are nowadays too many special cases. If it moves out there is the question whether we really want to use Wayland for the internal windows or whether this is just historic ballast (after all we used to use qwayland for that in the beginning). As the change could introduce regressions I'm targetting 5.16. Test Plan: new test case for window type, manual testing using Alt+Tab for the effects integration. Sliding popups, blur and contrast worked fine. Reviewers: #kwin Subscribers: kwin Tags: #kwin Differential Revision: https://phabricator.kde.org/D18228
2019-01-13 16:50:32 +00:00
void testWindowType_data();
void testWindowType();
void testChangeWindowType_data();
void testChangeWindowType();
void testEffectWindow();
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 testReentrantMoveResize();
wayland: Introduce internal popup event filter The event filter allows dismissing the user actions menu by clicking anywhere outside of it. BUG: 428408
2021-01-30 20:29:55 +00:00
void testDismissPopup();
[autotest] Add a test for a KWin internal QWindow The test creates a QRasterWindow which through KWin's internal QPA is considered an internal window. In the test methods we simulate various pointer events (enter/leave, press/release, wheel).
2016-02-05 14:39:04 +00:00
};
class HelperWindow : public QRasterWindow
{
Q_OBJECT
public:
HelperWindow();
Run clang-tidy with modernize-use-override check Summary: Currently code base of kwin can be viewed as two pieces. One is very ancient, and the other one is more modern, which uses new C++ features. The main problem with the ancient code is that it was written before C++11 era. So, no override or final keywords, lambdas, etc. Quite recently, KDE compiler settings were changed to show a warning if a virtual method has missing override keyword. As you might have already guessed, this fired back at us because of that ancient code. We had about 500 new compiler warnings. A "solution" was proposed to that problem - disable -Wno-suggest-override and the other similar warning for clang. It's hard to call a solution because those warnings are disabled not only for the old code, but also for new. This is not what we want! The main argument for not actually fixing the problem was that git history will be screwed as well because of human factor. While good git history is a very important thing, we should not go crazy about it and block every change that somehow alters git history. git blame allows to specify starting revision for a reason. The other argument (human factor) can be easily solved by using tools such as clang-tidy. clang-tidy is a clang-based linter for C++. It can be used for various things, e.g. fixing coding style(e.g. add missing braces to if statements, readability-braces-around-statements check), or in our case add missing override keywords. Test Plan: Compiles. Reviewers: #kwin, davidedmundson Reviewed By: #kwin, davidedmundson Subscribers: davidedmundson, apol, romangg, kwin Tags: #kwin Differential Revision: https://phabricator.kde.org/D22371
2019-07-22 16:52:26 +00:00
~HelperWindow() override;
[autotest] Add a test for a KWin internal QWindow The test creates a QRasterWindow which through KWin's internal QPA is considered an internal window. In the test methods we simulate various pointer events (enter/leave, press/release, wheel).
2016-02-05 14:39:04 +00:00
Run clang-format The .clang-format file is based on the one in ECM except the following style options: - AlwaysBreakBeforeMultilineStrings - BinPackArguments - BinPackParameters - ColumnLimit - BreakBeforeBraces - KeepEmptyLinesAtTheStartOfBlocks
2022-03-23 10:13:38 +00:00
QPoint latestGlobalMousePos() const
{
Support touch events on KWin internal windows Summary: Qt's touch event API is rather difficult and complex to implement. As none of KWin's internal windows supports multi-touch gestures yet, this is going the easy route and just simulates a left mouse button press. If in future need arises for touch gesture support on KWin's internal windows, this can be added. Test Plan: Tested on exopc with DebugConsole and auto test Reviewers: #plasma Subscribers: plasma-devel Tags: #plasma Differential Revision: https://phabricator.kde.org/D1661
2016-05-23 15:07:08 +00:00
return m_latestGlobalMousePos;
}
Run clang-format The .clang-format file is based on the one in ECM except the following style options: - AlwaysBreakBeforeMultilineStrings - BinPackArguments - BinPackParameters - ColumnLimit - BreakBeforeBraces - KeepEmptyLinesAtTheStartOfBlocks
2022-03-23 10:13:38 +00:00
Qt::MouseButtons pressedButtons() const
{
Support touch events on KWin internal windows Summary: Qt's touch event API is rather difficult and complex to implement. As none of KWin's internal windows supports multi-touch gestures yet, this is going the easy route and just simulates a left mouse button press. If in future need arises for touch gesture support on KWin's internal windows, this can be added. Test Plan: Tested on exopc with DebugConsole and auto test Reviewers: #plasma Subscribers: plasma-devel Tags: #plasma Differential Revision: https://phabricator.kde.org/D1661
2016-05-23 15:07:08 +00:00
return m_pressedButtons;
}
[autotest] Add a test for a KWin internal QWindow The test creates a QRasterWindow which through KWin's internal QPA is considered an internal window. In the test methods we simulate various pointer events (enter/leave, press/release, wheel).
2016-02-05 14:39:04 +00:00
Q_SIGNALS:
void entered();
void left();
void mouseMoved(const QPoint &global);
void mousePressed();
void mouseReleased();
void wheel();
[autotests] Test case for key events on internal windows
2016-02-08 14:03:21 +00:00
void keyPressed();
void keyReleased();
[autotest] Add a test for a KWin internal QWindow The test creates a QRasterWindow which through KWin's internal QPA is considered an internal window. In the test methods we simulate various pointer events (enter/leave, press/release, wheel).
2016-02-05 14:39:04 +00:00
protected:
void paintEvent(QPaintEvent *event) override;
bool event(QEvent *event) override;
void mouseMoveEvent(QMouseEvent *event) override;
void mousePressEvent(QMouseEvent *event) override;
void mouseReleaseEvent(QMouseEvent *event) override;
void wheelEvent(QWheelEvent *event) override;
[autotests] Test case for key events on internal windows
2016-02-08 14:03:21 +00:00
void keyPressEvent(QKeyEvent *event) override;
void keyReleaseEvent(QKeyEvent *event) override;
Support touch events on KWin internal windows Summary: Qt's touch event API is rather difficult and complex to implement. As none of KWin's internal windows supports multi-touch gestures yet, this is going the easy route and just simulates a left mouse button press. If in future need arises for touch gesture support on KWin's internal windows, this can be added. Test Plan: Tested on exopc with DebugConsole and auto test Reviewers: #plasma Subscribers: plasma-devel Tags: #plasma Differential Revision: https://phabricator.kde.org/D1661
2016-05-23 15:07:08 +00:00
private:
QPoint m_latestGlobalMousePos;
Qt::MouseButtons m_pressedButtons = Qt::MouseButtons();
[autotest] Add a test for a KWin internal QWindow The test creates a QRasterWindow which through KWin's internal QPA is considered an internal window. In the test methods we simulate various pointer events (enter/leave, press/release, wheel).
2016-02-05 14:39:04 +00:00
};
HelperWindow::HelperWindow()
: QRasterWindow(nullptr)
{
[Wayland] Make it possible to have internal windows decorated Summary: With this change KWin can create window decorations for internal windows. Thus it's also possible to move internal windows and resize them which is especially important for the debug console. Reviewers: #kwin, #plasma_on_wayland, sebas Subscribers: plasma-devel, kwin Tags: #plasma_on_wayland, #kwin Differential Revision: https://phabricator.kde.org/D2371
2016-05-09 12:48:10 +00:00
setFlags(Qt::FramelessWindowHint);
[autotest] Add a test for a KWin internal QWindow The test creates a QRasterWindow which through KWin's internal QPA is considered an internal window. In the test methods we simulate various pointer events (enter/leave, press/release, wheel).
2016-02-05 14:39:04 +00:00
}
HelperWindow::~HelperWindow() = default;
void HelperWindow::paintEvent(QPaintEvent *event)
{
QPainter p(this);
p.fillRect(0, 0, width(), height(), Qt::red);
}
bool HelperWindow::event(QEvent *event)
{
if (event->type() == QEvent::Enter) {
Run clazy with qt-keywords fixit In C++20, there will be emit() class member, which can conflict with the emit keyword. Given that, there are plans to enable QT_NO_KEYWORDS by default in the future. See also https://lists.qt-project.org/pipermail/development/2020-February/038812.html
2021-06-08 07:02:14 +00:00
Q_EMIT entered();
[autotest] Add a test for a KWin internal QWindow The test creates a QRasterWindow which through KWin's internal QPA is considered an internal window. In the test methods we simulate various pointer events (enter/leave, press/release, wheel).
2016-02-05 14:39:04 +00:00
}
if (event->type() == QEvent::Leave) {
Run clazy with qt-keywords fixit In C++20, there will be emit() class member, which can conflict with the emit keyword. Given that, there are plans to enable QT_NO_KEYWORDS by default in the future. See also https://lists.qt-project.org/pipermail/development/2020-February/038812.html
2021-06-08 07:02:14 +00:00
Q_EMIT left();
[autotest] Add a test for a KWin internal QWindow The test creates a QRasterWindow which through KWin's internal QPA is considered an internal window. In the test methods we simulate various pointer events (enter/leave, press/release, wheel).
2016-02-05 14:39:04 +00:00
}
return QRasterWindow::event(event);
}
void HelperWindow::mouseMoveEvent(QMouseEvent *event)
{
Support touch events on KWin internal windows Summary: Qt's touch event API is rather difficult and complex to implement. As none of KWin's internal windows supports multi-touch gestures yet, this is going the easy route and just simulates a left mouse button press. If in future need arises for touch gesture support on KWin's internal windows, this can be added. Test Plan: Tested on exopc with DebugConsole and auto test Reviewers: #plasma Subscribers: plasma-devel Tags: #plasma Differential Revision: https://phabricator.kde.org/D1661
2016-05-23 15:07:08 +00:00
m_latestGlobalMousePos = event->globalPos();
Run clazy with qt-keywords fixit In C++20, there will be emit() class member, which can conflict with the emit keyword. Given that, there are plans to enable QT_NO_KEYWORDS by default in the future. See also https://lists.qt-project.org/pipermail/development/2020-February/038812.html
2021-06-08 07:02:14 +00:00
Q_EMIT mouseMoved(event->globalPos());
[autotest] Add a test for a KWin internal QWindow The test creates a QRasterWindow which through KWin's internal QPA is considered an internal window. In the test methods we simulate various pointer events (enter/leave, press/release, wheel).
2016-02-05 14:39:04 +00:00
}
void HelperWindow::mousePressEvent(QMouseEvent *event)
{
Support touch events on KWin internal windows Summary: Qt's touch event API is rather difficult and complex to implement. As none of KWin's internal windows supports multi-touch gestures yet, this is going the easy route and just simulates a left mouse button press. If in future need arises for touch gesture support on KWin's internal windows, this can be added. Test Plan: Tested on exopc with DebugConsole and auto test Reviewers: #plasma Subscribers: plasma-devel Tags: #plasma Differential Revision: https://phabricator.kde.org/D1661
2016-05-23 15:07:08 +00:00
m_latestGlobalMousePos = event->globalPos();
m_pressedButtons = event->buttons();
Run clazy with qt-keywords fixit In C++20, there will be emit() class member, which can conflict with the emit keyword. Given that, there are plans to enable QT_NO_KEYWORDS by default in the future. See also https://lists.qt-project.org/pipermail/development/2020-February/038812.html
2021-06-08 07:02:14 +00:00
Q_EMIT mousePressed();
[autotest] Add a test for a KWin internal QWindow The test creates a QRasterWindow which through KWin's internal QPA is considered an internal window. In the test methods we simulate various pointer events (enter/leave, press/release, wheel).
2016-02-05 14:39:04 +00:00
}
void HelperWindow::mouseReleaseEvent(QMouseEvent *event)
{
Support touch events on KWin internal windows Summary: Qt's touch event API is rather difficult and complex to implement. As none of KWin's internal windows supports multi-touch gestures yet, this is going the easy route and just simulates a left mouse button press. If in future need arises for touch gesture support on KWin's internal windows, this can be added. Test Plan: Tested on exopc with DebugConsole and auto test Reviewers: #plasma Subscribers: plasma-devel Tags: #plasma Differential Revision: https://phabricator.kde.org/D1661
2016-05-23 15:07:08 +00:00
m_latestGlobalMousePos = event->globalPos();
m_pressedButtons = event->buttons();
Run clazy with qt-keywords fixit In C++20, there will be emit() class member, which can conflict with the emit keyword. Given that, there are plans to enable QT_NO_KEYWORDS by default in the future. See also https://lists.qt-project.org/pipermail/development/2020-February/038812.html
2021-06-08 07:02:14 +00:00
Q_EMIT mouseReleased();
[autotest] Add a test for a KWin internal QWindow The test creates a QRasterWindow which through KWin's internal QPA is considered an internal window. In the test methods we simulate various pointer events (enter/leave, press/release, wheel).
2016-02-05 14:39:04 +00:00
}
void HelperWindow::wheelEvent(QWheelEvent *event)
{
Run clazy with qt-keywords fixit In C++20, there will be emit() class member, which can conflict with the emit keyword. Given that, there are plans to enable QT_NO_KEYWORDS by default in the future. See also https://lists.qt-project.org/pipermail/development/2020-February/038812.html
2021-06-08 07:02:14 +00:00
Q_EMIT wheel();
[autotest] Add a test for a KWin internal QWindow The test creates a QRasterWindow which through KWin's internal QPA is considered an internal window. In the test methods we simulate various pointer events (enter/leave, press/release, wheel).
2016-02-05 14:39:04 +00:00
}
[autotests] Test case for key events on internal windows
2016-02-08 14:03:21 +00:00
void HelperWindow::keyPressEvent(QKeyEvent *event)
{
Run clazy with qt-keywords fixit In C++20, there will be emit() class member, which can conflict with the emit keyword. Given that, there are plans to enable QT_NO_KEYWORDS by default in the future. See also https://lists.qt-project.org/pipermail/development/2020-February/038812.html
2021-06-08 07:02:14 +00:00
Q_EMIT keyPressed();
[autotests] Test case for key events on internal windows
2016-02-08 14:03:21 +00:00
}
void HelperWindow::keyReleaseEvent(QKeyEvent *event)
{
Run clazy with qt-keywords fixit In C++20, there will be emit() class member, which can conflict with the emit keyword. Given that, there are plans to enable QT_NO_KEYWORDS by default in the future. See also https://lists.qt-project.org/pipermail/development/2020-February/038812.html
2021-06-08 07:02:14 +00:00
Q_EMIT keyReleased();
[autotests] Test case for key events on internal windows
2016-02-08 14:03:21 +00:00
}
[autotest] Add a test for a KWin internal QWindow The test creates a QRasterWindow which through KWin's internal QPA is considered an internal window. In the test methods we simulate various pointer events (enter/leave, press/release, wheel).
2016-02-05 14:39:04 +00:00
void InternalWindowTest::initTestCase()
{
Rename AbstractClient to Window
2022-04-22 17:39:12 +00:00
qRegisterMetaType<KWin::Window *>();
Rename InternalClient to InternalWindow The word "client" means different things in wayland and kwin. Use a better word to refer to windows.
2022-04-22 17:45:19 +00:00
qRegisterMetaType<KWin::InternalWindow *>();
Introduce started signal in Application The new signal is emitted when the Application has fully been initialized. It allows us to change the startup sequence, for example create workspace before starting the Xwayland server, without making any adjustments in our test suit.
2020-07-07 09:32:29 +00:00
QSignalSpy applicationStartedSpy(kwinApp(), &Application::started);
Avoid converting socket name between QString and QByteArray back and forth It only contributes overhead.
2020-12-09 13:06:15 +00:00
QVERIFY(waylandServer()->init(s_socketName));
autotests: directly call setVirtualOutputs
2023-05-08 10:16:00 +00:00
Test::setOutputConfig({
QRect(0, 0, 1280, 1024),
QRect(1280, 0, 1280, 1024),
});
Support modifier mouse/scroll action on internal decorated windows Summary: This fixes the problem that alt+lmb did not start unrestricted move resize for the Debug Console. BUG: 374880 FIXED-IN: 5.12.3 Test Plan: New test case and manual testing whether alt+lmb/rmb works Reviewers: #kwin, #plasma Subscribers: plasma-devel, kwin Tags: #plasma Differential Revision: https://phabricator.kde.org/D10440
2018-02-11 09:49:31 +00:00
kwinApp()->setConfig(KSharedConfig::openConfig(QString(), KConfig::SimpleConfig));
[autotest] Add a test for a KWin internal QWindow The test creates a QRasterWindow which through KWin's internal QPA is considered an internal window. In the test methods we simulate various pointer events (enter/leave, press/release, wheel).
2016-02-05 14:39:04 +00:00
kwinApp()->start();
Introduce started signal in Application The new signal is emitted when the Application has fully been initialized. It allows us to change the startup sequence, for example create workspace before starting the Xwayland server, without making any adjustments in our test suit.
2020-07-07 09:32:29 +00:00
QVERIFY(applicationStartedSpy.wait());
Make Workspace track managed outputs This change adjusts the window management abstractions in kwin for the drm backend providing more than just "desktop" outputs. Besides that, it has other potential benefits - for example, the Workspace could start managing allocation of the placeholder output by itself, thus leading to some simplifications in the drm backend. Another is that it lets us move wayland code from the drm backend.
2022-07-11 10:41:15 +00:00
const auto outputs = workspace()->outputs();
autotests: Port common screen check preamble to AbstractOutput
2021-08-31 07:03:05 +00:00
QCOMPARE(outputs.count(), 2);
QCOMPARE(outputs[0]->geometry(), QRect(0, 0, 1280, 1024));
QCOMPARE(outputs[1]->geometry(), QRect(1280, 0, 1280, 1024));
[autotest] Add a test for a KWin internal QWindow The test creates a QRasterWindow which through KWin's internal QPA is considered an internal window. In the test methods we simulate various pointer events (enter/leave, press/release, wheel).
2016-02-05 14:39:04 +00:00
}
void InternalWindowTest::init()
{
Port away from Cursor::setPos() Use input device specific apis to change the position of the cursor. The main reason to do so is to break the assumption that Cursor position is the same as pointer position, which I would like to rely on later to merge tablet and pointer cursors.
2023-02-09 13:07:56 +00:00
input()->pointer()->warp(QPoint(512, 512));
[autotests/integration] Use socketpair for Wayland connection Summary: This is a preparation step for no longer creating a socket in the tests and slightly simplifies the init test code. Reviewers: #kwin, #plasma_on_wayland Subscribers: plasma-devel, kwin Tags: #plasma_on_wayland, #kwin Differential Revision: https://phabricator.kde.org/D3575
2016-12-03 13:31:14 +00:00
QVERIFY(Test::setupWaylandConnection(Test::AdditionalWaylandInterface::Seat));
[wayland] Unset focused keyboard surface when handling key event internally Summary: So far when KWin intercepted a key event a leave was not sent to the Wayland surface currently having keyboard focus. This could result in the Wayland application to start repeating keys. E.g. 1. application gets key press event 2. This triggers an internal window to show 3. key release goes to KWin internal window 4. application starts to repeat key as there is no release With this change whenever KWin intercepts the key event e.g. due to * internal window * Effects grabbing key event * Tabbox the focused keyboard surface is set to null, thus triggering a leave event and the client not starting to repeat the event. Reviewers: #kwin, #plasma_on_wayland Subscribers: plasma-devel, kwin Tags: #plasma_on_wayland, #kwin Differential Revision: https://phabricator.kde.org/D2402
2016-08-11 09:17:09 +00:00
QVERIFY(Test::waitForWaylandKeyboard());
}
void InternalWindowTest::cleanup()
{
Test::destroyWaylandConnection();
[autotest] Add a test for a KWin internal QWindow The test creates a QRasterWindow which through KWin's internal QPA is considered an internal window. In the test methods we simulate various pointer events (enter/leave, press/release, wheel).
2016-02-05 14:39:04 +00:00
}
void InternalWindowTest::testEnterLeave()
{
Make Workspace::allClientList() return all windows Currently windows are scattered in a few separate lists. If you need to go through the windows, you have to do it piece by piece. On the other hand, with the overhaul of window types, we've started converging towards one universal type: Window. Keeping windows in the separate buckets goes against this design. Workspace::stackingOrder() already contains all windows. This change repurposes Workspace::allClientList() from a list of "normal" windows to all windows, i.e. Workspace::windows(), to be consistent. There's one API change though. Scripting API will expose other window types too. This is an intentional change so scripted effects could operate with all windows. It also matches the current behavior observed in libkwineffects, which exposes all windows as well.
2023-03-13 11:54:38 +00:00
QSignalSpy windowAddedSpy(workspace(), &Workspace::windowAdded);
[autotest] Add a test for a KWin internal QWindow The test creates a QRasterWindow which through KWin's internal QPA is considered an internal window. In the test methods we simulate various pointer events (enter/leave, press/release, wheel).
2016-02-05 14:39:04 +00:00
HelperWindow win;
Port QPA away from Wayland Summary: So far wayland was used by internal clients to submit raster buffers and position themselves on the screen. While we didn't have issues with submitting raster buffers, there were some problems with positioning task switchers. Mostly, because we had effectively two paths that may alter geometry. A better approach to deal with internal clients is to let our QPA use kwin core api directly. This way we can eliminate unnecessary roundtrips as well make geometry handling much easier and comprehensible. The last missing piece is shadows. Both Plasma::Dialog and Breeze widget style use platform-specific APIs to set and unset shadows. We need to add shadows API to KWindowSystem. Even though some internal clients lack drop-shadows at the moment, I don't consider it to be a blocker. We can add shadows back later on. CCBUG: 386304 Reviewers: #kwin, davidedmundson, romangg Reviewed By: #kwin, romangg Subscribers: romangg, kwin Tags: #kwin Maniphest Tasks: T9600 Differential Revision: https://phabricator.kde.org/D22810
2019-08-26 07:44:04 +00:00
QVERIFY(!workspace()->findInternal(nullptr));
QVERIFY(!workspace()->findInternal(&win));
[autotest] Add a test for a KWin internal QWindow The test creates a QRasterWindow which through KWin's internal QPA is considered an internal window. In the test methods we simulate various pointer events (enter/leave, press/release, wheel).
2016-02-05 14:39:04 +00:00
win.setGeometry(0, 0, 100, 100);
win.show();
Prefer the term "window" over "client" in Workspace
2022-04-23 08:33:23 +00:00
QTRY_COMPARE(windowAddedSpy.count(), 1);
QVERIFY(!workspace()->activeWindow());
autotests: client -> window
2022-04-23 19:51:16 +00:00
InternalWindow *window = windowAddedSpy.first().first().value<InternalWindow *>();
QVERIFY(window);
QVERIFY(window->isInternal());
QVERIFY(!window->isDecorated());
QCOMPARE(workspace()->findInternal(&win), window);
QCOMPARE(window->frameGeometry(), QRect(0, 0, 100, 100));
QVERIFY(window->isShown());
QVERIFY(workspace()->stackingOrder().contains(window));
[autotest] Add a test for a KWin internal QWindow The test creates a QRasterWindow which through KWin's internal QPA is considered an internal window. In the test methods we simulate various pointer events (enter/leave, press/release, wheel).
2016-02-05 14:39:04 +00:00
QSignalSpy enterSpy(&win, &HelperWindow::entered);
QSignalSpy leaveSpy(&win, &HelperWindow::left);
QSignalSpy moveSpy(&win, &HelperWindow::mouseMoved);
quint32 timestamp = 1;
Migrate all autotest input simulation functions [5/6] Make autotests create fake input devices Migrate all input simulation functions from kwinApp()->platform()->... to the their counter part in the Test namespace.
2022-03-10 10:27:35 +00:00
Test::pointerMotion(QPoint(50, 50), timestamp++);
Rework InputDeviceHandler focus tracking Summary: This patch aims at improving the Toplevel, internal window and decoration focus tracking. In detail the goals are: * Clean tracking of beneath and focus Toplevel as well as decoration and internal windows. Splitting this up in well defined sub routines. * Minimal find Toplevel operations on window stack. * Reduce code duplication in pointer and touch child classes. * Reuse tracking in drag operations. * Allow direct usage of Wayland input interfaces for decoration and internal windows in the future. * Update touch focus on external events like VD switches correctly. Test Plan: Manually and existing autotests. Reviewers: #kwin Subscribers: kwin, zzag Tags: #kwin Differential Revision: https://phabricator.kde.org/D15595
2018-09-15 00:00:24 +00:00
QTRY_COMPARE(moveSpy.count(), 1);
[autotest] Add a test for a KWin internal QWindow The test creates a QRasterWindow which through KWin's internal QPA is considered an internal window. In the test methods we simulate various pointer events (enter/leave, press/release, wheel).
2016-02-05 14:39:04 +00:00
Migrate all autotest input simulation functions [5/6] Make autotests create fake input devices Migrate all input simulation functions from kwinApp()->platform()->... to the their counter part in the Test namespace.
2022-03-10 10:27:35 +00:00
Test::pointerMotion(QPoint(60, 50), timestamp++);
Rework InputDeviceHandler focus tracking Summary: This patch aims at improving the Toplevel, internal window and decoration focus tracking. In detail the goals are: * Clean tracking of beneath and focus Toplevel as well as decoration and internal windows. Splitting this up in well defined sub routines. * Minimal find Toplevel operations on window stack. * Reduce code duplication in pointer and touch child classes. * Reuse tracking in drag operations. * Allow direct usage of Wayland input interfaces for decoration and internal windows in the future. * Update touch focus on external events like VD switches correctly. Test Plan: Manually and existing autotests. Reviewers: #kwin Subscribers: kwin, zzag Tags: #kwin Differential Revision: https://phabricator.kde.org/D15595
2018-09-15 00:00:24 +00:00
QTRY_COMPARE(moveSpy.count(), 2);
QCOMPARE(moveSpy[1].first().toPoint(), QPoint(60, 50));
[autotest] Add a test for a KWin internal QWindow The test creates a QRasterWindow which through KWin's internal QPA is considered an internal window. In the test methods we simulate various pointer events (enter/leave, press/release, wheel).
2016-02-05 14:39:04 +00:00
Migrate all autotest input simulation functions [5/6] Make autotests create fake input devices Migrate all input simulation functions from kwinApp()->platform()->... to the their counter part in the Test namespace.
2022-03-10 10:27:35 +00:00
Test::pointerMotion(QPoint(101, 50), timestamp++);
[autotest] Add a test for a KWin internal QWindow The test creates a QRasterWindow which through KWin's internal QPA is considered an internal window. In the test methods we simulate various pointer events (enter/leave, press/release, wheel).
2016-02-05 14:39:04 +00:00
QTRY_COMPARE(leaveSpy.count(), 1);
Honor input mask set on internal windows Summary: This ensures that QWindow::setMask works for KWin internal windows. Without KWin sends all pointer events to the QWindow, even if the mask says it shouldn't get events. Reviewers: #plasma Subscribers: plasma-devel Projects: #plasma Differential Revision: https://phabricator.kde.org/D1509
2016-04-29 13:08:22 +00:00
// set a mask on the window
win.setMask(QRegion(10, 20, 30, 40));
// outside the mask we should not get an enter
Migrate all autotest input simulation functions [5/6] Make autotests create fake input devices Migrate all input simulation functions from kwinApp()->platform()->... to the their counter part in the Test namespace.
2022-03-10 10:27:35 +00:00
Test::pointerMotion(QPoint(5, 5), timestamp++);
Honor input mask set on internal windows Summary: This ensures that QWindow::setMask works for KWin internal windows. Without KWin sends all pointer events to the QWindow, even if the mask says it shouldn't get events. Reviewers: #plasma Subscribers: plasma-devel Projects: #plasma Differential Revision: https://phabricator.kde.org/D1509
2016-04-29 13:08:22 +00:00
QVERIFY(!enterSpy.wait(100));
QCOMPARE(enterSpy.count(), 1);
// inside the mask we should still get an enter
Migrate all autotest input simulation functions [5/6] Make autotests create fake input devices Migrate all input simulation functions from kwinApp()->platform()->... to the their counter part in the Test namespace.
2022-03-10 10:27:35 +00:00
Test::pointerMotion(QPoint(25, 27), timestamp++);
Honor input mask set on internal windows Summary: This ensures that QWindow::setMask works for KWin internal windows. Without KWin sends all pointer events to the QWindow, even if the mask says it shouldn't get events. Reviewers: #plasma Subscribers: plasma-devel Projects: #plasma Differential Revision: https://phabricator.kde.org/D1509
2016-04-29 13:08:22 +00:00
QTRY_COMPARE(enterSpy.count(), 2);
[autotest] Add a test for a KWin internal QWindow The test creates a QRasterWindow which through KWin's internal QPA is considered an internal window. In the test methods we simulate various pointer events (enter/leave, press/release, wheel).
2016-02-05 14:39:04 +00:00
}
void InternalWindowTest::testPointerPressRelease()
{
Make Workspace::allClientList() return all windows Currently windows are scattered in a few separate lists. If you need to go through the windows, you have to do it piece by piece. On the other hand, with the overhaul of window types, we've started converging towards one universal type: Window. Keeping windows in the separate buckets goes against this design. Workspace::stackingOrder() already contains all windows. This change repurposes Workspace::allClientList() from a list of "normal" windows to all windows, i.e. Workspace::windows(), to be consistent. There's one API change though. Scripting API will expose other window types too. This is an intentional change so scripted effects could operate with all windows. It also matches the current behavior observed in libkwineffects, which exposes all windows as well.
2023-03-13 11:54:38 +00:00
QSignalSpy windowAddedSpy(workspace(), &Workspace::windowAdded);
[autotest] Add a test for a KWin internal QWindow The test creates a QRasterWindow which through KWin's internal QPA is considered an internal window. In the test methods we simulate various pointer events (enter/leave, press/release, wheel).
2016-02-05 14:39:04 +00:00
HelperWindow win;
win.setGeometry(0, 0, 100, 100);
win.show();
QSignalSpy pressSpy(&win, &HelperWindow::mousePressed);
QSignalSpy releaseSpy(&win, &HelperWindow::mouseReleased);
Prefer the term "window" over "client" in Workspace
2022-04-23 08:33:23 +00:00
QTRY_COMPARE(windowAddedSpy.count(), 1);
[autotest] Add a test for a KWin internal QWindow The test creates a QRasterWindow which through KWin's internal QPA is considered an internal window. In the test methods we simulate various pointer events (enter/leave, press/release, wheel).
2016-02-05 14:39:04 +00:00
quint32 timestamp = 1;
Migrate all autotest input simulation functions [5/6] Make autotests create fake input devices Migrate all input simulation functions from kwinApp()->platform()->... to the their counter part in the Test namespace.
2022-03-10 10:27:35 +00:00
Test::pointerMotion(QPoint(50, 50), timestamp++);
[autotest] Add a test for a KWin internal QWindow The test creates a QRasterWindow which through KWin's internal QPA is considered an internal window. In the test methods we simulate various pointer events (enter/leave, press/release, wheel).
2016-02-05 14:39:04 +00:00
Migrate all autotest input simulation functions [5/6] Make autotests create fake input devices Migrate all input simulation functions from kwinApp()->platform()->... to the their counter part in the Test namespace.
2022-03-10 10:27:35 +00:00
Test::pointerButtonPressed(BTN_LEFT, timestamp++);
[autotest] Add a test for a KWin internal QWindow The test creates a QRasterWindow which through KWin's internal QPA is considered an internal window. In the test methods we simulate various pointer events (enter/leave, press/release, wheel).
2016-02-05 14:39:04 +00:00
QTRY_COMPARE(pressSpy.count(), 1);
Migrate all autotest input simulation functions [5/6] Make autotests create fake input devices Migrate all input simulation functions from kwinApp()->platform()->... to the their counter part in the Test namespace.
2022-03-10 10:27:35 +00:00
Test::pointerButtonReleased(BTN_LEFT, timestamp++);
[autotest] Add a test for a KWin internal QWindow The test creates a QRasterWindow which through KWin's internal QPA is considered an internal window. In the test methods we simulate various pointer events (enter/leave, press/release, wheel).
2016-02-05 14:39:04 +00:00
QTRY_COMPARE(releaseSpy.count(), 1);
}
void InternalWindowTest::testPointerAxis()
{
Make Workspace::allClientList() return all windows Currently windows are scattered in a few separate lists. If you need to go through the windows, you have to do it piece by piece. On the other hand, with the overhaul of window types, we've started converging towards one universal type: Window. Keeping windows in the separate buckets goes against this design. Workspace::stackingOrder() already contains all windows. This change repurposes Workspace::allClientList() from a list of "normal" windows to all windows, i.e. Workspace::windows(), to be consistent. There's one API change though. Scripting API will expose other window types too. This is an intentional change so scripted effects could operate with all windows. It also matches the current behavior observed in libkwineffects, which exposes all windows as well.
2023-03-13 11:54:38 +00:00
QSignalSpy windowAddedSpy(workspace(), &Workspace::windowAdded);
[autotest] Add a test for a KWin internal QWindow The test creates a QRasterWindow which through KWin's internal QPA is considered an internal window. In the test methods we simulate various pointer events (enter/leave, press/release, wheel).
2016-02-05 14:39:04 +00:00
HelperWindow win;
win.setGeometry(0, 0, 100, 100);
win.show();
QSignalSpy wheelSpy(&win, &HelperWindow::wheel);
Prefer the term "window" over "client" in Workspace
2022-04-23 08:33:23 +00:00
QTRY_COMPARE(windowAddedSpy.count(), 1);
[autotest] Add a test for a KWin internal QWindow The test creates a QRasterWindow which through KWin's internal QPA is considered an internal window. In the test methods we simulate various pointer events (enter/leave, press/release, wheel).
2016-02-05 14:39:04 +00:00
quint32 timestamp = 1;
Migrate all autotest input simulation functions [5/6] Make autotests create fake input devices Migrate all input simulation functions from kwinApp()->platform()->... to the their counter part in the Test namespace.
2022-03-10 10:27:35 +00:00
Test::pointerMotion(QPoint(50, 50), timestamp++);
[autotest] Add a test for a KWin internal QWindow The test creates a QRasterWindow which through KWin's internal QPA is considered an internal window. In the test methods we simulate various pointer events (enter/leave, press/release, wheel).
2016-02-05 14:39:04 +00:00
Migrate all autotest input simulation functions [5/6] Make autotests create fake input devices Migrate all input simulation functions from kwinApp()->platform()->... to the their counter part in the Test namespace.
2022-03-10 10:27:35 +00:00
Test::pointerAxisVertical(5.0, timestamp++);
[autotest] Add a test for a KWin internal QWindow The test creates a QRasterWindow which through KWin's internal QPA is considered an internal window. In the test methods we simulate various pointer events (enter/leave, press/release, wheel).
2016-02-05 14:39:04 +00:00
QTRY_COMPARE(wheelSpy.count(), 1);
Migrate all autotest input simulation functions [5/6] Make autotests create fake input devices Migrate all input simulation functions from kwinApp()->platform()->... to the their counter part in the Test namespace.
2022-03-10 10:27:35 +00:00
Test::pointerAxisHorizontal(5.0, timestamp++);
[autotest] Add a test for a KWin internal QWindow The test creates a QRasterWindow which through KWin's internal QPA is considered an internal window. In the test methods we simulate various pointer events (enter/leave, press/release, wheel).
2016-02-05 14:39:04 +00:00
QTRY_COMPARE(wheelSpy.count(), 2);
}
Improve keyboard handling for internal windows So far the key handler in the InternalWindowEventFilter used the PointerInputRedirection's internal window. This had the result that key events were only delivered to an internal window if the window was under the cursor. This change tries sending the event to the latest created and visible window. Thus e.g. with nested context menus it goes to the current sub menu as expected. The return value of sendEvent is used to filter out the event.
2016-02-17 12:34:24 +00:00
void InternalWindowTest::testKeyboard_data()
{
QTest::addColumn<QPoint>("cursorPos");
QTest::newRow("on Window") << QPoint(50, 50);
QTest::newRow("outside Window") << QPoint(250, 250);
}
[autotests] Test case for key events on internal windows
2016-02-08 14:03:21 +00:00
void InternalWindowTest::testKeyboard()
{
Make Workspace::allClientList() return all windows Currently windows are scattered in a few separate lists. If you need to go through the windows, you have to do it piece by piece. On the other hand, with the overhaul of window types, we've started converging towards one universal type: Window. Keeping windows in the separate buckets goes against this design. Workspace::stackingOrder() already contains all windows. This change repurposes Workspace::allClientList() from a list of "normal" windows to all windows, i.e. Workspace::windows(), to be consistent. There's one API change though. Scripting API will expose other window types too. This is an intentional change so scripted effects could operate with all windows. It also matches the current behavior observed in libkwineffects, which exposes all windows as well.
2023-03-13 11:54:38 +00:00
QSignalSpy windowAddedSpy(workspace(), &Workspace::windowAdded);
[autotests] Test case for key events on internal windows
2016-02-08 14:03:21 +00:00
HelperWindow win;
win.setGeometry(0, 0, 100, 100);
win.show();
QSignalSpy pressSpy(&win, &HelperWindow::keyPressed);
QSignalSpy releaseSpy(&win, &HelperWindow::keyReleased);
Prefer the term "window" over "client" in Workspace
2022-04-23 08:33:23 +00:00
QTRY_COMPARE(windowAddedSpy.count(), 1);
autotests: client -> window
2022-04-23 19:51:16 +00:00
auto internalWindow = windowAddedSpy.first().first().value<InternalWindow *>();
QVERIFY(internalWindow);
QVERIFY(internalWindow->isInternal());
QVERIFY(internalWindow->readyForPainting());
[autotests] Test case for key events on internal windows
2016-02-08 14:03:21 +00:00
quint32 timestamp = 1;
Improve keyboard handling for internal windows So far the key handler in the InternalWindowEventFilter used the PointerInputRedirection's internal window. This had the result that key events were only delivered to an internal window if the window was under the cursor. This change tries sending the event to the latest created and visible window. Thus e.g. with nested context menus it goes to the current sub menu as expected. The return value of sendEvent is used to filter out the event.
2016-02-17 12:34:24 +00:00
QFETCH(QPoint, cursorPos);
Migrate all autotest input simulation functions [5/6] Make autotests create fake input devices Migrate all input simulation functions from kwinApp()->platform()->... to the their counter part in the Test namespace.
2022-03-10 10:27:35 +00:00
Test::pointerMotion(cursorPos, timestamp++);
[autotests] Test case for key events on internal windows
2016-02-08 14:03:21 +00:00
Migrate all autotest input simulation functions [5/6] Make autotests create fake input devices Migrate all input simulation functions from kwinApp()->platform()->... to the their counter part in the Test namespace.
2022-03-10 10:27:35 +00:00
Test::keyboardKeyPressed(KEY_A, timestamp++);
[autotests] Test case for key events on internal windows
2016-02-08 14:03:21 +00:00
QTRY_COMPARE(pressSpy.count(), 1);
QCOMPARE(releaseSpy.count(), 0);
Migrate all autotest input simulation functions [5/6] Make autotests create fake input devices Migrate all input simulation functions from kwinApp()->platform()->... to the their counter part in the Test namespace.
2022-03-10 10:27:35 +00:00
Test::keyboardKeyReleased(KEY_A, timestamp++);
[autotests] Test case for key events on internal windows
2016-02-08 14:03:21 +00:00
QTRY_COMPARE(releaseSpy.count(), 1);
QCOMPARE(pressSpy.count(), 1);
[autotests/integration] Split InternalWindowTest::testKeyboard into two test methods Creating a dedicated method for the leave event on client. This restructuring of the test should hopefully work around the failing test condition on build.kde.org.
2016-08-16 13:39:47 +00:00
}
[wayland] Unset focused keyboard surface when handling key event internally Summary: So far when KWin intercepted a key event a leave was not sent to the Wayland surface currently having keyboard focus. This could result in the Wayland application to start repeating keys. E.g. 1. application gets key press event 2. This triggers an internal window to show 3. key release goes to KWin internal window 4. application starts to repeat key as there is no release With this change whenever KWin intercepts the key event e.g. due to * internal window * Effects grabbing key event * Tabbox the focused keyboard surface is set to null, thus triggering a leave event and the client not starting to repeat the event. Reviewers: #kwin, #plasma_on_wayland Subscribers: plasma-devel, kwin Tags: #plasma_on_wayland, #kwin Differential Revision: https://phabricator.kde.org/D2402
2016-08-11 09:17:09 +00:00
DebugConsole window does not take keyboard input Summary: In order to add more tabs which can further help monitoring how KWin handles some aspects the DebugConsole is changed to not take keyboard input. This means it can only be navigated using pointer device or touch screen. This is needed for adding a new tab to monitor clipboard changes. On Wayland sometimes windows don't get the clipboard, so it would be helpful to have a debug monitor to see when the clipboard changes. But for that debug console window may not take keyboard events. To support this DebugConsole sets the WA_ShowWithoutActivating attribute which gets honored by the InternalWindowEventFilter and does not forward key events to such windows. Reviewers: #kwin, #plasma_on_wayland Subscribers: plasma-devel, kwin Tags: #plasma_on_wayland, #kwin Differential Revision: https://phabricator.kde.org/D2620
2016-08-29 13:34:02 +00:00
void InternalWindowTest::testKeyboardShowWithoutActivating()
{
Make Workspace::allClientList() return all windows Currently windows are scattered in a few separate lists. If you need to go through the windows, you have to do it piece by piece. On the other hand, with the overhaul of window types, we've started converging towards one universal type: Window. Keeping windows in the separate buckets goes against this design. Workspace::stackingOrder() already contains all windows. This change repurposes Workspace::allClientList() from a list of "normal" windows to all windows, i.e. Workspace::windows(), to be consistent. There's one API change though. Scripting API will expose other window types too. This is an intentional change so scripted effects could operate with all windows. It also matches the current behavior observed in libkwineffects, which exposes all windows as well.
2023-03-13 11:54:38 +00:00
QSignalSpy windowAddedSpy(workspace(), &Workspace::windowAdded);
DebugConsole window does not take keyboard input Summary: In order to add more tabs which can further help monitoring how KWin handles some aspects the DebugConsole is changed to not take keyboard input. This means it can only be navigated using pointer device or touch screen. This is needed for adding a new tab to monitor clipboard changes. On Wayland sometimes windows don't get the clipboard, so it would be helpful to have a debug monitor to see when the clipboard changes. But for that debug console window may not take keyboard events. To support this DebugConsole sets the WA_ShowWithoutActivating attribute which gets honored by the InternalWindowEventFilter and does not forward key events to such windows. Reviewers: #kwin, #plasma_on_wayland Subscribers: plasma-devel, kwin Tags: #plasma_on_wayland, #kwin Differential Revision: https://phabricator.kde.org/D2620
2016-08-29 13:34:02 +00:00
HelperWindow win;
win.setProperty("_q_showWithoutActivating", true);
win.setGeometry(0, 0, 100, 100);
win.show();
QSignalSpy pressSpy(&win, &HelperWindow::keyPressed);
QSignalSpy releaseSpy(&win, &HelperWindow::keyReleased);
Prefer the term "window" over "client" in Workspace
2022-04-23 08:33:23 +00:00
QTRY_COMPARE(windowAddedSpy.count(), 1);
autotests: client -> window
2022-04-23 19:51:16 +00:00
auto internalWindow = windowAddedSpy.first().first().value<InternalWindow *>();
QVERIFY(internalWindow);
QVERIFY(internalWindow->isInternal());
QVERIFY(internalWindow->readyForPainting());
DebugConsole window does not take keyboard input Summary: In order to add more tabs which can further help monitoring how KWin handles some aspects the DebugConsole is changed to not take keyboard input. This means it can only be navigated using pointer device or touch screen. This is needed for adding a new tab to monitor clipboard changes. On Wayland sometimes windows don't get the clipboard, so it would be helpful to have a debug monitor to see when the clipboard changes. But for that debug console window may not take keyboard events. To support this DebugConsole sets the WA_ShowWithoutActivating attribute which gets honored by the InternalWindowEventFilter and does not forward key events to such windows. Reviewers: #kwin, #plasma_on_wayland Subscribers: plasma-devel, kwin Tags: #plasma_on_wayland, #kwin Differential Revision: https://phabricator.kde.org/D2620
2016-08-29 13:34:02 +00:00
quint32 timestamp = 1;
const QPoint cursorPos = QPoint(50, 50);
Migrate all autotest input simulation functions [5/6] Make autotests create fake input devices Migrate all input simulation functions from kwinApp()->platform()->... to the their counter part in the Test namespace.
2022-03-10 10:27:35 +00:00
Test::pointerMotion(cursorPos, timestamp++);
DebugConsole window does not take keyboard input Summary: In order to add more tabs which can further help monitoring how KWin handles some aspects the DebugConsole is changed to not take keyboard input. This means it can only be navigated using pointer device or touch screen. This is needed for adding a new tab to monitor clipboard changes. On Wayland sometimes windows don't get the clipboard, so it would be helpful to have a debug monitor to see when the clipboard changes. But for that debug console window may not take keyboard events. To support this DebugConsole sets the WA_ShowWithoutActivating attribute which gets honored by the InternalWindowEventFilter and does not forward key events to such windows. Reviewers: #kwin, #plasma_on_wayland Subscribers: plasma-devel, kwin Tags: #plasma_on_wayland, #kwin Differential Revision: https://phabricator.kde.org/D2620
2016-08-29 13:34:02 +00:00
Migrate all autotest input simulation functions [5/6] Make autotests create fake input devices Migrate all input simulation functions from kwinApp()->platform()->... to the their counter part in the Test namespace.
2022-03-10 10:27:35 +00:00
Test::keyboardKeyPressed(KEY_A, timestamp++);
DebugConsole window does not take keyboard input Summary: In order to add more tabs which can further help monitoring how KWin handles some aspects the DebugConsole is changed to not take keyboard input. This means it can only be navigated using pointer device or touch screen. This is needed for adding a new tab to monitor clipboard changes. On Wayland sometimes windows don't get the clipboard, so it would be helpful to have a debug monitor to see when the clipboard changes. But for that debug console window may not take keyboard events. To support this DebugConsole sets the WA_ShowWithoutActivating attribute which gets honored by the InternalWindowEventFilter and does not forward key events to such windows. Reviewers: #kwin, #plasma_on_wayland Subscribers: plasma-devel, kwin Tags: #plasma_on_wayland, #kwin Differential Revision: https://phabricator.kde.org/D2620
2016-08-29 13:34:02 +00:00
QCOMPARE(pressSpy.count(), 0);
QVERIFY(!pressSpy.wait(100));
QCOMPARE(releaseSpy.count(), 0);
Migrate all autotest input simulation functions [5/6] Make autotests create fake input devices Migrate all input simulation functions from kwinApp()->platform()->... to the their counter part in the Test namespace.
2022-03-10 10:27:35 +00:00
Test::keyboardKeyReleased(KEY_A, timestamp++);
DebugConsole window does not take keyboard input Summary: In order to add more tabs which can further help monitoring how KWin handles some aspects the DebugConsole is changed to not take keyboard input. This means it can only be navigated using pointer device or touch screen. This is needed for adding a new tab to monitor clipboard changes. On Wayland sometimes windows don't get the clipboard, so it would be helpful to have a debug monitor to see when the clipboard changes. But for that debug console window may not take keyboard events. To support this DebugConsole sets the WA_ShowWithoutActivating attribute which gets honored by the InternalWindowEventFilter and does not forward key events to such windows. Reviewers: #kwin, #plasma_on_wayland Subscribers: plasma-devel, kwin Tags: #plasma_on_wayland, #kwin Differential Revision: https://phabricator.kde.org/D2620
2016-08-29 13:34:02 +00:00
QCOMPARE(releaseSpy.count(), 0);
QVERIFY(!releaseSpy.wait(100));
QCOMPARE(pressSpy.count(), 0);
}
[autotests/integration] Split InternalWindowTest::testKeyboard into two test methods Creating a dedicated method for the leave event on client. This restructuring of the test should hopefully work around the failing test condition on build.kde.org.
2016-08-16 13:39:47 +00:00
void InternalWindowTest::testKeyboardTriggersLeave()
{
autotests: client -> window
2022-04-23 19:51:16 +00:00
// this test verifies that a leave event is sent to a window when an internal window
[autotests/integration] Split InternalWindowTest::testKeyboard into two test methods Creating a dedicated method for the leave event on client. This restructuring of the test should hopefully work around the failing test condition on build.kde.org.
2016-08-16 13:39:47 +00:00
// gets a key event
autotests: Reduce the number of "using namespace KWayland::Client" KWayland::Client has ambiguous type names such as "Compositor" or "Output". Use full types to improve code readability.
2022-11-07 21:33:00 +00:00
std::unique_ptr<KWayland::Client::Keyboard> keyboard(Test::waylandSeat()->createKeyboard());
replace all uses of QScopedPointer with std::unique_ptr
2022-08-01 21:29:02 +00:00
QVERIFY(keyboard != nullptr);
[wayland] Unset focused keyboard surface when handling key event internally Summary: So far when KWin intercepted a key event a leave was not sent to the Wayland surface currently having keyboard focus. This could result in the Wayland application to start repeating keys. E.g. 1. application gets key press event 2. This triggers an internal window to show 3. key release goes to KWin internal window 4. application starts to repeat key as there is no release With this change whenever KWin intercepts the key event e.g. due to * internal window * Effects grabbing key event * Tabbox the focused keyboard surface is set to null, thus triggering a leave event and the client not starting to repeat the event. Reviewers: #kwin, #plasma_on_wayland Subscribers: plasma-devel, kwin Tags: #plasma_on_wayland, #kwin Differential Revision: https://phabricator.kde.org/D2402
2016-08-11 09:17:09 +00:00
QVERIFY(keyboard->isValid());
autotests: Reduce the number of "using namespace KWayland::Client" KWayland::Client has ambiguous type names such as "Compositor" or "Output". Use full types to improve code readability.
2022-11-07 21:33:00 +00:00
QSignalSpy enteredSpy(keyboard.get(), &KWayland::Client::Keyboard::entered);
QSignalSpy leftSpy(keyboard.get(), &KWayland::Client::Keyboard::left);
replace all uses of QScopedPointer with std::unique_ptr
2022-08-01 21:29:02 +00:00
std::unique_ptr<KWayland::Client::Surface> surface(Test::createSurface());
std::unique_ptr<Test::XdgToplevel> shellSurface(Test::createXdgToplevelSurface(surface.get()));
[wayland] Unset focused keyboard surface when handling key event internally Summary: So far when KWin intercepted a key event a leave was not sent to the Wayland surface currently having keyboard focus. This could result in the Wayland application to start repeating keys. E.g. 1. application gets key press event 2. This triggers an internal window to show 3. key release goes to KWin internal window 4. application starts to repeat key as there is no release With this change whenever KWin intercepts the key event e.g. due to * internal window * Effects grabbing key event * Tabbox the focused keyboard surface is set to null, thus triggering a leave event and the client not starting to repeat the event. Reviewers: #kwin, #plasma_on_wayland Subscribers: plasma-devel, kwin Tags: #plasma_on_wayland, #kwin Differential Revision: https://phabricator.kde.org/D2402
2016-08-11 09:17:09 +00:00
// now let's render
replace all uses of QScopedPointer with std::unique_ptr
2022-08-01 21:29:02 +00:00
auto window = Test::renderAndWaitForShown(surface.get(), QSize(100, 50), Qt::blue);
autotests: client -> window
2022-04-23 19:51:16 +00:00
QVERIFY(window);
QVERIFY(window->isActive());
QVERIFY(!window->isInternal());
[wayland] Unset focused keyboard surface when handling key event internally Summary: So far when KWin intercepted a key event a leave was not sent to the Wayland surface currently having keyboard focus. This could result in the Wayland application to start repeating keys. E.g. 1. application gets key press event 2. This triggers an internal window to show 3. key release goes to KWin internal window 4. application starts to repeat key as there is no release With this change whenever KWin intercepts the key event e.g. due to * internal window * Effects grabbing key event * Tabbox the focused keyboard surface is set to null, thus triggering a leave event and the client not starting to repeat the event. Reviewers: #kwin, #plasma_on_wayland Subscribers: plasma-devel, kwin Tags: #plasma_on_wayland, #kwin Differential Revision: https://phabricator.kde.org/D2402
2016-08-11 09:17:09 +00:00
if (enteredSpy.isEmpty()) {
QVERIFY(enteredSpy.wait());
}
QCOMPARE(enteredSpy.count(), 1);
[autotests/integration] Split InternalWindowTest::testKeyboard into two test methods Creating a dedicated method for the leave event on client. This restructuring of the test should hopefully work around the failing test condition on build.kde.org.
2016-08-16 13:39:47 +00:00
// create internal window
Make Workspace::allClientList() return all windows Currently windows are scattered in a few separate lists. If you need to go through the windows, you have to do it piece by piece. On the other hand, with the overhaul of window types, we've started converging towards one universal type: Window. Keeping windows in the separate buckets goes against this design. Workspace::stackingOrder() already contains all windows. This change repurposes Workspace::allClientList() from a list of "normal" windows to all windows, i.e. Workspace::windows(), to be consistent. There's one API change though. Scripting API will expose other window types too. This is an intentional change so scripted effects could operate with all windows. It also matches the current behavior observed in libkwineffects, which exposes all windows as well.
2023-03-13 11:54:38 +00:00
QSignalSpy windowAddedSpy(workspace(), &Workspace::windowAdded);
[autotests/integration] Split InternalWindowTest::testKeyboard into two test methods Creating a dedicated method for the leave event on client. This restructuring of the test should hopefully work around the failing test condition on build.kde.org.
2016-08-16 13:39:47 +00:00
HelperWindow win;
win.setGeometry(0, 0, 100, 100);
[wayland] Unset focused keyboard surface when handling key event internally Summary: So far when KWin intercepted a key event a leave was not sent to the Wayland surface currently having keyboard focus. This could result in the Wayland application to start repeating keys. E.g. 1. application gets key press event 2. This triggers an internal window to show 3. key release goes to KWin internal window 4. application starts to repeat key as there is no release With this change whenever KWin intercepts the key event e.g. due to * internal window * Effects grabbing key event * Tabbox the focused keyboard surface is set to null, thus triggering a leave event and the client not starting to repeat the event. Reviewers: #kwin, #plasma_on_wayland Subscribers: plasma-devel, kwin Tags: #plasma_on_wayland, #kwin Differential Revision: https://phabricator.kde.org/D2402
2016-08-11 09:17:09 +00:00
win.show();
[autotests/integration] Split InternalWindowTest::testKeyboard into two test methods Creating a dedicated method for the leave event on client. This restructuring of the test should hopefully work around the failing test condition on build.kde.org.
2016-08-16 13:39:47 +00:00
QSignalSpy pressSpy(&win, &HelperWindow::keyPressed);
QSignalSpy releaseSpy(&win, &HelperWindow::keyReleased);
Prefer the term "window" over "client" in Workspace
2022-04-23 08:33:23 +00:00
QTRY_COMPARE(windowAddedSpy.count(), 1);
autotests: client -> window
2022-04-23 19:51:16 +00:00
auto internalWindow = windowAddedSpy.first().first().value<InternalWindow *>();
QVERIFY(internalWindow);
QVERIFY(internalWindow->isInternal());
QVERIFY(internalWindow->readyForPainting());
[autotests/integration] Split InternalWindowTest::testKeyboard into two test methods Creating a dedicated method for the leave event on client. This restructuring of the test should hopefully work around the failing test condition on build.kde.org.
2016-08-16 13:39:47 +00:00
[wayland] Unset focused keyboard surface when handling key event internally Summary: So far when KWin intercepted a key event a leave was not sent to the Wayland surface currently having keyboard focus. This could result in the Wayland application to start repeating keys. E.g. 1. application gets key press event 2. This triggers an internal window to show 3. key release goes to KWin internal window 4. application starts to repeat key as there is no release With this change whenever KWin intercepts the key event e.g. due to * internal window * Effects grabbing key event * Tabbox the focused keyboard surface is set to null, thus triggering a leave event and the client not starting to repeat the event. Reviewers: #kwin, #plasma_on_wayland Subscribers: plasma-devel, kwin Tags: #plasma_on_wayland, #kwin Differential Revision: https://phabricator.kde.org/D2402
2016-08-11 09:17:09 +00:00
QVERIFY(leftSpy.isEmpty());
QVERIFY(!leftSpy.wait(100));
// now let's trigger a key, which should result in a leave
[autotests/integration] Split InternalWindowTest::testKeyboard into two test methods Creating a dedicated method for the leave event on client. This restructuring of the test should hopefully work around the failing test condition on build.kde.org.
2016-08-16 13:39:47 +00:00
quint32 timestamp = 1;
Migrate all autotest input simulation functions [5/6] Make autotests create fake input devices Migrate all input simulation functions from kwinApp()->platform()->... to the their counter part in the Test namespace.
2022-03-10 10:27:35 +00:00
Test::keyboardKeyPressed(KEY_A, timestamp++);
[wayland] Unset focused keyboard surface when handling key event internally Summary: So far when KWin intercepted a key event a leave was not sent to the Wayland surface currently having keyboard focus. This could result in the Wayland application to start repeating keys. E.g. 1. application gets key press event 2. This triggers an internal window to show 3. key release goes to KWin internal window 4. application starts to repeat key as there is no release With this change whenever KWin intercepts the key event e.g. due to * internal window * Effects grabbing key event * Tabbox the focused keyboard surface is set to null, thus triggering a leave event and the client not starting to repeat the event. Reviewers: #kwin, #plasma_on_wayland Subscribers: plasma-devel, kwin Tags: #plasma_on_wayland, #kwin Differential Revision: https://phabricator.kde.org/D2402
2016-08-11 09:17:09 +00:00
QVERIFY(leftSpy.wait());
[autotests/integration] Split InternalWindowTest::testKeyboard into two test methods Creating a dedicated method for the leave event on client. This restructuring of the test should hopefully work around the failing test condition on build.kde.org.
2016-08-16 13:39:47 +00:00
QCOMPARE(pressSpy.count(), 1);
[wayland] Unset focused keyboard surface when handling key event internally Summary: So far when KWin intercepted a key event a leave was not sent to the Wayland surface currently having keyboard focus. This could result in the Wayland application to start repeating keys. E.g. 1. application gets key press event 2. This triggers an internal window to show 3. key release goes to KWin internal window 4. application starts to repeat key as there is no release With this change whenever KWin intercepts the key event e.g. due to * internal window * Effects grabbing key event * Tabbox the focused keyboard surface is set to null, thus triggering a leave event and the client not starting to repeat the event. Reviewers: #kwin, #plasma_on_wayland Subscribers: plasma-devel, kwin Tags: #plasma_on_wayland, #kwin Differential Revision: https://phabricator.kde.org/D2402
2016-08-11 09:17:09 +00:00
Migrate all autotest input simulation functions [5/6] Make autotests create fake input devices Migrate all input simulation functions from kwinApp()->platform()->... to the their counter part in the Test namespace.
2022-03-10 10:27:35 +00:00
Test::keyboardKeyReleased(KEY_A, timestamp++);
[autotests/integration] Split InternalWindowTest::testKeyboard into two test methods Creating a dedicated method for the leave event on client. This restructuring of the test should hopefully work around the failing test condition on build.kde.org.
2016-08-16 13:39:47 +00:00
QTRY_COMPARE(releaseSpy.count(), 1);
[wayland] Unset focused keyboard surface when handling key event internally Summary: So far when KWin intercepted a key event a leave was not sent to the Wayland surface currently having keyboard focus. This could result in the Wayland application to start repeating keys. E.g. 1. application gets key press event 2. This triggers an internal window to show 3. key release goes to KWin internal window 4. application starts to repeat key as there is no release With this change whenever KWin intercepts the key event e.g. due to * internal window * Effects grabbing key event * Tabbox the focused keyboard surface is set to null, thus triggering a leave event and the client not starting to repeat the event. Reviewers: #kwin, #plasma_on_wayland Subscribers: plasma-devel, kwin Tags: #plasma_on_wayland, #kwin Differential Revision: https://phabricator.kde.org/D2402
2016-08-11 09:17:09 +00:00
// after hiding the internal window, next key press should trigger an enter
win.hide();
Migrate all autotest input simulation functions [5/6] Make autotests create fake input devices Migrate all input simulation functions from kwinApp()->platform()->... to the their counter part in the Test namespace.
2022-03-10 10:27:35 +00:00
Test::keyboardKeyPressed(KEY_A, timestamp++);
[wayland] Unset focused keyboard surface when handling key event internally Summary: So far when KWin intercepted a key event a leave was not sent to the Wayland surface currently having keyboard focus. This could result in the Wayland application to start repeating keys. E.g. 1. application gets key press event 2. This triggers an internal window to show 3. key release goes to KWin internal window 4. application starts to repeat key as there is no release With this change whenever KWin intercepts the key event e.g. due to * internal window * Effects grabbing key event * Tabbox the focused keyboard surface is set to null, thus triggering a leave event and the client not starting to repeat the event. Reviewers: #kwin, #plasma_on_wayland Subscribers: plasma-devel, kwin Tags: #plasma_on_wayland, #kwin Differential Revision: https://phabricator.kde.org/D2402
2016-08-11 09:17:09 +00:00
QVERIFY(enteredSpy.wait());
Migrate all autotest input simulation functions [5/6] Make autotests create fake input devices Migrate all input simulation functions from kwinApp()->platform()->... to the their counter part in the Test namespace.
2022-03-10 10:27:35 +00:00
Test::keyboardKeyReleased(KEY_A, timestamp++);
[autotests] Gracefully destroy xdg client
2019-09-23 19:57:50 +00:00
autotests: client -> window
2022-04-23 19:51:16 +00:00
// Destroy the test window.
[autotests] Gracefully destroy xdg client
2019-09-23 19:57:50 +00:00
shellSurface.reset();
autotests: Fix Test::waitForWindowDestroyed Before Deleted merge, it used to be equivalent to waiting until the window is closed. This fixes tests waiting until the window closing animation completes and the Window object is destroyed.
2023-04-21 20:28:48 +00:00
QVERIFY(Test::waitForWindowClosed(window));
[autotests] Test case for key events on internal windows
2016-02-08 14:03:21 +00:00
}
Support touch events on KWin internal windows Summary: Qt's touch event API is rather difficult and complex to implement. As none of KWin's internal windows supports multi-touch gestures yet, this is going the easy route and just simulates a left mouse button press. If in future need arises for touch gesture support on KWin's internal windows, this can be added. Test Plan: Tested on exopc with DebugConsole and auto test Reviewers: #plasma Subscribers: plasma-devel Tags: #plasma Differential Revision: https://phabricator.kde.org/D1661
2016-05-23 15:07:08 +00:00
void InternalWindowTest::testTouch()
{
// touch events for internal windows are emulated through mouse events
Make Workspace::allClientList() return all windows Currently windows are scattered in a few separate lists. If you need to go through the windows, you have to do it piece by piece. On the other hand, with the overhaul of window types, we've started converging towards one universal type: Window. Keeping windows in the separate buckets goes against this design. Workspace::stackingOrder() already contains all windows. This change repurposes Workspace::allClientList() from a list of "normal" windows to all windows, i.e. Workspace::windows(), to be consistent. There's one API change though. Scripting API will expose other window types too. This is an intentional change so scripted effects could operate with all windows. It also matches the current behavior observed in libkwineffects, which exposes all windows as well.
2023-03-13 11:54:38 +00:00
QSignalSpy windowAddedSpy(workspace(), &Workspace::windowAdded);
Support touch events on KWin internal windows Summary: Qt's touch event API is rather difficult and complex to implement. As none of KWin's internal windows supports multi-touch gestures yet, this is going the easy route and just simulates a left mouse button press. If in future need arises for touch gesture support on KWin's internal windows, this can be added. Test Plan: Tested on exopc with DebugConsole and auto test Reviewers: #plasma Subscribers: plasma-devel Tags: #plasma Differential Revision: https://phabricator.kde.org/D1661
2016-05-23 15:07:08 +00:00
HelperWindow win;
win.setGeometry(0, 0, 100, 100);
win.show();
Prefer the term "window" over "client" in Workspace
2022-04-23 08:33:23 +00:00
QTRY_COMPARE(windowAddedSpy.count(), 1);
Support touch events on KWin internal windows Summary: Qt's touch event API is rather difficult and complex to implement. As none of KWin's internal windows supports multi-touch gestures yet, this is going the easy route and just simulates a left mouse button press. If in future need arises for touch gesture support on KWin's internal windows, this can be added. Test Plan: Tested on exopc with DebugConsole and auto test Reviewers: #plasma Subscribers: plasma-devel Tags: #plasma Differential Revision: https://phabricator.kde.org/D1661
2016-05-23 15:07:08 +00:00
QSignalSpy pressSpy(&win, &HelperWindow::mousePressed);
QSignalSpy releaseSpy(&win, &HelperWindow::mouseReleased);
QSignalSpy moveSpy(&win, &HelperWindow::mouseMoved);
quint32 timestamp = 1;
QCOMPARE(win.pressedButtons(), Qt::MouseButtons());
Migrate all autotest input simulation functions [5/6] Make autotests create fake input devices Migrate all input simulation functions from kwinApp()->platform()->... to the their counter part in the Test namespace.
2022-03-10 10:27:35 +00:00
Test::touchDown(0, QPointF(50, 50), timestamp++);
Support touch events on KWin internal windows Summary: Qt's touch event API is rather difficult and complex to implement. As none of KWin's internal windows supports multi-touch gestures yet, this is going the easy route and just simulates a left mouse button press. If in future need arises for touch gesture support on KWin's internal windows, this can be added. Test Plan: Tested on exopc with DebugConsole and auto test Reviewers: #plasma Subscribers: plasma-devel Tags: #plasma Differential Revision: https://phabricator.kde.org/D1661
2016-05-23 15:07:08 +00:00
QCOMPARE(pressSpy.count(), 1);
QCOMPARE(win.latestGlobalMousePos(), QPoint(50, 50));
QCOMPARE(win.pressedButtons(), Qt::MouseButtons(Qt::LeftButton));
// further touch down should not trigger
Migrate all autotest input simulation functions [5/6] Make autotests create fake input devices Migrate all input simulation functions from kwinApp()->platform()->... to the their counter part in the Test namespace.
2022-03-10 10:27:35 +00:00
Test::touchDown(1, QPointF(75, 75), timestamp++);
Support touch events on KWin internal windows Summary: Qt's touch event API is rather difficult and complex to implement. As none of KWin's internal windows supports multi-touch gestures yet, this is going the easy route and just simulates a left mouse button press. If in future need arises for touch gesture support on KWin's internal windows, this can be added. Test Plan: Tested on exopc with DebugConsole and auto test Reviewers: #plasma Subscribers: plasma-devel Tags: #plasma Differential Revision: https://phabricator.kde.org/D1661
2016-05-23 15:07:08 +00:00
QCOMPARE(pressSpy.count(), 1);
Migrate all autotest input simulation functions [5/6] Make autotests create fake input devices Migrate all input simulation functions from kwinApp()->platform()->... to the their counter part in the Test namespace.
2022-03-10 10:27:35 +00:00
Test::touchUp(1, timestamp++);
Support touch events on KWin internal windows Summary: Qt's touch event API is rather difficult and complex to implement. As none of KWin's internal windows supports multi-touch gestures yet, this is going the easy route and just simulates a left mouse button press. If in future need arises for touch gesture support on KWin's internal windows, this can be added. Test Plan: Tested on exopc with DebugConsole and auto test Reviewers: #plasma Subscribers: plasma-devel Tags: #plasma Differential Revision: https://phabricator.kde.org/D1661
2016-05-23 15:07:08 +00:00
QCOMPARE(releaseSpy.count(), 0);
QCOMPARE(win.latestGlobalMousePos(), QPoint(50, 50));
QCOMPARE(win.pressedButtons(), Qt::MouseButtons(Qt::LeftButton));
// another press
Migrate all autotest input simulation functions [5/6] Make autotests create fake input devices Migrate all input simulation functions from kwinApp()->platform()->... to the their counter part in the Test namespace.
2022-03-10 10:27:35 +00:00
Test::touchDown(1, QPointF(10, 10), timestamp++);
Support touch events on KWin internal windows Summary: Qt's touch event API is rather difficult and complex to implement. As none of KWin's internal windows supports multi-touch gestures yet, this is going the easy route and just simulates a left mouse button press. If in future need arises for touch gesture support on KWin's internal windows, this can be added. Test Plan: Tested on exopc with DebugConsole and auto test Reviewers: #plasma Subscribers: plasma-devel Tags: #plasma Differential Revision: https://phabricator.kde.org/D1661
2016-05-23 15:07:08 +00:00
QCOMPARE(pressSpy.count(), 1);
QCOMPARE(win.latestGlobalMousePos(), QPoint(50, 50));
QCOMPARE(win.pressedButtons(), Qt::MouseButtons(Qt::LeftButton));
// simulate the move
QCOMPARE(moveSpy.count(), 0);
Migrate all autotest input simulation functions [5/6] Make autotests create fake input devices Migrate all input simulation functions from kwinApp()->platform()->... to the their counter part in the Test namespace.
2022-03-10 10:27:35 +00:00
Test::touchMotion(0, QPointF(80, 90), timestamp++);
Support touch events on KWin internal windows Summary: Qt's touch event API is rather difficult and complex to implement. As none of KWin's internal windows supports multi-touch gestures yet, this is going the easy route and just simulates a left mouse button press. If in future need arises for touch gesture support on KWin's internal windows, this can be added. Test Plan: Tested on exopc with DebugConsole and auto test Reviewers: #plasma Subscribers: plasma-devel Tags: #plasma Differential Revision: https://phabricator.kde.org/D1661
2016-05-23 15:07:08 +00:00
QCOMPARE(moveSpy.count(), 1);
QCOMPARE(win.latestGlobalMousePos(), QPoint(80, 90));
QCOMPARE(win.pressedButtons(), Qt::MouseButtons(Qt::LeftButton));
// move on other ID should not do anything
Migrate all autotest input simulation functions [5/6] Make autotests create fake input devices Migrate all input simulation functions from kwinApp()->platform()->... to the their counter part in the Test namespace.
2022-03-10 10:27:35 +00:00
Test::touchMotion(1, QPointF(20, 30), timestamp++);
Support touch events on KWin internal windows Summary: Qt's touch event API is rather difficult and complex to implement. As none of KWin's internal windows supports multi-touch gestures yet, this is going the easy route and just simulates a left mouse button press. If in future need arises for touch gesture support on KWin's internal windows, this can be added. Test Plan: Tested on exopc with DebugConsole and auto test Reviewers: #plasma Subscribers: plasma-devel Tags: #plasma Differential Revision: https://phabricator.kde.org/D1661
2016-05-23 15:07:08 +00:00
QCOMPARE(moveSpy.count(), 1);
QCOMPARE(win.latestGlobalMousePos(), QPoint(80, 90));
QCOMPARE(win.pressedButtons(), Qt::MouseButtons(Qt::LeftButton));
// now up our main point
Migrate all autotest input simulation functions [5/6] Make autotests create fake input devices Migrate all input simulation functions from kwinApp()->platform()->... to the their counter part in the Test namespace.
2022-03-10 10:27:35 +00:00
Test::touchUp(0, timestamp++);
Support touch events on KWin internal windows Summary: Qt's touch event API is rather difficult and complex to implement. As none of KWin's internal windows supports multi-touch gestures yet, this is going the easy route and just simulates a left mouse button press. If in future need arises for touch gesture support on KWin's internal windows, this can be added. Test Plan: Tested on exopc with DebugConsole and auto test Reviewers: #plasma Subscribers: plasma-devel Tags: #plasma Differential Revision: https://phabricator.kde.org/D1661
2016-05-23 15:07:08 +00:00
QCOMPARE(releaseSpy.count(), 1);
QCOMPARE(win.latestGlobalMousePos(), QPoint(80, 90));
QCOMPARE(win.pressedButtons(), Qt::MouseButtons());
// and up the additional point
Migrate all autotest input simulation functions [5/6] Make autotests create fake input devices Migrate all input simulation functions from kwinApp()->platform()->... to the their counter part in the Test namespace.
2022-03-10 10:27:35 +00:00
Test::touchUp(1, timestamp++);
Support touch events on KWin internal windows Summary: Qt's touch event API is rather difficult and complex to implement. As none of KWin's internal windows supports multi-touch gestures yet, this is going the easy route and just simulates a left mouse button press. If in future need arises for touch gesture support on KWin's internal windows, this can be added. Test Plan: Tested on exopc with DebugConsole and auto test Reviewers: #plasma Subscribers: plasma-devel Tags: #plasma Differential Revision: https://phabricator.kde.org/D1661
2016-05-23 15:07:08 +00:00
QCOMPARE(releaseSpy.count(), 1);
QCOMPARE(moveSpy.count(), 1);
QCOMPARE(win.latestGlobalMousePos(), QPoint(80, 90));
QCOMPARE(win.pressedButtons(), Qt::MouseButtons());
}
Sync opacity from an internal QWindow to its ShellClient Summary: This change adds support for opacity on a KWin internal QWindow. Calling QWindow::setOpacity syncs the value to the ShellClient representation of the QWindow. This is needed for fading out the OnScreenNotification on mouse over. Test Plan: Added auto test and manual test Reviewers: #kwin, #plasma_on_wayland Subscribers: plasma-devel, kwin Tags: #plasma_on_wayland, #kwin Differential Revision: https://phabricator.kde.org/D3928
2017-01-03 06:28:29 +00:00
void InternalWindowTest::testOpacity()
{
Port QPA away from Wayland Summary: So far wayland was used by internal clients to submit raster buffers and position themselves on the screen. While we didn't have issues with submitting raster buffers, there were some problems with positioning task switchers. Mostly, because we had effectively two paths that may alter geometry. A better approach to deal with internal clients is to let our QPA use kwin core api directly. This way we can eliminate unnecessary roundtrips as well make geometry handling much easier and comprehensible. The last missing piece is shadows. Both Plasma::Dialog and Breeze widget style use platform-specific APIs to set and unset shadows. We need to add shadows API to KWindowSystem. Even though some internal clients lack drop-shadows at the moment, I don't consider it to be a blocker. We can add shadows back later on. CCBUG: 386304 Reviewers: #kwin, davidedmundson, romangg Reviewed By: #kwin, romangg Subscribers: romangg, kwin Tags: #kwin Maniphest Tasks: T9600 Differential Revision: https://phabricator.kde.org/D22810
2019-08-26 07:44:04 +00:00
// this test verifies that opacity is properly synced from QWindow to InternalClient
Make Workspace::allClientList() return all windows Currently windows are scattered in a few separate lists. If you need to go through the windows, you have to do it piece by piece. On the other hand, with the overhaul of window types, we've started converging towards one universal type: Window. Keeping windows in the separate buckets goes against this design. Workspace::stackingOrder() already contains all windows. This change repurposes Workspace::allClientList() from a list of "normal" windows to all windows, i.e. Workspace::windows(), to be consistent. There's one API change though. Scripting API will expose other window types too. This is an intentional change so scripted effects could operate with all windows. It also matches the current behavior observed in libkwineffects, which exposes all windows as well.
2023-03-13 11:54:38 +00:00
QSignalSpy windowAddedSpy(workspace(), &Workspace::windowAdded);
Sync opacity from an internal QWindow to its ShellClient Summary: This change adds support for opacity on a KWin internal QWindow. Calling QWindow::setOpacity syncs the value to the ShellClient representation of the QWindow. This is needed for fading out the OnScreenNotification on mouse over. Test Plan: Added auto test and manual test Reviewers: #kwin, #plasma_on_wayland Subscribers: plasma-devel, kwin Tags: #plasma_on_wayland, #kwin Differential Revision: https://phabricator.kde.org/D3928
2017-01-03 06:28:29 +00:00
HelperWindow win;
win.setOpacity(0.5);
win.setGeometry(0, 0, 100, 100);
win.show();
Prefer the term "window" over "client" in Workspace
2022-04-23 08:33:23 +00:00
QTRY_COMPARE(windowAddedSpy.count(), 1);
autotests: client -> window
2022-04-23 19:51:16 +00:00
auto internalWindow = windowAddedSpy.first().first().value<InternalWindow *>();
QVERIFY(internalWindow);
QVERIFY(internalWindow->isInternal());
QCOMPARE(internalWindow->opacity(), 0.5);
Sync opacity from an internal QWindow to its ShellClient Summary: This change adds support for opacity on a KWin internal QWindow. Calling QWindow::setOpacity syncs the value to the ShellClient representation of the QWindow. This is needed for fading out the OnScreenNotification on mouse over. Test Plan: Added auto test and manual test Reviewers: #kwin, #plasma_on_wayland Subscribers: plasma-devel, kwin Tags: #plasma_on_wayland, #kwin Differential Revision: https://phabricator.kde.org/D3928
2017-01-03 06:28:29 +00:00
autotests: client -> window
2022-04-23 19:51:16 +00:00
QSignalSpy opacityChangedSpy(internalWindow, &InternalWindow::opacityChanged);
Sync opacity from an internal QWindow to its ShellClient Summary: This change adds support for opacity on a KWin internal QWindow. Calling QWindow::setOpacity syncs the value to the ShellClient representation of the QWindow. This is needed for fading out the OnScreenNotification on mouse over. Test Plan: Added auto test and manual test Reviewers: #kwin, #plasma_on_wayland Subscribers: plasma-devel, kwin Tags: #plasma_on_wayland, #kwin Differential Revision: https://phabricator.kde.org/D3928
2017-01-03 06:28:29 +00:00
win.setOpacity(0.75);
QCOMPARE(opacityChangedSpy.count(), 1);
autotests: client -> window
2022-04-23 19:51:16 +00:00
QCOMPARE(internalWindow->opacity(), 0.75);
Sync opacity from an internal QWindow to its ShellClient Summary: This change adds support for opacity on a KWin internal QWindow. Calling QWindow::setOpacity syncs the value to the ShellClient representation of the QWindow. This is needed for fading out the OnScreenNotification on mouse over. Test Plan: Added auto test and manual test Reviewers: #kwin, #plasma_on_wayland Subscribers: plasma-devel, kwin Tags: #plasma_on_wayland, #kwin Differential Revision: https://phabricator.kde.org/D3928
2017-01-03 06:28:29 +00:00
}
Fix syncing of geometry to internal window when using ::move Summary: The OnScreenNotification gets moved during its placement. This update of the geometry did not get synced to the QWindow's geometry as it should. The reason for this is the rather special implementation of AbstractClient::move. This just modifies the geom variable and does not call into setGeometry at all. Instead a virtual doMove method is invoked to inform the platform specific client implementation about the move of the window. For a "normal" ShellClient that is fine - there is nothing to do. This change adds an implementation of doMove in ShellClient to sync the geometry to the internal window. This is not yet enough to fix the geometry of the OnScreenNotification. It gets placed with a GeometryUpdatesBlocker in place causing the doMove never to be called. Instead setGeometry is invoked again when the geometry updates get unblocked. So far ShellClient did not do anything in this case. This change ensures that at least the doSetGeometry method is performed again. Test Plan: Added test case and manual testing of OnScreenNotification Reviewers: #kwin, #plasma_on_wayland Subscribers: plasma-devel, kwin Tags: #plasma_on_wayland, #kwin Differential Revision: https://phabricator.kde.org/D3963
2017-01-04 16:53:46 +00:00
void InternalWindowTest::testMove()
{
Make Workspace::allClientList() return all windows Currently windows are scattered in a few separate lists. If you need to go through the windows, you have to do it piece by piece. On the other hand, with the overhaul of window types, we've started converging towards one universal type: Window. Keeping windows in the separate buckets goes against this design. Workspace::stackingOrder() already contains all windows. This change repurposes Workspace::allClientList() from a list of "normal" windows to all windows, i.e. Workspace::windows(), to be consistent. There's one API change though. Scripting API will expose other window types too. This is an intentional change so scripted effects could operate with all windows. It also matches the current behavior observed in libkwineffects, which exposes all windows as well.
2023-03-13 11:54:38 +00:00
QSignalSpy windowAddedSpy(workspace(), &Workspace::windowAdded);
Fix syncing of geometry to internal window when using ::move Summary: The OnScreenNotification gets moved during its placement. This update of the geometry did not get synced to the QWindow's geometry as it should. The reason for this is the rather special implementation of AbstractClient::move. This just modifies the geom variable and does not call into setGeometry at all. Instead a virtual doMove method is invoked to inform the platform specific client implementation about the move of the window. For a "normal" ShellClient that is fine - there is nothing to do. This change adds an implementation of doMove in ShellClient to sync the geometry to the internal window. This is not yet enough to fix the geometry of the OnScreenNotification. It gets placed with a GeometryUpdatesBlocker in place causing the doMove never to be called. Instead setGeometry is invoked again when the geometry updates get unblocked. So far ShellClient did not do anything in this case. This change ensures that at least the doSetGeometry method is performed again. Test Plan: Added test case and manual testing of OnScreenNotification Reviewers: #kwin, #plasma_on_wayland Subscribers: plasma-devel, kwin Tags: #plasma_on_wayland, #kwin Differential Revision: https://phabricator.kde.org/D3963
2017-01-04 16:53:46 +00:00
HelperWindow win;
win.setOpacity(0.5);
win.setGeometry(0, 0, 100, 100);
win.show();
Prefer the term "window" over "client" in Workspace
2022-04-23 08:33:23 +00:00
QTRY_COMPARE(windowAddedSpy.count(), 1);
autotests: client -> window
2022-04-23 19:51:16 +00:00
auto internalWindow = windowAddedSpy.first().first().value<InternalWindow *>();
QVERIFY(internalWindow);
QCOMPARE(internalWindow->frameGeometry(), QRect(0, 0, 100, 100));
Fix syncing of geometry to internal window when using ::move Summary: The OnScreenNotification gets moved during its placement. This update of the geometry did not get synced to the QWindow's geometry as it should. The reason for this is the rather special implementation of AbstractClient::move. This just modifies the geom variable and does not call into setGeometry at all. Instead a virtual doMove method is invoked to inform the platform specific client implementation about the move of the window. For a "normal" ShellClient that is fine - there is nothing to do. This change adds an implementation of doMove in ShellClient to sync the geometry to the internal window. This is not yet enough to fix the geometry of the OnScreenNotification. It gets placed with a GeometryUpdatesBlocker in place causing the doMove never to be called. Instead setGeometry is invoked again when the geometry updates get unblocked. So far ShellClient did not do anything in this case. This change ensures that at least the doSetGeometry method is performed again. Test Plan: Added test case and manual testing of OnScreenNotification Reviewers: #kwin, #plasma_on_wayland Subscribers: plasma-devel, kwin Tags: #plasma_on_wayland, #kwin Differential Revision: https://phabricator.kde.org/D3963
2017-01-04 16:53:46 +00:00
// normal move should be synced
autotests: client -> window
2022-04-23 19:51:16 +00:00
internalWindow->move(QPoint(5, 10));
QCOMPARE(internalWindow->frameGeometry(), QRect(5, 10, 100, 100));
Delay syncing internal window geometry to end of cycle Summary: The syncing of the window geometry to the internal geometry can unfortunately cause a freeze in very special conditions: 1. create QML component 2. a Plasma::Dialog gets created 3. It creates the DialogShadows 4. This triggers QGlobalStatic creation which locks a non-recursive mutex 5. The creation of DialogShadows creates a Registry and triggers a roundtrip on the Wayland server 6. KWin processes all Wayland events 7. This triggers the creation of a ShellClient 8. The ShellClient has a PlasmaShellSurface which requested a position 9. The new geometry does not match the geometry of the Plasma::Dialog 10. ShellClient syncs the geometry to the Plasma::Dialog 11. Plasma::Dialog updates the theme because window geometry changed 12. This accesses the DialogShadows... which is still in the non recursive mutex and we have a freeze. By delaying the sync to the end of cycle we jump out of this deadly sequence. BUG: 384441 Test Plan: The freeze doesn't hit any more. It's possible that some test cases need adjustments. Reviewers: #kwin, #plasma Subscribers: plasma-devel, kwin Tags: #kwin Differential Revision: https://phabricator.kde.org/D7712
2017-09-06 18:45:51 +00:00
QTRY_COMPARE(win.geometry(), QRect(5, 10, 100, 100));
Fix syncing of geometry to internal window when using ::move Summary: The OnScreenNotification gets moved during its placement. This update of the geometry did not get synced to the QWindow's geometry as it should. The reason for this is the rather special implementation of AbstractClient::move. This just modifies the geom variable and does not call into setGeometry at all. Instead a virtual doMove method is invoked to inform the platform specific client implementation about the move of the window. For a "normal" ShellClient that is fine - there is nothing to do. This change adds an implementation of doMove in ShellClient to sync the geometry to the internal window. This is not yet enough to fix the geometry of the OnScreenNotification. It gets placed with a GeometryUpdatesBlocker in place causing the doMove never to be called. Instead setGeometry is invoked again when the geometry updates get unblocked. So far ShellClient did not do anything in this case. This change ensures that at least the doSetGeometry method is performed again. Test Plan: Added test case and manual testing of OnScreenNotification Reviewers: #kwin, #plasma_on_wayland Subscribers: plasma-devel, kwin Tags: #plasma_on_wayland, #kwin Differential Revision: https://phabricator.kde.org/D3963
2017-01-04 16:53:46 +00:00
// another move should also be synced
autotests: client -> window
2022-04-23 19:51:16 +00:00
internalWindow->move(QPoint(10, 20));
QCOMPARE(internalWindow->frameGeometry(), QRect(10, 20, 100, 100));
Delay syncing internal window geometry to end of cycle Summary: The syncing of the window geometry to the internal geometry can unfortunately cause a freeze in very special conditions: 1. create QML component 2. a Plasma::Dialog gets created 3. It creates the DialogShadows 4. This triggers QGlobalStatic creation which locks a non-recursive mutex 5. The creation of DialogShadows creates a Registry and triggers a roundtrip on the Wayland server 6. KWin processes all Wayland events 7. This triggers the creation of a ShellClient 8. The ShellClient has a PlasmaShellSurface which requested a position 9. The new geometry does not match the geometry of the Plasma::Dialog 10. ShellClient syncs the geometry to the Plasma::Dialog 11. Plasma::Dialog updates the theme because window geometry changed 12. This accesses the DialogShadows... which is still in the non recursive mutex and we have a freeze. By delaying the sync to the end of cycle we jump out of this deadly sequence. BUG: 384441 Test Plan: The freeze doesn't hit any more. It's possible that some test cases need adjustments. Reviewers: #kwin, #plasma Subscribers: plasma-devel, kwin Tags: #kwin Differential Revision: https://phabricator.kde.org/D7712
2017-09-06 18:45:51 +00:00
QTRY_COMPARE(win.geometry(), QRect(10, 20, 100, 100));
Fix syncing of geometry to internal window when using ::move Summary: The OnScreenNotification gets moved during its placement. This update of the geometry did not get synced to the QWindow's geometry as it should. The reason for this is the rather special implementation of AbstractClient::move. This just modifies the geom variable and does not call into setGeometry at all. Instead a virtual doMove method is invoked to inform the platform specific client implementation about the move of the window. For a "normal" ShellClient that is fine - there is nothing to do. This change adds an implementation of doMove in ShellClient to sync the geometry to the internal window. This is not yet enough to fix the geometry of the OnScreenNotification. It gets placed with a GeometryUpdatesBlocker in place causing the doMove never to be called. Instead setGeometry is invoked again when the geometry updates get unblocked. So far ShellClient did not do anything in this case. This change ensures that at least the doSetGeometry method is performed again. Test Plan: Added test case and manual testing of OnScreenNotification Reviewers: #kwin, #plasma_on_wayland Subscribers: plasma-devel, kwin Tags: #plasma_on_wayland, #kwin Differential Revision: https://phabricator.kde.org/D3963
2017-01-04 16:53:46 +00:00
// now move with a Geometry update blocker
{
autotests: client -> window
2022-04-23 19:51:16 +00:00
GeometryUpdatesBlocker blocker(internalWindow);
internalWindow->move(QPoint(5, 10));
Fix syncing of geometry to internal window when using ::move Summary: The OnScreenNotification gets moved during its placement. This update of the geometry did not get synced to the QWindow's geometry as it should. The reason for this is the rather special implementation of AbstractClient::move. This just modifies the geom variable and does not call into setGeometry at all. Instead a virtual doMove method is invoked to inform the platform specific client implementation about the move of the window. For a "normal" ShellClient that is fine - there is nothing to do. This change adds an implementation of doMove in ShellClient to sync the geometry to the internal window. This is not yet enough to fix the geometry of the OnScreenNotification. It gets placed with a GeometryUpdatesBlocker in place causing the doMove never to be called. Instead setGeometry is invoked again when the geometry updates get unblocked. So far ShellClient did not do anything in this case. This change ensures that at least the doSetGeometry method is performed again. Test Plan: Added test case and manual testing of OnScreenNotification Reviewers: #kwin, #plasma_on_wayland Subscribers: plasma-devel, kwin Tags: #plasma_on_wayland, #kwin Differential Revision: https://phabricator.kde.org/D3963
2017-01-04 16:53:46 +00:00
// not synced!
QCOMPARE(win.geometry(), QRect(10, 20, 100, 100));
}
// after destroying the blocker it should be synced
Delay syncing internal window geometry to end of cycle Summary: The syncing of the window geometry to the internal geometry can unfortunately cause a freeze in very special conditions: 1. create QML component 2. a Plasma::Dialog gets created 3. It creates the DialogShadows 4. This triggers QGlobalStatic creation which locks a non-recursive mutex 5. The creation of DialogShadows creates a Registry and triggers a roundtrip on the Wayland server 6. KWin processes all Wayland events 7. This triggers the creation of a ShellClient 8. The ShellClient has a PlasmaShellSurface which requested a position 9. The new geometry does not match the geometry of the Plasma::Dialog 10. ShellClient syncs the geometry to the Plasma::Dialog 11. Plasma::Dialog updates the theme because window geometry changed 12. This accesses the DialogShadows... which is still in the non recursive mutex and we have a freeze. By delaying the sync to the end of cycle we jump out of this deadly sequence. BUG: 384441 Test Plan: The freeze doesn't hit any more. It's possible that some test cases need adjustments. Reviewers: #kwin, #plasma Subscribers: plasma-devel, kwin Tags: #kwin Differential Revision: https://phabricator.kde.org/D7712
2017-09-06 18:45:51 +00:00
QTRY_COMPARE(win.geometry(), QRect(5, 10, 100, 100));
Fix syncing of geometry to internal window when using ::move Summary: The OnScreenNotification gets moved during its placement. This update of the geometry did not get synced to the QWindow's geometry as it should. The reason for this is the rather special implementation of AbstractClient::move. This just modifies the geom variable and does not call into setGeometry at all. Instead a virtual doMove method is invoked to inform the platform specific client implementation about the move of the window. For a "normal" ShellClient that is fine - there is nothing to do. This change adds an implementation of doMove in ShellClient to sync the geometry to the internal window. This is not yet enough to fix the geometry of the OnScreenNotification. It gets placed with a GeometryUpdatesBlocker in place causing the doMove never to be called. Instead setGeometry is invoked again when the geometry updates get unblocked. So far ShellClient did not do anything in this case. This change ensures that at least the doSetGeometry method is performed again. Test Plan: Added test case and manual testing of OnScreenNotification Reviewers: #kwin, #plasma_on_wayland Subscribers: plasma-devel, kwin Tags: #plasma_on_wayland, #kwin Differential Revision: https://phabricator.kde.org/D3963
2017-01-04 16:53:46 +00:00
}
Add support for skipCloseAnimation for internal windows Summary: We need this to use the new OnScreenNotification in the screenshot effect. Reviewers: #kwin, #plasma_on_wayland Subscribers: plasma-devel, kwin Tags: #plasma_on_wayland, #kwin Differential Revision: https://phabricator.kde.org/D4089
2017-01-11 19:00:40 +00:00
void InternalWindowTest::testSkipCloseAnimation_data()
{
QTest::addColumn<bool>("initial");
QTest::newRow("set") << true;
QTest::newRow("not set") << false;
}
void InternalWindowTest::testSkipCloseAnimation()
{
Make Workspace::allClientList() return all windows Currently windows are scattered in a few separate lists. If you need to go through the windows, you have to do it piece by piece. On the other hand, with the overhaul of window types, we've started converging towards one universal type: Window. Keeping windows in the separate buckets goes against this design. Workspace::stackingOrder() already contains all windows. This change repurposes Workspace::allClientList() from a list of "normal" windows to all windows, i.e. Workspace::windows(), to be consistent. There's one API change though. Scripting API will expose other window types too. This is an intentional change so scripted effects could operate with all windows. It also matches the current behavior observed in libkwineffects, which exposes all windows as well.
2023-03-13 11:54:38 +00:00
QSignalSpy windowAddedSpy(workspace(), &Workspace::windowAdded);
Add support for skipCloseAnimation for internal windows Summary: We need this to use the new OnScreenNotification in the screenshot effect. Reviewers: #kwin, #plasma_on_wayland Subscribers: plasma-devel, kwin Tags: #plasma_on_wayland, #kwin Differential Revision: https://phabricator.kde.org/D4089
2017-01-11 19:00:40 +00:00
HelperWindow win;
win.setOpacity(0.5);
win.setGeometry(0, 0, 100, 100);
QFETCH(bool, initial);
win.setProperty("KWIN_SKIP_CLOSE_ANIMATION", initial);
win.show();
Prefer the term "window" over "client" in Workspace
2022-04-23 08:33:23 +00:00
QTRY_COMPARE(windowAddedSpy.count(), 1);
autotests: client -> window
2022-04-23 19:51:16 +00:00
auto internalWindow = windowAddedSpy.first().first().value<InternalWindow *>();
QVERIFY(internalWindow);
QCOMPARE(internalWindow->skipsCloseAnimation(), initial);
QSignalSpy skipCloseChangedSpy(internalWindow, &Window::skipCloseAnimationChanged);
Add support for skipCloseAnimation for internal windows Summary: We need this to use the new OnScreenNotification in the screenshot effect. Reviewers: #kwin, #plasma_on_wayland Subscribers: plasma-devel, kwin Tags: #plasma_on_wayland, #kwin Differential Revision: https://phabricator.kde.org/D4089
2017-01-11 19:00:40 +00:00
win.setProperty("KWIN_SKIP_CLOSE_ANIMATION", !initial);
QCOMPARE(skipCloseChangedSpy.count(), 1);
autotests: client -> window
2022-04-23 19:51:16 +00:00
QCOMPARE(internalWindow->skipsCloseAnimation(), !initial);
Add support for skipCloseAnimation for internal windows Summary: We need this to use the new OnScreenNotification in the screenshot effect. Reviewers: #kwin, #plasma_on_wayland Subscribers: plasma-devel, kwin Tags: #plasma_on_wayland, #kwin Differential Revision: https://phabricator.kde.org/D4089
2017-01-11 19:00:40 +00:00
win.setProperty("KWIN_SKIP_CLOSE_ANIMATION", initial);
QCOMPARE(skipCloseChangedSpy.count(), 2);
autotests: client -> window
2022-04-23 19:51:16 +00:00
QCOMPARE(internalWindow->skipsCloseAnimation(), initial);
Add support for skipCloseAnimation for internal windows Summary: We need this to use the new OnScreenNotification in the screenshot effect. Reviewers: #kwin, #plasma_on_wayland Subscribers: plasma-devel, kwin Tags: #plasma_on_wayland, #kwin Differential Revision: https://phabricator.kde.org/D4089
2017-01-11 19:00:40 +00:00
}
Support modifier mouse/scroll action on internal decorated windows Summary: This fixes the problem that alt+lmb did not start unrestricted move resize for the Debug Console. BUG: 374880 FIXED-IN: 5.12.3 Test Plan: New test case and manual testing whether alt+lmb/rmb works Reviewers: #kwin, #plasma Subscribers: plasma-devel, kwin Tags: #plasma Differential Revision: https://phabricator.kde.org/D10440
2018-02-11 09:49:31 +00:00
void InternalWindowTest::testModifierClickUnrestrictedMove()
{
Make Workspace::allClientList() return all windows Currently windows are scattered in a few separate lists. If you need to go through the windows, you have to do it piece by piece. On the other hand, with the overhaul of window types, we've started converging towards one universal type: Window. Keeping windows in the separate buckets goes against this design. Workspace::stackingOrder() already contains all windows. This change repurposes Workspace::allClientList() from a list of "normal" windows to all windows, i.e. Workspace::windows(), to be consistent. There's one API change though. Scripting API will expose other window types too. This is an intentional change so scripted effects could operate with all windows. It also matches the current behavior observed in libkwineffects, which exposes all windows as well.
2023-03-13 11:54:38 +00:00
QSignalSpy windowAddedSpy(workspace(), &Workspace::windowAdded);
Support modifier mouse/scroll action on internal decorated windows Summary: This fixes the problem that alt+lmb did not start unrestricted move resize for the Debug Console. BUG: 374880 FIXED-IN: 5.12.3 Test Plan: New test case and manual testing whether alt+lmb/rmb works Reviewers: #kwin, #plasma Subscribers: plasma-devel, kwin Tags: #plasma Differential Revision: https://phabricator.kde.org/D10440
2018-02-11 09:49:31 +00:00
HelperWindow win;
win.setGeometry(0, 0, 100, 100);
win.setFlags(win.flags() & ~Qt::FramelessWindowHint);
win.show();
Prefer the term "window" over "client" in Workspace
2022-04-23 08:33:23 +00:00
QTRY_COMPARE(windowAddedSpy.count(), 1);
autotests: client -> window
2022-04-23 19:51:16 +00:00
auto internalWindow = windowAddedSpy.first().first().value<InternalWindow *>();
QVERIFY(internalWindow);
QVERIFY(internalWindow->isDecorated());
Support modifier mouse/scroll action on internal decorated windows Summary: This fixes the problem that alt+lmb did not start unrestricted move resize for the Debug Console. BUG: 374880 FIXED-IN: 5.12.3 Test Plan: New test case and manual testing whether alt+lmb/rmb works Reviewers: #kwin, #plasma Subscribers: plasma-devel, kwin Tags: #plasma Differential Revision: https://phabricator.kde.org/D10440
2018-02-11 09:49:31 +00:00
KConfigGroup group = kwinApp()->config()->group("MouseBindings");
Change CommandAllKey to Meta Summary: Alt + Left Click to move windows has a tendency to conflict with creative workflow apps. While Alt can be changed to Meta in KWin's settings, Alt + Left Click shortcuts often cannot be customized in apps. Rather than making every user who runs into this problem change their settings, we should change our default settings to improve KWin's default usability. The fact that Alt + Left Click to move windows is older does not matter. We are trying to use Meta for global/shell shortcuts anyway. BUG: 399375 Test Plan: The relevant parts of the relevant tests pass. kwin-testInternalWindow fails, but for unrelated reasons that have something to do with XWayland.
2020-05-06 09:17:44 +00:00
group.writeEntry("CommandAllKey", "Meta");
Support modifier mouse/scroll action on internal decorated windows Summary: This fixes the problem that alt+lmb did not start unrestricted move resize for the Debug Console. BUG: 374880 FIXED-IN: 5.12.3 Test Plan: New test case and manual testing whether alt+lmb/rmb works Reviewers: #kwin, #plasma Subscribers: plasma-devel, kwin Tags: #plasma Differential Revision: https://phabricator.kde.org/D10440
2018-02-11 09:49:31 +00:00
group.writeEntry("CommandAll1", "Move");
group.writeEntry("CommandAll2", "Move");
group.writeEntry("CommandAll3", "Move");
group.sync();
workspace()->slotReconfigure();
Change CommandAllKey to Meta Summary: Alt + Left Click to move windows has a tendency to conflict with creative workflow apps. While Alt can be changed to Meta in KWin's settings, Alt + Left Click shortcuts often cannot be customized in apps. Rather than making every user who runs into this problem change their settings, we should change our default settings to improve KWin's default usability. The fact that Alt + Left Click to move windows is older does not matter. We are trying to use Meta for global/shell shortcuts anyway. BUG: 399375 Test Plan: The relevant parts of the relevant tests pass. kwin-testInternalWindow fails, but for unrelated reasons that have something to do with XWayland.
2020-05-06 09:17:44 +00:00
QCOMPARE(options->commandAllModifier(), Qt::MetaModifier);
Support modifier mouse/scroll action on internal decorated windows Summary: This fixes the problem that alt+lmb did not start unrestricted move resize for the Debug Console. BUG: 374880 FIXED-IN: 5.12.3 Test Plan: New test case and manual testing whether alt+lmb/rmb works Reviewers: #kwin, #plasma Subscribers: plasma-devel, kwin Tags: #plasma Differential Revision: https://phabricator.kde.org/D10440
2018-02-11 09:49:31 +00:00
QCOMPARE(options->commandAll1(), Options::MouseUnrestrictedMove);
QCOMPARE(options->commandAll2(), Options::MouseUnrestrictedMove);
QCOMPARE(options->commandAll3(), Options::MouseUnrestrictedMove);
// move cursor on window
Port away from Cursor::setPos() Use input device specific apis to change the position of the cursor. The main reason to do so is to break the assumption that Cursor position is the same as pointer position, which I would like to rely on later to merge tablet and pointer cursors.
2023-02-09 13:07:56 +00:00
input()->pointer()->warp(internalWindow->frameGeometry().center());
Support modifier mouse/scroll action on internal decorated windows Summary: This fixes the problem that alt+lmb did not start unrestricted move resize for the Debug Console. BUG: 374880 FIXED-IN: 5.12.3 Test Plan: New test case and manual testing whether alt+lmb/rmb works Reviewers: #kwin, #plasma Subscribers: plasma-devel, kwin Tags: #plasma Differential Revision: https://phabricator.kde.org/D10440
2018-02-11 09:49:31 +00:00
// simulate modifier+click
quint32 timestamp = 1;
Migrate all autotest input simulation functions [5/6] Make autotests create fake input devices Migrate all input simulation functions from kwinApp()->platform()->... to the their counter part in the Test namespace.
2022-03-10 10:27:35 +00:00
Test::keyboardKeyPressed(KEY_LEFTMETA, timestamp++);
autotests: client -> window
2022-04-23 19:51:16 +00:00
QVERIFY(!internalWindow->isInteractiveMove());
Migrate all autotest input simulation functions [5/6] Make autotests create fake input devices Migrate all input simulation functions from kwinApp()->platform()->... to the their counter part in the Test namespace.
2022-03-10 10:27:35 +00:00
Test::pointerButtonPressed(BTN_LEFT, timestamp++);
autotests: client -> window
2022-04-23 19:51:16 +00:00
QVERIFY(internalWindow->isInteractiveMove());
Support modifier mouse/scroll action on internal decorated windows Summary: This fixes the problem that alt+lmb did not start unrestricted move resize for the Debug Console. BUG: 374880 FIXED-IN: 5.12.3 Test Plan: New test case and manual testing whether alt+lmb/rmb works Reviewers: #kwin, #plasma Subscribers: plasma-devel, kwin Tags: #plasma Differential Revision: https://phabricator.kde.org/D10440
2018-02-11 09:49:31 +00:00
// release modifier should not change it
Migrate all autotest input simulation functions [5/6] Make autotests create fake input devices Migrate all input simulation functions from kwinApp()->platform()->... to the their counter part in the Test namespace.
2022-03-10 10:27:35 +00:00
Test::keyboardKeyReleased(KEY_LEFTMETA, timestamp++);
autotests: client -> window
2022-04-23 19:51:16 +00:00
QVERIFY(internalWindow->isInteractiveMove());
Support modifier mouse/scroll action on internal decorated windows Summary: This fixes the problem that alt+lmb did not start unrestricted move resize for the Debug Console. BUG: 374880 FIXED-IN: 5.12.3 Test Plan: New test case and manual testing whether alt+lmb/rmb works Reviewers: #kwin, #plasma Subscribers: plasma-devel, kwin Tags: #plasma Differential Revision: https://phabricator.kde.org/D10440
2018-02-11 09:49:31 +00:00
// but releasing the key should end move/resize
Migrate all autotest input simulation functions [5/6] Make autotests create fake input devices Migrate all input simulation functions from kwinApp()->platform()->... to the their counter part in the Test namespace.
2022-03-10 10:27:35 +00:00
Test::pointerButtonReleased(BTN_LEFT, timestamp++);
autotests: client -> window
2022-04-23 19:51:16 +00:00
QVERIFY(!internalWindow->isInteractiveMove());
Support modifier mouse/scroll action on internal decorated windows Summary: This fixes the problem that alt+lmb did not start unrestricted move resize for the Debug Console. BUG: 374880 FIXED-IN: 5.12.3 Test Plan: New test case and manual testing whether alt+lmb/rmb works Reviewers: #kwin, #plasma Subscribers: plasma-devel, kwin Tags: #plasma Differential Revision: https://phabricator.kde.org/D10440
2018-02-11 09:49:31 +00:00
}
void InternalWindowTest::testModifierScroll()
{
Make Workspace::allClientList() return all windows Currently windows are scattered in a few separate lists. If you need to go through the windows, you have to do it piece by piece. On the other hand, with the overhaul of window types, we've started converging towards one universal type: Window. Keeping windows in the separate buckets goes against this design. Workspace::stackingOrder() already contains all windows. This change repurposes Workspace::allClientList() from a list of "normal" windows to all windows, i.e. Workspace::windows(), to be consistent. There's one API change though. Scripting API will expose other window types too. This is an intentional change so scripted effects could operate with all windows. It also matches the current behavior observed in libkwineffects, which exposes all windows as well.
2023-03-13 11:54:38 +00:00
QSignalSpy windowAddedSpy(workspace(), &Workspace::windowAdded);
Support modifier mouse/scroll action on internal decorated windows Summary: This fixes the problem that alt+lmb did not start unrestricted move resize for the Debug Console. BUG: 374880 FIXED-IN: 5.12.3 Test Plan: New test case and manual testing whether alt+lmb/rmb works Reviewers: #kwin, #plasma Subscribers: plasma-devel, kwin Tags: #plasma Differential Revision: https://phabricator.kde.org/D10440
2018-02-11 09:49:31 +00:00
HelperWindow win;
win.setGeometry(0, 0, 100, 100);
win.setFlags(win.flags() & ~Qt::FramelessWindowHint);
win.show();
Prefer the term "window" over "client" in Workspace
2022-04-23 08:33:23 +00:00
QTRY_COMPARE(windowAddedSpy.count(), 1);
autotests: client -> window
2022-04-23 19:51:16 +00:00
auto internalWindow = windowAddedSpy.first().first().value<InternalWindow *>();
QVERIFY(internalWindow);
QVERIFY(internalWindow->isDecorated());
Support modifier mouse/scroll action on internal decorated windows Summary: This fixes the problem that alt+lmb did not start unrestricted move resize for the Debug Console. BUG: 374880 FIXED-IN: 5.12.3 Test Plan: New test case and manual testing whether alt+lmb/rmb works Reviewers: #kwin, #plasma Subscribers: plasma-devel, kwin Tags: #plasma Differential Revision: https://phabricator.kde.org/D10440
2018-02-11 09:49:31 +00:00
KConfigGroup group = kwinApp()->config()->group("MouseBindings");
Change CommandAllKey to Meta Summary: Alt + Left Click to move windows has a tendency to conflict with creative workflow apps. While Alt can be changed to Meta in KWin's settings, Alt + Left Click shortcuts often cannot be customized in apps. Rather than making every user who runs into this problem change their settings, we should change our default settings to improve KWin's default usability. The fact that Alt + Left Click to move windows is older does not matter. We are trying to use Meta for global/shell shortcuts anyway. BUG: 399375 Test Plan: The relevant parts of the relevant tests pass. kwin-testInternalWindow fails, but for unrelated reasons that have something to do with XWayland.
2020-05-06 09:17:44 +00:00
group.writeEntry("CommandAllKey", "Meta");
Support modifier mouse/scroll action on internal decorated windows Summary: This fixes the problem that alt+lmb did not start unrestricted move resize for the Debug Console. BUG: 374880 FIXED-IN: 5.12.3 Test Plan: New test case and manual testing whether alt+lmb/rmb works Reviewers: #kwin, #plasma Subscribers: plasma-devel, kwin Tags: #plasma Differential Revision: https://phabricator.kde.org/D10440
2018-02-11 09:49:31 +00:00
group.writeEntry("CommandAllWheel", "change opacity");
group.sync();
workspace()->slotReconfigure();
// move cursor on window
Port away from Cursor::setPos() Use input device specific apis to change the position of the cursor. The main reason to do so is to break the assumption that Cursor position is the same as pointer position, which I would like to rely on later to merge tablet and pointer cursors.
2023-02-09 13:07:56 +00:00
input()->pointer()->warp(internalWindow->frameGeometry().center());
Support modifier mouse/scroll action on internal decorated windows Summary: This fixes the problem that alt+lmb did not start unrestricted move resize for the Debug Console. BUG: 374880 FIXED-IN: 5.12.3 Test Plan: New test case and manual testing whether alt+lmb/rmb works Reviewers: #kwin, #plasma Subscribers: plasma-devel, kwin Tags: #plasma Differential Revision: https://phabricator.kde.org/D10440
2018-02-11 09:49:31 +00:00
// set the opacity to 0.5
autotests: client -> window
2022-04-23 19:51:16 +00:00
internalWindow->setOpacity(0.5);
QCOMPARE(internalWindow->opacity(), 0.5);
Support modifier mouse/scroll action on internal decorated windows Summary: This fixes the problem that alt+lmb did not start unrestricted move resize for the Debug Console. BUG: 374880 FIXED-IN: 5.12.3 Test Plan: New test case and manual testing whether alt+lmb/rmb works Reviewers: #kwin, #plasma Subscribers: plasma-devel, kwin Tags: #plasma Differential Revision: https://phabricator.kde.org/D10440
2018-02-11 09:49:31 +00:00
quint32 timestamp = 1;
Migrate all autotest input simulation functions [5/6] Make autotests create fake input devices Migrate all input simulation functions from kwinApp()->platform()->... to the their counter part in the Test namespace.
2022-03-10 10:27:35 +00:00
Test::keyboardKeyPressed(KEY_LEFTMETA, timestamp++);
Test::pointerAxisVertical(-5, timestamp++);
autotests: client -> window
2022-04-23 19:51:16 +00:00
QCOMPARE(internalWindow->opacity(), 0.6);
Migrate all autotest input simulation functions [5/6] Make autotests create fake input devices Migrate all input simulation functions from kwinApp()->platform()->... to the their counter part in the Test namespace.
2022-03-10 10:27:35 +00:00
Test::pointerAxisVertical(5, timestamp++);
autotests: client -> window
2022-04-23 19:51:16 +00:00
QCOMPARE(internalWindow->opacity(), 0.5);
Migrate all autotest input simulation functions [5/6] Make autotests create fake input devices Migrate all input simulation functions from kwinApp()->platform()->... to the their counter part in the Test namespace.
2022-03-10 10:27:35 +00:00
Test::keyboardKeyReleased(KEY_LEFTMETA, timestamp++);
Support modifier mouse/scroll action on internal decorated windows Summary: This fixes the problem that alt+lmb did not start unrestricted move resize for the Debug Console. BUG: 374880 FIXED-IN: 5.12.3 Test Plan: New test case and manual testing whether alt+lmb/rmb works Reviewers: #kwin, #plasma Subscribers: plasma-devel, kwin Tags: #plasma Differential Revision: https://phabricator.kde.org/D10440
2018-02-11 09:49:31 +00:00
}
Implement isPopupWindow for internal windows Summary: Just accessing Qt::Popup WindowFlag. BUG: 402852 Test Plan: Not tested for the described problematic case Reviewers: #kwin Subscribers: kwin Tags: #kwin Differential Revision: https://phabricator.kde.org/D17981
2019-01-05 10:10:33 +00:00
void InternalWindowTest::testPopup()
{
Make Workspace::allClientList() return all windows Currently windows are scattered in a few separate lists. If you need to go through the windows, you have to do it piece by piece. On the other hand, with the overhaul of window types, we've started converging towards one universal type: Window. Keeping windows in the separate buckets goes against this design. Workspace::stackingOrder() already contains all windows. This change repurposes Workspace::allClientList() from a list of "normal" windows to all windows, i.e. Workspace::windows(), to be consistent. There's one API change though. Scripting API will expose other window types too. This is an intentional change so scripted effects could operate with all windows. It also matches the current behavior observed in libkwineffects, which exposes all windows as well.
2023-03-13 11:54:38 +00:00
QSignalSpy windowAddedSpy(workspace(), &Workspace::windowAdded);
Implement isPopupWindow for internal windows Summary: Just accessing Qt::Popup WindowFlag. BUG: 402852 Test Plan: Not tested for the described problematic case Reviewers: #kwin Subscribers: kwin Tags: #kwin Differential Revision: https://phabricator.kde.org/D17981
2019-01-05 10:10:33 +00:00
HelperWindow win;
win.setGeometry(0, 0, 100, 100);
win.setFlags(win.flags() | Qt::Popup);
win.show();
Prefer the term "window" over "client" in Workspace
2022-04-23 08:33:23 +00:00
QTRY_COMPARE(windowAddedSpy.count(), 1);
autotests: client -> window
2022-04-23 19:51:16 +00:00
auto internalWindow = windowAddedSpy.first().first().value<InternalWindow *>();
QVERIFY(internalWindow);
QCOMPARE(internalWindow->isPopupWindow(), true);
Implement isPopupWindow for internal windows Summary: Just accessing Qt::Popup WindowFlag. BUG: 402852 Test Plan: Not tested for the described problematic case Reviewers: #kwin Subscribers: kwin Tags: #kwin Differential Revision: https://phabricator.kde.org/D17981
2019-01-05 10:10:33 +00:00
}
Add high DPI support to internal KWin windows Summary: So far we didn't try to do high DPI on kwin internal windows, such as the user context menu and tab bars and whatever. Due to wayland scaling they were the correct phyiscal size but upscaled. This patch fixes our QPA to enable Qt's high-dpi support. BUG: 402853 Note icons are still low res. This is because the global QGuiApplication::devicePixelRatio which is the max of all connected screens is static for the duration of the app. QIcon uses this when determining the DPR to use. This will require a Qt change. Test Plan: Ran at 2x on my normal DPI screen (as that's easier to see anything) * User action menu is high DPI * Window deco tooltips are still fine * Tab switcher is high DPI * Overlay in present windows Desktop grid are still ok Reviewers: #kwin Subscribers: zzag, kwin Tags: #kwin Differential Revision: https://phabricator.kde.org/D18042
2019-01-11 22:48:04 +00:00
void InternalWindowTest::testScale()
{
autotests: directly call setVirtualOutputs
2023-05-08 10:16:00 +00:00
Test::setOutputConfig({
Test::OutputInfo{
.geometry = QRect(0, 0, 1280, 1024),
.scale = 2.0,
},
Test::OutputInfo{
.geometry = QRect(1280, 0, 1280, 1024),
.scale = 2.0,
},
});
Make Workspace::allClientList() return all windows Currently windows are scattered in a few separate lists. If you need to go through the windows, you have to do it piece by piece. On the other hand, with the overhaul of window types, we've started converging towards one universal type: Window. Keeping windows in the separate buckets goes against this design. Workspace::stackingOrder() already contains all windows. This change repurposes Workspace::allClientList() from a list of "normal" windows to all windows, i.e. Workspace::windows(), to be consistent. There's one API change though. Scripting API will expose other window types too. This is an intentional change so scripted effects could operate with all windows. It also matches the current behavior observed in libkwineffects, which exposes all windows as well.
2023-03-13 11:54:38 +00:00
QSignalSpy windowAddedSpy(workspace(), &Workspace::windowAdded);
Add high DPI support to internal KWin windows Summary: So far we didn't try to do high DPI on kwin internal windows, such as the user context menu and tab bars and whatever. Due to wayland scaling they were the correct phyiscal size but upscaled. This patch fixes our QPA to enable Qt's high-dpi support. BUG: 402853 Note icons are still low res. This is because the global QGuiApplication::devicePixelRatio which is the max of all connected screens is static for the duration of the app. QIcon uses this when determining the DPR to use. This will require a Qt change. Test Plan: Ran at 2x on my normal DPI screen (as that's easier to see anything) * User action menu is high DPI * Window deco tooltips are still fine * Tab switcher is high DPI * Overlay in present windows Desktop grid are still ok Reviewers: #kwin Subscribers: zzag, kwin Tags: #kwin Differential Revision: https://phabricator.kde.org/D18042
2019-01-11 22:48:04 +00:00
HelperWindow win;
win.setGeometry(0, 0, 100, 100);
win.setFlags(win.flags() | Qt::Popup);
win.show();
QCOMPARE(win.devicePixelRatio(), 2.0);
Prefer the term "window" over "client" in Workspace
2022-04-23 08:33:23 +00:00
QTRY_COMPARE(windowAddedSpy.count(), 1);
autotests: client -> window
2022-04-23 19:51:16 +00:00
auto internalWindow = windowAddedSpy.first().first().value<InternalWindow *>();
QCOMPARE(internalWindow->bufferScale(), 2);
Add high DPI support to internal KWin windows Summary: So far we didn't try to do high DPI on kwin internal windows, such as the user context menu and tab bars and whatever. Due to wayland scaling they were the correct phyiscal size but upscaled. This patch fixes our QPA to enable Qt's high-dpi support. BUG: 402853 Note icons are still low res. This is because the global QGuiApplication::devicePixelRatio which is the max of all connected screens is static for the duration of the app. QIcon uses this when determining the DPR to use. This will require a Qt change. Test Plan: Ran at 2x on my normal DPI screen (as that's easier to see anything) * User action menu is high DPI * Window deco tooltips are still fine * Tab switcher is high DPI * Overlay in present windows Desktop grid are still ok Reviewers: #kwin Subscribers: zzag, kwin Tags: #kwin Differential Revision: https://phabricator.kde.org/D18042
2019-01-11 22:48:04 +00:00
}
Add windowsystem plugin for KWin's qpa Summary: KWindowSystem provides a plugin interface to have platform specific implementations. So far KWin relied on the implementation in KWayland-integration repository. This is something I find unsuited, for the following reasons: * any test in KWin for functionality set through the plugin would fail * it's not clear what's going on where * in worst case some code could deadlock * KWin shouldn't use KWindowSystem and only a small subset is allowed to be used The last point needs some further explanation. KWin internally does not and cannot use KWindowSystem. KWindowSystem (especially KWindowInfo) is exposing information which KWin sets. It's more than weird if KWin asks KWindowSystem for the state of a window it set itself. On X11 it's just slow, on Wayland it can result in roundtrips to KWin itself which is dangerous. But due to using Plasma components we have a few areas where we use KWindowSystem. E.g. a Plasma::Dialog sets a window type, the slide in direction, blur and background contrast. This we want to support and need to support. Other API elements we do not want, like for examples the available windows. KWin internal windows either have direct access to KWin or a scripting interface exposed providing (limited) access - there is just no need to have this in KWindowSystem. To make it more clear what KWin supports as API of KWindowSystem for internal windows this change implements a stripped down version of the kwayland-integration plugin. The main difference is that it does not use KWayland at all, but a QWindow internal side channel. To support this EffectWindow provides an accessor for internalWindow and the three already mentioned effects are adjusted to read from the internal QWindow and it's dynamic properties. This change is a first step for a further refactoring. I plan to split the internal window out of ShellClient into a dedicated class. I think there are nowadays too many special cases. If it moves out there is the question whether we really want to use Wayland for the internal windows or whether this is just historic ballast (after all we used to use qwayland for that in the beginning). As the change could introduce regressions I'm targetting 5.16. Test Plan: new test case for window type, manual testing using Alt+Tab for the effects integration. Sliding popups, blur and contrast worked fine. Reviewers: #kwin Subscribers: kwin Tags: #kwin Differential Revision: https://phabricator.kde.org/D18228
2019-01-13 16:50:32 +00:00
void InternalWindowTest::testWindowType_data()
{
QTest::addColumn<NET::WindowType>("windowType");
QTest::newRow("normal") << NET::Normal;
QTest::newRow("desktop") << NET::Desktop;
QTest::newRow("Dock") << NET::Dock;
QTest::newRow("Toolbar") << NET::Toolbar;
QTest::newRow("Menu") << NET::Menu;
QTest::newRow("Dialog") << NET::Dialog;
QTest::newRow("Utility") << NET::Utility;
QTest::newRow("Splash") << NET::Splash;
QTest::newRow("DropdownMenu") << NET::DropdownMenu;
QTest::newRow("PopupMenu") << NET::PopupMenu;
QTest::newRow("Tooltip") << NET::Tooltip;
QTest::newRow("Notification") << NET::Notification;
QTest::newRow("ComboBox") << NET::ComboBox;
QTest::newRow("OnScreenDisplay") << NET::OnScreenDisplay;
Support CriticalNotification type and place it in a CriticalNotificationLayer Differential Revision: https://phabricator.kde.org/D20629
2019-05-02 08:29:38 +00:00
QTest::newRow("CriticalNotification") << NET::CriticalNotification;
Support new AppletPopup window type See the discussion in https://invent.kde.org/frameworks/plasma-framework/-/merge_requests/500. BUG: 411462 BUG: 332512 FIXED-IN: 5.25
2022-05-27 21:49:37 +00:00
QTest::newRow("AppletPopup") << NET::AppletPopup;
Add windowsystem plugin for KWin's qpa Summary: KWindowSystem provides a plugin interface to have platform specific implementations. So far KWin relied on the implementation in KWayland-integration repository. This is something I find unsuited, for the following reasons: * any test in KWin for functionality set through the plugin would fail * it's not clear what's going on where * in worst case some code could deadlock * KWin shouldn't use KWindowSystem and only a small subset is allowed to be used The last point needs some further explanation. KWin internally does not and cannot use KWindowSystem. KWindowSystem (especially KWindowInfo) is exposing information which KWin sets. It's more than weird if KWin asks KWindowSystem for the state of a window it set itself. On X11 it's just slow, on Wayland it can result in roundtrips to KWin itself which is dangerous. But due to using Plasma components we have a few areas where we use KWindowSystem. E.g. a Plasma::Dialog sets a window type, the slide in direction, blur and background contrast. This we want to support and need to support. Other API elements we do not want, like for examples the available windows. KWin internal windows either have direct access to KWin or a scripting interface exposed providing (limited) access - there is just no need to have this in KWindowSystem. To make it more clear what KWin supports as API of KWindowSystem for internal windows this change implements a stripped down version of the kwayland-integration plugin. The main difference is that it does not use KWayland at all, but a QWindow internal side channel. To support this EffectWindow provides an accessor for internalWindow and the three already mentioned effects are adjusted to read from the internal QWindow and it's dynamic properties. This change is a first step for a further refactoring. I plan to split the internal window out of ShellClient into a dedicated class. I think there are nowadays too many special cases. If it moves out there is the question whether we really want to use Wayland for the internal windows or whether this is just historic ballast (after all we used to use qwayland for that in the beginning). As the change could introduce regressions I'm targetting 5.16. Test Plan: new test case for window type, manual testing using Alt+Tab for the effects integration. Sliding popups, blur and contrast worked fine. Reviewers: #kwin Subscribers: kwin Tags: #kwin Differential Revision: https://phabricator.kde.org/D18228
2019-01-13 16:50:32 +00:00
}
void InternalWindowTest::testWindowType()
{
Make Workspace::allClientList() return all windows Currently windows are scattered in a few separate lists. If you need to go through the windows, you have to do it piece by piece. On the other hand, with the overhaul of window types, we've started converging towards one universal type: Window. Keeping windows in the separate buckets goes against this design. Workspace::stackingOrder() already contains all windows. This change repurposes Workspace::allClientList() from a list of "normal" windows to all windows, i.e. Workspace::windows(), to be consistent. There's one API change though. Scripting API will expose other window types too. This is an intentional change so scripted effects could operate with all windows. It also matches the current behavior observed in libkwineffects, which exposes all windows as well.
2023-03-13 11:54:38 +00:00
QSignalSpy windowAddedSpy(workspace(), &Workspace::windowAdded);
Add windowsystem plugin for KWin's qpa Summary: KWindowSystem provides a plugin interface to have platform specific implementations. So far KWin relied on the implementation in KWayland-integration repository. This is something I find unsuited, for the following reasons: * any test in KWin for functionality set through the plugin would fail * it's not clear what's going on where * in worst case some code could deadlock * KWin shouldn't use KWindowSystem and only a small subset is allowed to be used The last point needs some further explanation. KWin internally does not and cannot use KWindowSystem. KWindowSystem (especially KWindowInfo) is exposing information which KWin sets. It's more than weird if KWin asks KWindowSystem for the state of a window it set itself. On X11 it's just slow, on Wayland it can result in roundtrips to KWin itself which is dangerous. But due to using Plasma components we have a few areas where we use KWindowSystem. E.g. a Plasma::Dialog sets a window type, the slide in direction, blur and background contrast. This we want to support and need to support. Other API elements we do not want, like for examples the available windows. KWin internal windows either have direct access to KWin or a scripting interface exposed providing (limited) access - there is just no need to have this in KWindowSystem. To make it more clear what KWin supports as API of KWindowSystem for internal windows this change implements a stripped down version of the kwayland-integration plugin. The main difference is that it does not use KWayland at all, but a QWindow internal side channel. To support this EffectWindow provides an accessor for internalWindow and the three already mentioned effects are adjusted to read from the internal QWindow and it's dynamic properties. This change is a first step for a further refactoring. I plan to split the internal window out of ShellClient into a dedicated class. I think there are nowadays too many special cases. If it moves out there is the question whether we really want to use Wayland for the internal windows or whether this is just historic ballast (after all we used to use qwayland for that in the beginning). As the change could introduce regressions I'm targetting 5.16. Test Plan: new test case for window type, manual testing using Alt+Tab for the effects integration. Sliding popups, blur and contrast worked fine. Reviewers: #kwin Subscribers: kwin Tags: #kwin Differential Revision: https://phabricator.kde.org/D18228
2019-01-13 16:50:32 +00:00
HelperWindow win;
win.setGeometry(0, 0, 100, 100);
QFETCH(NET::WindowType, windowType);
KWindowSystem::setType(win.winId(), windowType);
win.show();
Prefer the term "window" over "client" in Workspace
2022-04-23 08:33:23 +00:00
QTRY_COMPARE(windowAddedSpy.count(), 1);
autotests: client -> window
2022-04-23 19:51:16 +00:00
auto internalWindow = windowAddedSpy.first().first().value<InternalWindow *>();
QVERIFY(internalWindow);
QCOMPARE(internalWindow->windowType(), windowType);
Add windowsystem plugin for KWin's qpa Summary: KWindowSystem provides a plugin interface to have platform specific implementations. So far KWin relied on the implementation in KWayland-integration repository. This is something I find unsuited, for the following reasons: * any test in KWin for functionality set through the plugin would fail * it's not clear what's going on where * in worst case some code could deadlock * KWin shouldn't use KWindowSystem and only a small subset is allowed to be used The last point needs some further explanation. KWin internally does not and cannot use KWindowSystem. KWindowSystem (especially KWindowInfo) is exposing information which KWin sets. It's more than weird if KWin asks KWindowSystem for the state of a window it set itself. On X11 it's just slow, on Wayland it can result in roundtrips to KWin itself which is dangerous. But due to using Plasma components we have a few areas where we use KWindowSystem. E.g. a Plasma::Dialog sets a window type, the slide in direction, blur and background contrast. This we want to support and need to support. Other API elements we do not want, like for examples the available windows. KWin internal windows either have direct access to KWin or a scripting interface exposed providing (limited) access - there is just no need to have this in KWindowSystem. To make it more clear what KWin supports as API of KWindowSystem for internal windows this change implements a stripped down version of the kwayland-integration plugin. The main difference is that it does not use KWayland at all, but a QWindow internal side channel. To support this EffectWindow provides an accessor for internalWindow and the three already mentioned effects are adjusted to read from the internal QWindow and it's dynamic properties. This change is a first step for a further refactoring. I plan to split the internal window out of ShellClient into a dedicated class. I think there are nowadays too many special cases. If it moves out there is the question whether we really want to use Wayland for the internal windows or whether this is just historic ballast (after all we used to use qwayland for that in the beginning). As the change could introduce regressions I'm targetting 5.16. Test Plan: new test case for window type, manual testing using Alt+Tab for the effects integration. Sliding popups, blur and contrast worked fine. Reviewers: #kwin Subscribers: kwin Tags: #kwin Differential Revision: https://phabricator.kde.org/D18228
2019-01-13 16:50:32 +00:00
}
void InternalWindowTest::testChangeWindowType_data()
{
QTest::addColumn<NET::WindowType>("windowType");
QTest::newRow("desktop") << NET::Desktop;
QTest::newRow("Dock") << NET::Dock;
QTest::newRow("Toolbar") << NET::Toolbar;
QTest::newRow("Menu") << NET::Menu;
QTest::newRow("Dialog") << NET::Dialog;
QTest::newRow("Utility") << NET::Utility;
QTest::newRow("Splash") << NET::Splash;
QTest::newRow("DropdownMenu") << NET::DropdownMenu;
QTest::newRow("PopupMenu") << NET::PopupMenu;
QTest::newRow("Tooltip") << NET::Tooltip;
QTest::newRow("Notification") << NET::Notification;
QTest::newRow("ComboBox") << NET::ComboBox;
QTest::newRow("OnScreenDisplay") << NET::OnScreenDisplay;
Support CriticalNotification type and place it in a CriticalNotificationLayer Differential Revision: https://phabricator.kde.org/D20629
2019-05-02 08:29:38 +00:00
QTest::newRow("CriticalNotification") << NET::CriticalNotification;
Support new AppletPopup window type See the discussion in https://invent.kde.org/frameworks/plasma-framework/-/merge_requests/500. BUG: 411462 BUG: 332512 FIXED-IN: 5.25
2022-05-27 21:49:37 +00:00
QTest::newRow("AppletPopup") << NET::AppletPopup;
Add windowsystem plugin for KWin's qpa Summary: KWindowSystem provides a plugin interface to have platform specific implementations. So far KWin relied on the implementation in KWayland-integration repository. This is something I find unsuited, for the following reasons: * any test in KWin for functionality set through the plugin would fail * it's not clear what's going on where * in worst case some code could deadlock * KWin shouldn't use KWindowSystem and only a small subset is allowed to be used The last point needs some further explanation. KWin internally does not and cannot use KWindowSystem. KWindowSystem (especially KWindowInfo) is exposing information which KWin sets. It's more than weird if KWin asks KWindowSystem for the state of a window it set itself. On X11 it's just slow, on Wayland it can result in roundtrips to KWin itself which is dangerous. But due to using Plasma components we have a few areas where we use KWindowSystem. E.g. a Plasma::Dialog sets a window type, the slide in direction, blur and background contrast. This we want to support and need to support. Other API elements we do not want, like for examples the available windows. KWin internal windows either have direct access to KWin or a scripting interface exposed providing (limited) access - there is just no need to have this in KWindowSystem. To make it more clear what KWin supports as API of KWindowSystem for internal windows this change implements a stripped down version of the kwayland-integration plugin. The main difference is that it does not use KWayland at all, but a QWindow internal side channel. To support this EffectWindow provides an accessor for internalWindow and the three already mentioned effects are adjusted to read from the internal QWindow and it's dynamic properties. This change is a first step for a further refactoring. I plan to split the internal window out of ShellClient into a dedicated class. I think there are nowadays too many special cases. If it moves out there is the question whether we really want to use Wayland for the internal windows or whether this is just historic ballast (after all we used to use qwayland for that in the beginning). As the change could introduce regressions I'm targetting 5.16. Test Plan: new test case for window type, manual testing using Alt+Tab for the effects integration. Sliding popups, blur and contrast worked fine. Reviewers: #kwin Subscribers: kwin Tags: #kwin Differential Revision: https://phabricator.kde.org/D18228
2019-01-13 16:50:32 +00:00
}
void InternalWindowTest::testChangeWindowType()
{
Make Workspace::allClientList() return all windows Currently windows are scattered in a few separate lists. If you need to go through the windows, you have to do it piece by piece. On the other hand, with the overhaul of window types, we've started converging towards one universal type: Window. Keeping windows in the separate buckets goes against this design. Workspace::stackingOrder() already contains all windows. This change repurposes Workspace::allClientList() from a list of "normal" windows to all windows, i.e. Workspace::windows(), to be consistent. There's one API change though. Scripting API will expose other window types too. This is an intentional change so scripted effects could operate with all windows. It also matches the current behavior observed in libkwineffects, which exposes all windows as well.
2023-03-13 11:54:38 +00:00
QSignalSpy windowAddedSpy(workspace(), &Workspace::windowAdded);
Add windowsystem plugin for KWin's qpa Summary: KWindowSystem provides a plugin interface to have platform specific implementations. So far KWin relied on the implementation in KWayland-integration repository. This is something I find unsuited, for the following reasons: * any test in KWin for functionality set through the plugin would fail * it's not clear what's going on where * in worst case some code could deadlock * KWin shouldn't use KWindowSystem and only a small subset is allowed to be used The last point needs some further explanation. KWin internally does not and cannot use KWindowSystem. KWindowSystem (especially KWindowInfo) is exposing information which KWin sets. It's more than weird if KWin asks KWindowSystem for the state of a window it set itself. On X11 it's just slow, on Wayland it can result in roundtrips to KWin itself which is dangerous. But due to using Plasma components we have a few areas where we use KWindowSystem. E.g. a Plasma::Dialog sets a window type, the slide in direction, blur and background contrast. This we want to support and need to support. Other API elements we do not want, like for examples the available windows. KWin internal windows either have direct access to KWin or a scripting interface exposed providing (limited) access - there is just no need to have this in KWindowSystem. To make it more clear what KWin supports as API of KWindowSystem for internal windows this change implements a stripped down version of the kwayland-integration plugin. The main difference is that it does not use KWayland at all, but a QWindow internal side channel. To support this EffectWindow provides an accessor for internalWindow and the three already mentioned effects are adjusted to read from the internal QWindow and it's dynamic properties. This change is a first step for a further refactoring. I plan to split the internal window out of ShellClient into a dedicated class. I think there are nowadays too many special cases. If it moves out there is the question whether we really want to use Wayland for the internal windows or whether this is just historic ballast (after all we used to use qwayland for that in the beginning). As the change could introduce regressions I'm targetting 5.16. Test Plan: new test case for window type, manual testing using Alt+Tab for the effects integration. Sliding popups, blur and contrast worked fine. Reviewers: #kwin Subscribers: kwin Tags: #kwin Differential Revision: https://phabricator.kde.org/D18228
2019-01-13 16:50:32 +00:00
HelperWindow win;
win.setGeometry(0, 0, 100, 100);
win.show();
Prefer the term "window" over "client" in Workspace
2022-04-23 08:33:23 +00:00
QTRY_COMPARE(windowAddedSpy.count(), 1);
autotests: client -> window
2022-04-23 19:51:16 +00:00
auto internalWindow = windowAddedSpy.first().first().value<InternalWindow *>();
QVERIFY(internalWindow);
QCOMPARE(internalWindow->windowType(), NET::Normal);
Add windowsystem plugin for KWin's qpa Summary: KWindowSystem provides a plugin interface to have platform specific implementations. So far KWin relied on the implementation in KWayland-integration repository. This is something I find unsuited, for the following reasons: * any test in KWin for functionality set through the plugin would fail * it's not clear what's going on where * in worst case some code could deadlock * KWin shouldn't use KWindowSystem and only a small subset is allowed to be used The last point needs some further explanation. KWin internally does not and cannot use KWindowSystem. KWindowSystem (especially KWindowInfo) is exposing information which KWin sets. It's more than weird if KWin asks KWindowSystem for the state of a window it set itself. On X11 it's just slow, on Wayland it can result in roundtrips to KWin itself which is dangerous. But due to using Plasma components we have a few areas where we use KWindowSystem. E.g. a Plasma::Dialog sets a window type, the slide in direction, blur and background contrast. This we want to support and need to support. Other API elements we do not want, like for examples the available windows. KWin internal windows either have direct access to KWin or a scripting interface exposed providing (limited) access - there is just no need to have this in KWindowSystem. To make it more clear what KWin supports as API of KWindowSystem for internal windows this change implements a stripped down version of the kwayland-integration plugin. The main difference is that it does not use KWayland at all, but a QWindow internal side channel. To support this EffectWindow provides an accessor for internalWindow and the three already mentioned effects are adjusted to read from the internal QWindow and it's dynamic properties. This change is a first step for a further refactoring. I plan to split the internal window out of ShellClient into a dedicated class. I think there are nowadays too many special cases. If it moves out there is the question whether we really want to use Wayland for the internal windows or whether this is just historic ballast (after all we used to use qwayland for that in the beginning). As the change could introduce regressions I'm targetting 5.16. Test Plan: new test case for window type, manual testing using Alt+Tab for the effects integration. Sliding popups, blur and contrast worked fine. Reviewers: #kwin Subscribers: kwin Tags: #kwin Differential Revision: https://phabricator.kde.org/D18228
2019-01-13 16:50:32 +00:00
QFETCH(NET::WindowType, windowType);
KWindowSystem::setType(win.winId(), windowType);
autotests: client -> window
2022-04-23 19:51:16 +00:00
QTRY_COMPARE(internalWindow->windowType(), windowType);
Add windowsystem plugin for KWin's qpa Summary: KWindowSystem provides a plugin interface to have platform specific implementations. So far KWin relied on the implementation in KWayland-integration repository. This is something I find unsuited, for the following reasons: * any test in KWin for functionality set through the plugin would fail * it's not clear what's going on where * in worst case some code could deadlock * KWin shouldn't use KWindowSystem and only a small subset is allowed to be used The last point needs some further explanation. KWin internally does not and cannot use KWindowSystem. KWindowSystem (especially KWindowInfo) is exposing information which KWin sets. It's more than weird if KWin asks KWindowSystem for the state of a window it set itself. On X11 it's just slow, on Wayland it can result in roundtrips to KWin itself which is dangerous. But due to using Plasma components we have a few areas where we use KWindowSystem. E.g. a Plasma::Dialog sets a window type, the slide in direction, blur and background contrast. This we want to support and need to support. Other API elements we do not want, like for examples the available windows. KWin internal windows either have direct access to KWin or a scripting interface exposed providing (limited) access - there is just no need to have this in KWindowSystem. To make it more clear what KWin supports as API of KWindowSystem for internal windows this change implements a stripped down version of the kwayland-integration plugin. The main difference is that it does not use KWayland at all, but a QWindow internal side channel. To support this EffectWindow provides an accessor for internalWindow and the three already mentioned effects are adjusted to read from the internal QWindow and it's dynamic properties. This change is a first step for a further refactoring. I plan to split the internal window out of ShellClient into a dedicated class. I think there are nowadays too many special cases. If it moves out there is the question whether we really want to use Wayland for the internal windows or whether this is just historic ballast (after all we used to use qwayland for that in the beginning). As the change could introduce regressions I'm targetting 5.16. Test Plan: new test case for window type, manual testing using Alt+Tab for the effects integration. Sliding popups, blur and contrast worked fine. Reviewers: #kwin Subscribers: kwin Tags: #kwin Differential Revision: https://phabricator.kde.org/D18228
2019-01-13 16:50:32 +00:00
KWindowSystem::setType(win.winId(), NET::Normal);
autotests: client -> window
2022-04-23 19:51:16 +00:00
QTRY_COMPARE(internalWindow->windowType(), NET::Normal);
Add windowsystem plugin for KWin's qpa Summary: KWindowSystem provides a plugin interface to have platform specific implementations. So far KWin relied on the implementation in KWayland-integration repository. This is something I find unsuited, for the following reasons: * any test in KWin for functionality set through the plugin would fail * it's not clear what's going on where * in worst case some code could deadlock * KWin shouldn't use KWindowSystem and only a small subset is allowed to be used The last point needs some further explanation. KWin internally does not and cannot use KWindowSystem. KWindowSystem (especially KWindowInfo) is exposing information which KWin sets. It's more than weird if KWin asks KWindowSystem for the state of a window it set itself. On X11 it's just slow, on Wayland it can result in roundtrips to KWin itself which is dangerous. But due to using Plasma components we have a few areas where we use KWindowSystem. E.g. a Plasma::Dialog sets a window type, the slide in direction, blur and background contrast. This we want to support and need to support. Other API elements we do not want, like for examples the available windows. KWin internal windows either have direct access to KWin or a scripting interface exposed providing (limited) access - there is just no need to have this in KWindowSystem. To make it more clear what KWin supports as API of KWindowSystem for internal windows this change implements a stripped down version of the kwayland-integration plugin. The main difference is that it does not use KWayland at all, but a QWindow internal side channel. To support this EffectWindow provides an accessor for internalWindow and the three already mentioned effects are adjusted to read from the internal QWindow and it's dynamic properties. This change is a first step for a further refactoring. I plan to split the internal window out of ShellClient into a dedicated class. I think there are nowadays too many special cases. If it moves out there is the question whether we really want to use Wayland for the internal windows or whether this is just historic ballast (after all we used to use qwayland for that in the beginning). As the change could introduce regressions I'm targetting 5.16. Test Plan: new test case for window type, manual testing using Alt+Tab for the effects integration. Sliding popups, blur and contrast worked fine. Reviewers: #kwin Subscribers: kwin Tags: #kwin Differential Revision: https://phabricator.kde.org/D18228
2019-01-13 16:50:32 +00:00
}
void InternalWindowTest::testEffectWindow()
{
Make Workspace::allClientList() return all windows Currently windows are scattered in a few separate lists. If you need to go through the windows, you have to do it piece by piece. On the other hand, with the overhaul of window types, we've started converging towards one universal type: Window. Keeping windows in the separate buckets goes against this design. Workspace::stackingOrder() already contains all windows. This change repurposes Workspace::allClientList() from a list of "normal" windows to all windows, i.e. Workspace::windows(), to be consistent. There's one API change though. Scripting API will expose other window types too. This is an intentional change so scripted effects could operate with all windows. It also matches the current behavior observed in libkwineffects, which exposes all windows as well.
2023-03-13 11:54:38 +00:00
QSignalSpy windowAddedSpy(workspace(), &Workspace::windowAdded);
Add windowsystem plugin for KWin's qpa Summary: KWindowSystem provides a plugin interface to have platform specific implementations. So far KWin relied on the implementation in KWayland-integration repository. This is something I find unsuited, for the following reasons: * any test in KWin for functionality set through the plugin would fail * it's not clear what's going on where * in worst case some code could deadlock * KWin shouldn't use KWindowSystem and only a small subset is allowed to be used The last point needs some further explanation. KWin internally does not and cannot use KWindowSystem. KWindowSystem (especially KWindowInfo) is exposing information which KWin sets. It's more than weird if KWin asks KWindowSystem for the state of a window it set itself. On X11 it's just slow, on Wayland it can result in roundtrips to KWin itself which is dangerous. But due to using Plasma components we have a few areas where we use KWindowSystem. E.g. a Plasma::Dialog sets a window type, the slide in direction, blur and background contrast. This we want to support and need to support. Other API elements we do not want, like for examples the available windows. KWin internal windows either have direct access to KWin or a scripting interface exposed providing (limited) access - there is just no need to have this in KWindowSystem. To make it more clear what KWin supports as API of KWindowSystem for internal windows this change implements a stripped down version of the kwayland-integration plugin. The main difference is that it does not use KWayland at all, but a QWindow internal side channel. To support this EffectWindow provides an accessor for internalWindow and the three already mentioned effects are adjusted to read from the internal QWindow and it's dynamic properties. This change is a first step for a further refactoring. I plan to split the internal window out of ShellClient into a dedicated class. I think there are nowadays too many special cases. If it moves out there is the question whether we really want to use Wayland for the internal windows or whether this is just historic ballast (after all we used to use qwayland for that in the beginning). As the change could introduce regressions I'm targetting 5.16. Test Plan: new test case for window type, manual testing using Alt+Tab for the effects integration. Sliding popups, blur and contrast worked fine. Reviewers: #kwin Subscribers: kwin Tags: #kwin Differential Revision: https://phabricator.kde.org/D18228
2019-01-13 16:50:32 +00:00
HelperWindow win;
win.setGeometry(0, 0, 100, 100);
win.show();
Prefer the term "window" over "client" in Workspace
2022-04-23 08:33:23 +00:00
QTRY_COMPARE(windowAddedSpy.count(), 1);
autotests: client -> window
2022-04-23 19:51:16 +00:00
auto internalWindow = windowAddedSpy.first().first().value<InternalWindow *>();
QVERIFY(internalWindow);
QVERIFY(internalWindow->effectWindow());
QCOMPARE(internalWindow->effectWindow()->internalWindow(), &win);
Add windowsystem plugin for KWin's qpa Summary: KWindowSystem provides a plugin interface to have platform specific implementations. So far KWin relied on the implementation in KWayland-integration repository. This is something I find unsuited, for the following reasons: * any test in KWin for functionality set through the plugin would fail * it's not clear what's going on where * in worst case some code could deadlock * KWin shouldn't use KWindowSystem and only a small subset is allowed to be used The last point needs some further explanation. KWin internally does not and cannot use KWindowSystem. KWindowSystem (especially KWindowInfo) is exposing information which KWin sets. It's more than weird if KWin asks KWindowSystem for the state of a window it set itself. On X11 it's just slow, on Wayland it can result in roundtrips to KWin itself which is dangerous. But due to using Plasma components we have a few areas where we use KWindowSystem. E.g. a Plasma::Dialog sets a window type, the slide in direction, blur and background contrast. This we want to support and need to support. Other API elements we do not want, like for examples the available windows. KWin internal windows either have direct access to KWin or a scripting interface exposed providing (limited) access - there is just no need to have this in KWindowSystem. To make it more clear what KWin supports as API of KWindowSystem for internal windows this change implements a stripped down version of the kwayland-integration plugin. The main difference is that it does not use KWayland at all, but a QWindow internal side channel. To support this EffectWindow provides an accessor for internalWindow and the three already mentioned effects are adjusted to read from the internal QWindow and it's dynamic properties. This change is a first step for a further refactoring. I plan to split the internal window out of ShellClient into a dedicated class. I think there are nowadays too many special cases. If it moves out there is the question whether we really want to use Wayland for the internal windows or whether this is just historic ballast (after all we used to use qwayland for that in the beginning). As the change could introduce regressions I'm targetting 5.16. Test Plan: new test case for window type, manual testing using Alt+Tab for the effects integration. Sliding popups, blur and contrast worked fine. Reviewers: #kwin Subscribers: kwin Tags: #kwin Differential Revision: https://phabricator.kde.org/D18228
2019-01-13 16:50:32 +00:00
autotests: client -> window
2022-04-23 19:51:16 +00:00
QCOMPARE(effects->findWindow(&win), internalWindow->effectWindow());
Add windowsystem plugin for KWin's qpa Summary: KWindowSystem provides a plugin interface to have platform specific implementations. So far KWin relied on the implementation in KWayland-integration repository. This is something I find unsuited, for the following reasons: * any test in KWin for functionality set through the plugin would fail * it's not clear what's going on where * in worst case some code could deadlock * KWin shouldn't use KWindowSystem and only a small subset is allowed to be used The last point needs some further explanation. KWin internally does not and cannot use KWindowSystem. KWindowSystem (especially KWindowInfo) is exposing information which KWin sets. It's more than weird if KWin asks KWindowSystem for the state of a window it set itself. On X11 it's just slow, on Wayland it can result in roundtrips to KWin itself which is dangerous. But due to using Plasma components we have a few areas where we use KWindowSystem. E.g. a Plasma::Dialog sets a window type, the slide in direction, blur and background contrast. This we want to support and need to support. Other API elements we do not want, like for examples the available windows. KWin internal windows either have direct access to KWin or a scripting interface exposed providing (limited) access - there is just no need to have this in KWindowSystem. To make it more clear what KWin supports as API of KWindowSystem for internal windows this change implements a stripped down version of the kwayland-integration plugin. The main difference is that it does not use KWayland at all, but a QWindow internal side channel. To support this EffectWindow provides an accessor for internalWindow and the three already mentioned effects are adjusted to read from the internal QWindow and it's dynamic properties. This change is a first step for a further refactoring. I plan to split the internal window out of ShellClient into a dedicated class. I think there are nowadays too many special cases. If it moves out there is the question whether we really want to use Wayland for the internal windows or whether this is just historic ballast (after all we used to use qwayland for that in the beginning). As the change could introduce regressions I'm targetting 5.16. Test Plan: new test case for window type, manual testing using Alt+Tab for the effects integration. Sliding popups, blur and contrast worked fine. Reviewers: #kwin Subscribers: kwin Tags: #kwin Differential Revision: https://phabricator.kde.org/D18228
2019-01-13 16:50:32 +00:00
QCOMPARE(effects->findWindow(&win)->internalWindow(), &win);
}
Add high DPI support to internal KWin windows Summary: So far we didn't try to do high DPI on kwin internal windows, such as the user context menu and tab bars and whatever. Due to wayland scaling they were the correct phyiscal size but upscaled. This patch fixes our QPA to enable Qt's high-dpi support. BUG: 402853 Note icons are still low res. This is because the global QGuiApplication::devicePixelRatio which is the max of all connected screens is static for the duration of the app. QIcon uses this when determining the DPR to use. This will require a Qt change. Test Plan: Ran at 2x on my normal DPI screen (as that's easier to see anything) * User action menu is high DPI * Window deco tooltips are still fine * Tab switcher is high DPI * Overlay in present windows Desktop grid are still ok Reviewers: #kwin Subscribers: zzag, kwin Tags: #kwin Differential Revision: https://phabricator.kde.org/D18042
2019-01-11 22:48:04 +00:00
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 InternalWindowTest::testReentrantMoveResize()
Make setFrameGeometry() re-entrant for X and internal clients If AbstractClient::setFrameGeometry() is called from a slot connected directly to the frameGeometryChanged() signal, then is there a good chance that kwin will fall into an infinite recursion. However, that's the case with only X11 and internal clients. The root cause of the infinite recursion is that both X11Client and InternalClient compare the new geometry against the geometry before update blocking. In order to fix the bug, we simply need to ensure that updateGeometryBeforeUpdateBlocking() has been called before we start emitting the frameGeometryChanged() signal. Furthermore, a couple of tests were added to ensure that we won't hit this subtle bug again.
2020-07-20 19:33:19 +00:00
{
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
// This test verifies that calling moveResize() from a slot connected directly
Make setFrameGeometry() re-entrant for X and internal clients If AbstractClient::setFrameGeometry() is called from a slot connected directly to the frameGeometryChanged() signal, then is there a good chance that kwin will fall into an infinite recursion. However, that's the case with only X11 and internal clients. The root cause of the infinite recursion is that both X11Client and InternalClient compare the new geometry against the geometry before update blocking. In order to fix the bug, we simply need to ensure that updateGeometryBeforeUpdateBlocking() has been called before we start emitting the frameGeometryChanged() signal. Furthermore, a couple of tests were added to ensure that we won't hit this subtle bug again.
2020-07-20 19:33:19 +00:00
// to the frameGeometryChanged() signal won't cause an infinite recursion.
// Create an internal window.
Make Workspace::allClientList() return all windows Currently windows are scattered in a few separate lists. If you need to go through the windows, you have to do it piece by piece. On the other hand, with the overhaul of window types, we've started converging towards one universal type: Window. Keeping windows in the separate buckets goes against this design. Workspace::stackingOrder() already contains all windows. This change repurposes Workspace::allClientList() from a list of "normal" windows to all windows, i.e. Workspace::windows(), to be consistent. There's one API change though. Scripting API will expose other window types too. This is an intentional change so scripted effects could operate with all windows. It also matches the current behavior observed in libkwineffects, which exposes all windows as well.
2023-03-13 11:54:38 +00:00
QSignalSpy windowAddedSpy(workspace(), &Workspace::windowAdded);
Make setFrameGeometry() re-entrant for X and internal clients If AbstractClient::setFrameGeometry() is called from a slot connected directly to the frameGeometryChanged() signal, then is there a good chance that kwin will fall into an infinite recursion. However, that's the case with only X11 and internal clients. The root cause of the infinite recursion is that both X11Client and InternalClient compare the new geometry against the geometry before update blocking. In order to fix the bug, we simply need to ensure that updateGeometryBeforeUpdateBlocking() has been called before we start emitting the frameGeometryChanged() signal. Furthermore, a couple of tests were added to ensure that we won't hit this subtle bug again.
2020-07-20 19:33:19 +00:00
HelperWindow win;
win.setGeometry(0, 0, 100, 100);
win.show();
Prefer the term "window" over "client" in Workspace
2022-04-23 08:33:23 +00:00
QTRY_COMPARE(windowAddedSpy.count(), 1);
autotests: client -> window
2022-04-23 19:51:16 +00:00
auto window = windowAddedSpy.first().first().value<InternalWindow *>();
QVERIFY(window);
QCOMPARE(window->pos(), QPoint(0, 0));
Make setFrameGeometry() re-entrant for X and internal clients If AbstractClient::setFrameGeometry() is called from a slot connected directly to the frameGeometryChanged() signal, then is there a good chance that kwin will fall into an infinite recursion. However, that's the case with only X11 and internal clients. The root cause of the infinite recursion is that both X11Client and InternalClient compare the new geometry against the geometry before update blocking. In order to fix the bug, we simply need to ensure that updateGeometryBeforeUpdateBlocking() has been called before we start emitting the frameGeometryChanged() signal. Furthermore, a couple of tests were added to ensure that we won't hit this subtle bug again.
2020-07-20 19:33:19 +00:00
autotests: client -> window
2022-04-23 19:51:16 +00:00
// Let's pretend that there is a script that really wants the window to be at (100, 100).
connect(window, &Window::frameGeometryChanged, this, [window]() {
Use floating geometry throughout With fractional scaling integer based logical geometry may not match device pixels. Once we have a floating point base we can fix that. This also is important for our X11 scale override, with a scale of 2 we could get logical sizes with halves. We already have all input being floating point, this doubles down on it for all remaining geometry. - Outputs remain integer to ensure that any screen on the right remains aligned. - Placement also remains integer based for now. - Repainting is untouched as we always expand outwards (QRectF::toAdjustedRect(). - Decoration is untouched for now - Rules are integer in the config, but floating in the adjusting/API This should also be fine. At some point we'll add a method to snap to the device pixel grid. Effectively `round(value * dpr) / dpr` though right now things mostly work. This also gets rid of a lot of hacks for QRect right and bottom which are very confusing. Parts to watch out in the port are: QRectF::contains now includes edges QRectF::right and bottom are now sane so previous hacks have to be removed QRectF(QPoint, QPoint) behaves differently for the same reason QRectF::center too In test results some adjusted values which are the result of QRect.center because using QRectF's center should behave the same to the user.
2022-05-16 20:13:39 +00:00
window->moveResize(QRectF(QPointF(100, 100), window->size()));
Make setFrameGeometry() re-entrant for X and internal clients If AbstractClient::setFrameGeometry() is called from a slot connected directly to the frameGeometryChanged() signal, then is there a good chance that kwin will fall into an infinite recursion. However, that's the case with only X11 and internal clients. The root cause of the infinite recursion is that both X11Client and InternalClient compare the new geometry against the geometry before update blocking. In order to fix the bug, we simply need to ensure that updateGeometryBeforeUpdateBlocking() has been called before we start emitting the frameGeometryChanged() signal. Furthermore, a couple of tests were added to ensure that we won't hit this subtle bug again.
2020-07-20 19:33:19 +00:00
});
// Trigger the lambda above.
autotests: client -> window
2022-04-23 19:51:16 +00:00
window->move(QPoint(40, 50));
Make setFrameGeometry() re-entrant for X and internal clients If AbstractClient::setFrameGeometry() is called from a slot connected directly to the frameGeometryChanged() signal, then is there a good chance that kwin will fall into an infinite recursion. However, that's the case with only X11 and internal clients. The root cause of the infinite recursion is that both X11Client and InternalClient compare the new geometry against the geometry before update blocking. In order to fix the bug, we simply need to ensure that updateGeometryBeforeUpdateBlocking() has been called before we start emitting the frameGeometryChanged() signal. Furthermore, a couple of tests were added to ensure that we won't hit this subtle bug again.
2020-07-20 19:33:19 +00:00
autotests: client -> window
2022-04-23 19:51:16 +00:00
// Eventually, the window will end up at (100, 100).
QCOMPARE(window->pos(), QPoint(100, 100));
Make setFrameGeometry() re-entrant for X and internal clients If AbstractClient::setFrameGeometry() is called from a slot connected directly to the frameGeometryChanged() signal, then is there a good chance that kwin will fall into an infinite recursion. However, that's the case with only X11 and internal clients. The root cause of the infinite recursion is that both X11Client and InternalClient compare the new geometry against the geometry before update blocking. In order to fix the bug, we simply need to ensure that updateGeometryBeforeUpdateBlocking() has been called before we start emitting the frameGeometryChanged() signal. Furthermore, a couple of tests were added to ensure that we won't hit this subtle bug again.
2020-07-20 19:33:19 +00:00
}
wayland: Introduce internal popup event filter The event filter allows dismissing the user actions menu by clicking anywhere outside of it. BUG: 428408
2021-01-30 20:29:55 +00:00
void InternalWindowTest::testDismissPopup()
{
// This test verifies that a popup window created by the compositor will be dismissed
// when user clicks another window.
// Create a toplevel window.
Make Workspace::allClientList() return all windows Currently windows are scattered in a few separate lists. If you need to go through the windows, you have to do it piece by piece. On the other hand, with the overhaul of window types, we've started converging towards one universal type: Window. Keeping windows in the separate buckets goes against this design. Workspace::stackingOrder() already contains all windows. This change repurposes Workspace::allClientList() from a list of "normal" windows to all windows, i.e. Workspace::windows(), to be consistent. There's one API change though. Scripting API will expose other window types too. This is an intentional change so scripted effects could operate with all windows. It also matches the current behavior observed in libkwineffects, which exposes all windows as well.
2023-03-13 11:54:38 +00:00
QSignalSpy windowAddedSpy(workspace(), &Workspace::windowAdded);
wayland: Introduce internal popup event filter The event filter allows dismissing the user actions menu by clicking anywhere outside of it. BUG: 428408
2021-01-30 20:29:55 +00:00
HelperWindow clientToplevel;
clientToplevel.setGeometry(0, 0, 100, 100);
clientToplevel.show();
Prefer the term "window" over "client" in Workspace
2022-04-23 08:33:23 +00:00
QTRY_COMPARE(windowAddedSpy.count(), 1);
auto serverToplevel = windowAddedSpy.last().first().value<InternalWindow *>();
wayland: Introduce internal popup event filter The event filter allows dismissing the user actions menu by clicking anywhere outside of it. BUG: 428408
2021-01-30 20:29:55 +00:00
QVERIFY(serverToplevel);
// Create a popup window.
QRasterWindow clientPopup;
clientPopup.setFlag(Qt::Popup);
clientPopup.setTransientParent(&clientToplevel);
clientPopup.setGeometry(0, 0, 50, 50);
clientPopup.show();
Prefer the term "window" over "client" in Workspace
2022-04-23 08:33:23 +00:00
QTRY_COMPARE(windowAddedSpy.count(), 2);
auto serverPopup = windowAddedSpy.last().first().value<InternalWindow *>();
wayland: Introduce internal popup event filter The event filter allows dismissing the user actions menu by clicking anywhere outside of it. BUG: 428408
2021-01-30 20:29:55 +00:00
QVERIFY(serverPopup);
Run clang-format The .clang-format file is based on the one in ECM except the following style options: - AlwaysBreakBeforeMultilineStrings - BinPackArguments - BinPackParameters - ColumnLimit - BreakBeforeBraces - KeepEmptyLinesAtTheStartOfBlocks
2022-03-23 10:13:38 +00:00
// Create the other window to click
Fix InternalWindowTest::testDismissPopup We were expecting a tooltip to be closed when clicking its transientParent, but it's explicitly not something we are after. We close popups when we click either other clients or the actual client on the decoration. This change makes it so we end up clicking another window instead of the parent one that is unrelated.
2021-05-07 22:26:21 +00:00
HelperWindow otherClientToplevel;
otherClientToplevel.setGeometry(100, 100, 100, 100);
otherClientToplevel.show();
Prefer the term "window" over "client" in Workspace
2022-04-23 08:33:23 +00:00
QTRY_COMPARE(windowAddedSpy.count(), 3);
auto serverOtherToplevel = windowAddedSpy.last().first().value<InternalWindow *>();
Fix InternalWindowTest::testDismissPopup We were expecting a tooltip to be closed when clicking its transientParent, but it's explicitly not something we are after. We close popups when we click either other clients or the actual client on the decoration. This change makes it so we end up clicking another window instead of the parent one that is unrelated.
2021-05-07 22:26:21 +00:00
QVERIFY(serverOtherToplevel);
wayland: Introduce internal popup event filter The event filter allows dismissing the user actions menu by clicking anywhere outside of it. BUG: 428408
2021-01-30 20:29:55 +00:00
// Click somewhere outside the popup window.
Tidy Window::windowClosed() signal "window" is redundant, so remove it. Also remove the original window argument to improve the API consistency.
2023-03-13 19:21:11 +00:00
QSignalSpy popupClosedSpy(serverPopup, &InternalWindow::closed);
wayland: Introduce internal popup event filter The event filter allows dismissing the user actions menu by clicking anywhere outside of it. BUG: 428408
2021-01-30 20:29:55 +00:00
quint32 timestamp = 0;
Migrate all autotest input simulation functions [5/6] Make autotests create fake input devices Migrate all input simulation functions from kwinApp()->platform()->... to the their counter part in the Test namespace.
2022-03-10 10:27:35 +00:00
Test::pointerMotion(serverOtherToplevel->frameGeometry().center(), timestamp++);
Test::pointerButtonPressed(BTN_LEFT, timestamp++);
wayland: Introduce internal popup event filter The event filter allows dismissing the user actions menu by clicking anywhere outside of it. BUG: 428408
2021-01-30 20:29:55 +00:00
QTRY_COMPARE(popupClosedSpy.count(), 1);
}
[autotest] Add a test for a KWin internal QWindow The test creates a QRasterWindow which through KWin's internal QPA is considered an internal window. In the test methods we simulate various pointer events (enter/leave, press/release, wheel).
2016-02-05 14:39:04 +00:00
}
Fix typo
2016-02-11 08:34:19 +00:00
WAYLANDTEST_MAIN(KWin::InternalWindowTest)
[autotest] Add a test for a KWin internal QWindow The test creates a QRasterWindow which through KWin's internal QPA is considered an internal window. In the test methods we simulate various pointer events (enter/leave, press/release, wheel).
2016-02-05 14:39:04 +00:00
#include "internal_window.moc"
Reference in a new issue Copy permalink