Let's have some tests

[piotr-dobrogost]

It would be good to have some tests so that the project could progress instead of going into circles (assuming it starts moving in the first place :)).

Links of interest

Tutorial 3: Testing Graphical User Interfaces
Squish from Froglogic

This is a followup to #15

[faho]

Well, I don't think either of those really apply (the first is about Qt C++ programs, which this explicitly isn't - we're bound by what the kwin api can do or what we can do externally), but I think I've found something that may be of assistance: http://en.wikipedia.org/wiki/Wmctrl.

The idea is to use bash scripts to start programs and use wmctrl to both control them and check the results. It won't cover everything (e.g. kwin crashes would need to be manually observed), but it should provide for a good foundation.

Sound good to you?

[piotr-dobrogost]

Looks nice but wasn't updated since year 2005 (not sure if it matters). I've sent an email to the author asking if it's alive. If we were to use it from some js test framework then we would have to find a way to invoke it from js and then read output back.
However I did not even manage to do the simplest thing with it like activating some window. I tried this:

$ wmctrl -l -G
0x02000235 4294967295 1680 0    1680 1050 demon plasma-desktop
0x0200023e 4294967295 0    0    1680 1050 demon plasma-desktop
0x02000223 4294967295 0    1015 1680 35   demon plasma-desktop
$ wmctrl -a -i 0x02000235
$ wmctrl -a -i 0x0200023e
$ wmctrl -a -i 0x02000223

I have two monitors, each has resolution of 1680x1050. Those windows listed above are not actual windows as the list is the same no matter how many opened windows I have. Have no idea why…

[faho]

some js test framework

I don't think that'd work properly, as we're bound to the kwin API, which at most allows us to make arbitrary dbus calls - it would be possible, but would (for now - IIRC dbus activation is supposed to be supported in the future) need something outside to launch programs in order to create windows. That plus the fact that we can't receive any flags, so we'd need to start tests on hotkey makes me think going with bash (or python or whatever) just to run some scripts outside is the better idea.

those windows listed above are not actual windows

Well, "plasma-desktop" is the application that (among other things) creates the desktop, which is an actual X11 window (of type DESKTOP). Launch xprop in a terminal and click on your wallpaper.

I'm not sure why there are three, though, if you've only got two monitors.

[piotr-dobrogost]

Does it work for you? How does output of wmctrl -l -G look in your case?
I suspect these windows with the number 35 in the geometry could be taskbars.

[faho]

Yes, it works for me, and yes, that's probably your taskbar (it's probably not shown for me since I autohide mine). Switching desktop to it won't work since these are on all desktops.

For me it looks like this:

0x01e00141 -1 0    0    1366 768  fordprefect plasma-desktop
0x0320001b  7 2    0    1364 768          N/A N/A
0x02600073  0 0    21   1366 747  fordprefect Let's have some tests · Issue #17 · faho/kwin-tiling - Mozilla Firefox
0x03a00024  2 0    21   1366 747  fordprefect Videos – Dolphin
0x02400025 -1 0    0    1366 768  fordprefect Yakuake

Switching to a window ("-a") works, but only via the title and not the number.

[piotr-dobrogost]

Well, the behavior on my system is wired. Having the following windows opened:
Firefox, PyCharm, Krusader, Konsolex2, Yakuake I got

$ ./wmctrl -l -G
0x02000235 4294967295 1680 0    1680 1050 demon plasma-desktop
0x0200023e 4294967295 0    0    1680 1050 demon plasma-desktop
0x02000223 4294967295 0    1015 1680 35   demon plasma-desktop
0x0200022c 4294967295 1680 1015 1680 35   demon plasma-desktop
0x0560001a  0 1682 23   836  988  demon Krusader

So only Krusader is listed. After I had closed PyCharm I get:

$ ./wmctrl -l -G
0x02000235 4294967295 1680 0    1680 1050 demon plasma-desktop
0x0200023e 4294967295 0    0    1680 1050 demon plasma-desktop
0x02000223 4294967295 0    1015 1680 35   demon plasma-desktop
0x0200022c 4294967295 1680 1015 1680 35   demon plasma-desktop

Wired.

[florianjacob]

IMHO it would make more sense to create dummy child windows from the actual test instead of trying to start some other applications. The content of the application shouldn't matter, and special behaviour of some apps like vlc resizing on video playback should be documented in the test and reproducable with only the test itself, not by relying on the actual behaviour of a third-party application.

(for the vlc example, you'd just need to start a Timer on child window creation, and when the timer finishes, you could change the size of the child window to some common movie aspect ratios.)

I looked at the OSD KWin script example, and correct me if I'm wrong, but it seems like KWin scripts are just QtQuick scripts with the addition of the kwin import. As requested by pdobrogost on IRC, I'm appending some example code on how to spawn child windows with QtQuick 2.1 / Qt 5. I don't think it's possible with QtQuick 1 / Qt 4.8, because as far as I know, the Window component didn't exist back then.

TestWindow.qml:

import QtQuick 2.1
import QtQuick.Window 2.1

Window {

    width: 800
    height: 600

        Text {
            anchors.centerIn: parent

            text: "Child Window"
        }
}

main.qml:

import QtQuick 2.1
import QtQuick.Window 2.1
import QtQuick.Controls 1.0

Window {
    id: root

    width: 800
    height: 600
    visible: true

    property variant childWindow;

    Button {
        text: "Open child window"
        anchors.centerIn: parent
        onClicked: {
            var component = Qt.createComponent("TestWindow.qml");
            childWindow = component.createObject(root);
            childWindow.show();
        }
    }
}

(run it with

qml-qt5 main.qml

or similar.)

[faho]

IMHO it would make more sense to create dummy child windows from the actual test instead of trying to start some other applications.

So, this sounds great and can probably be a part of the test suite, but I do believe actual applications should be a part of it, too, especially those that exhibit unusual behavior.

The point of a test suite is to catch regressions for everything you do support, and for this script that includes (within reason - I've hardcoded certain steam windows as they set the wrong window type) all manner of different applications.

I'm also not sure how one can specify minimum/maximum window size in qml.

The more pressing issue right now is that it truly does only work with qt5, which right now doesn't have the kwin modules (and won't have them until kwin is ported to qt5, which may take a while), so right now it's mostly pointless.

It showed me again that I should really be learning qml, though.

[florianjacob]

The more pressing issue right now is that it truly does only work with qt5, which right now doesn't have the kwin modules (and won't have them until kwin is ported to qt5, which may take a while), so right now it's mostly pointless.

Damn. So this approach would need at least an alpha release of kwin for KDE Frameworks 5.

within reason - I've hardcoded certain steam windows as they set the wrong window type

That's awful. xD I guess there'll be a lot more suprises and head -> table moments on the way to stable kwin tiling support..

I'm also not sure how one can specify minimum/maximum window size in qml.
[..]
It showed me again that I should really be learning qml, though. 

Let me help you with that, at least. ;) afaik it's just:

Window {
    maximumHeight: 1200
    maximumWidth: 1920
    minimumHeight: 320
    minimumWidth: 480
    [..]
}

But again, this is QML2. QML1 is barely usable for actual application development on the desktop.