Review Request: Fix KWindowSystem::compositingChanged signal

Thomas Lübking thomas.luebking at
Sat Jan 5 17:08:13 GMT 2013

This is an automatically generated e-mail. To reply, visit:

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

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


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


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.

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.

This addresses bug 179042.

Diffs (updated)

  kdeui/windowmanagement/kwindowsystem_x11.cpp f9b3cc1 



see summary


Thomas Lübking

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the kde-core-devel mailing list