This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/107983/

Review request for kdelibs, kwin, Plasma, Aaron J. Seigo, Marco Martin, Martin Gräßlin, and Fredrik Höglund.
By Thomas Lübking.

Updated Jan. 5, 2013, 5:08 p.m.

Changes

Modified patch to check the root event but let it unconditionally pass to Qt (to preserve other SelectionOwner notifications)
This does also stop additional notifications on winId(), so my guess is that passing the root event simply causes something (Qt?!) to "steal" it from XFixes.

Remaining question is, whether the explicit XFixesSelectSelectionInput call is still required (or we do receive them anyway due to eg. Qt's cnp implementation - from the simple testcase the answer is "yes")

Summary (updated)

Fix KWindowSystem::compositingChanged signal

Description

It works fine here (tested so far KWindowSystem signal, KSelectionWatcher only with kwin) with kwin (shift+alt+f12), xcompmgr, compiz & "metacity -c" and e17.
Didn't try xfce nor mutter.

Technically:
I do not at all understand why KWindowSystem is *not* watching the root window - KSelectionOwner for one is sending events to the root and this also seems the case for all other WMs (at least everything now starts to cause the signal to be emitted)

The KSelectionWatcher failure seems to be kwin specific (wrote me a cleaner testcase), there'll be some X11 event processing on top that eats away the client messages.
So this one can be scratched from the patch, the KWindowSystem issue remains.

Testing

see summary
Bugs: 179042

Diffs (updated)

  • kdeui/windowmanagement/kwindowsystem_x11.cpp (f9b3cc1)

View Diff