> 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. > > > > Thomas Lübking wrote: > 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. > > Fredrik Höglund wrote: > This happens because Qt compresses XFixesSelectionNotifyEvents by > deleting all events in the queue that refer to same selection except the last > one. It does this without taking the destination window or the subtype into > account, so it will randomly swallow either its own event or the event > selected by KWindowSystem. The event you see delivered to the root window is > the event selected by Qt for QX11Info::isCompositingManagerRunning(). > > > Thomas Lübking wrote: > Ok, i can see the bug in qt_xfixes_scanner. > > -> Question is, whether we should - given the Qt4 lifecycle - just work > around that for KDE4 by either relying on the Qt selection and just scanning > for the root or not relying on the Qt selection and pass on root events while > swallow winId() ones but hook on both to re-evaluate the compositing state. > > Is there any remote chance there'll be another Qt4 minor release?
> Is there any remote chance there'll be another Qt4 minor release? Ok, at least there's quite some action on the git tree and the term 4.8.5 ;-) - Thomas ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/107983/#review24751 ----------------------------------------------------------- On Jan. 5, 2013, 5:08 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, 5:08 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 > >
_______________________________________________ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
