在拖动/调整窗口大小时调用窗口上的isActive（）时，false返回。 （X11，Qt 5.4.0）

Question

I'm using Qt 5.4.0 on linux (X11) and I need to determine, if my window is active. So, I wrote example code, given below. If that code compiled on windows, it logs "false" in console only when window isn't really active. But on linux (X11), it also logs "false" when I start to drag or resize window. Why this happen and how to fix that on linux? I want to know, when my window is really inactive, and when it's active, but being dragged/resized.

code snippet (C++):

void MainWindow::changeEvent(QEvent *e) {
    if (e->type() == QEvent::ActivationChange) {
        if (this->isActiveWindow()) {
            std::cout << "True" << std::endl;
        } else {
            std::cout << "False" << std::endl;
        }
    }
}

same code, on PyQt5:

import sys
from PyQt5.QtCore import Qt, QEvent
from PyQt5.QtWidgets import QWidget, QApplication


class TransparentWidget(QWidget):
    def __init__(self):
        super(TransparentWidget, self).__init__()

    def changeEvent(self, e):
        if e.type() == QEvent.ActivationChange:
            print(self.isActiveWindow())

if __name__ == '__main__':
    app = QApplication(sys.argv)
    transparent_widget = TransparentWidget()
    transparent_widget.show()
    app.exec_()

Answer 1

It probably registers 'false' because on X the window you see is actually two windows: the window where you paint your contents and a slighly larger window, which is the parent window of yours and contains the border.

The reason is that X11 doesn't have a concept of a "decorated border" with close/max/min buttons, titlebar, nice gradient colors, rounded borders etc. (native X11 windows can have a border, but only as a solid color or texture). Those controls are provided by your window manager. What happens is that if you create a window, the window manager creates an extra X11 window which is slightly larger than yours and places your window as a child on this new window. From then on, the two windows are intimately linked: resizing your window will resize the parent window and vice versa.

This is all handled by the window manager. For example, if you want to resize the window and click on the border, the click goes not to your window but to the window manager, which then determines where the click was and decides what to do with it. So at that moment your own window is not active anymore, which explains why isActiveWindow() returns false.

With Microsoft Windows the border is an integral part of the window itself, so that's why it remains 'active'.

Anyway, to find out if your window is 'active' or not, you should use the QFocusEvent. By looking at the gotFocus() and lostFocus() values you should be able to track when you window is active or not.

Answer 2

The active window is the window that currently accepts the keyboard input focus, and therefore is also the window to which keyboard events are sent.

During a resize/move operation, the active window does not register keyboard events (whether they are actually sent or not). Given this, it is arguable whether the window should still be regarded as active during such operations.

Qt4 and Qt5 differ in how they deal with this. Qt4 does not report window activation changes (or focus changes) during a resize/move on any platform (I only actually tested on X11 and Windows, though). The same is also true for Qt5 - except when it comes to X11.

On X11, Qt5 reports a window activation change (and a focus change) at the start and end of all resize/move operations. That is, isActiveWindow() returns False when the operation starts and True when it ends (and the corresponding FocusIn/FocusOut events are also sent, as well as WindowActivate/WindowDeactivate events, and so forth).

It could be argued that the Qt5 behaviour on X11 is the only one that is accurate. However, it is inconsistent with the other platforms Qt5 supports, and so from a developer's point of view it must be considered buggy (or at the very least, inconvenient).

Although the behaviour on Qt4 is arguably less acccurate, it is at least consistent across all the platforms it supports (ie it is exactly what a developer would expect from a cross-platform toolkit).

Unfortunately, the resize/move events only begin after the window activation changes, so there does not seem to be any obvious way to filter out the unwanted activation events in Qt5.