This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/107983/ |
On January 5th, 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
On January 5th, 2013, 2:38 p.m., Thomas Lübking wrote:
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, 2:38 p.m. Description
Testing
Bugs:
179042
Diffs
|