Review Request: Fix KSelectionWatcher / KWindowSystem::compositingChanged signal

[Thomas Lübking]

> On Jan. 5, 2013, 3:13 p.m., Fredrik Höglund wrote:
> > Because the XFixesSelectSelectionInput() call specifies that the event should be delivered to winId(). KSelectionOwner does not send XFixes events; they are generated by the X server.
> >

Ok, problem is: whether by compiz, e17, kwin, xcompmgr - the event occurs on the root but not on winId() - even for the simplistic testcase (which also works on QApplication but for the selectionwatcher)

I tried adding some junk into XFixesSelectSelectionInput and get a request error (as expected)

X Error: BadWindow (invalid Window parameter) 3
  Extension:    138 (Uknown extension)
  Minor opcode: 2 (Unknown request)
  Resource id:  0x3039

yet KWindowSystem fires on compositing toggle.

Then i removed XFixesSelectSelectionInput - and still (patched to check against root) KWindowSystem fires on compositing toggle.


Now it gets interesting (I removed the KSelectionWatcher bits for the last tests):
-----------------------------------------------------------------------------------------
If i keep XFixesSelectSelectionInput AND the check against the root window i get after the event on root TWO additional events on the winId()
If i remove either, i get none of them (but still one on the root which however is ignored)

So ulitmately i just ate away (return true) selectionnotify events on the root window and in return got ONE additional event on the winId which then fired the signal - what is all less then ideal, since (just as the present patch btw.) we also eat away "regular" selectionowner events.


- Thomas


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


On Jan. 5, 2013, 2:38 p.m., Thomas Lübking wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> http://git.reviewboard.kde.org/r/107983/
> -----------------------------------------------------------
> 
> (Updated Jan. 5, 2013, 2:38 p.m.)
> 
> 
> Review request for kdelibs, kwin, Plasma, Aaron J. Seigo, Marco Martin, Martin Gräßlin, and Fredrik Höglund.
> 
> 
> 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.
> 
> 
> This addresses bug 179042.
>     http://bugs.kde.org/show_bug.cgi?id=179042
> 
> 
> Diffs
> -----
> 
>   kdeui/windowmanagement/kwindowsystem_x11.cpp f9b3cc1 
> 
> Diff: http://git.reviewboard.kde.org/r/107983/diff/
> 
> 
> Testing
> -------
> 
> see summary
> 
> 
> Thanks,
> 
> Thomas Lübking
> 
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20130105/d3a89827/attachment.htm>