--===============0089319203455108396== Content-Type: multipart/alternative; boundary="===============0102138236002274129==" --===============0102138236002274129== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable > On Jan. 5, 2013, 3:13 p.m., Fredrik H=C3=B6glund 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 o= n the root but not on winId() - even for the simplistic testcase (which als= o 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 aga= inst 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 how= ever is ignored) So ulitmately i just ate away (return true) selectionnotify events on the r= oot window and in return got ONE additional event on the winId which then f= ired the signal - what is all less then ideal, since (just as the present p= atch 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=C3=BCbking 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, M= artin Gr=C3=A4=C3=9Flin, and Fredrik H=C3=B6glund. > = > = > 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 w= indow - 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 clean= er testcase), there'll be some X11 event processing on top that eats away t= he client messages. > So this one can be scratched from the patch, the KWindowSystem issue rema= ins. > = > = > This addresses bug 179042. > http://bugs.kde.org/show_bug.cgi?id=3D179042 > = > = > Diffs > ----- > = > kdeui/windowmanagement/kwindowsystem_x11.cpp f9b3cc1 = > = > Diff: http://git.reviewboard.kde.org/r/107983/diff/ > = > = > Testing > ------- > = > see summary > = > = > Thanks, > = > Thomas L=C3=BCbking > = > --===============0102138236002274129== Content-Type: text/html; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable
This is an automatically generated e-mail. To reply, visit: http://git.revie= wboard.kde.org/r/107983/

On January 5th, 2013, 3:13 p.m., Fredrik H= =C3=B6glund wrote:

Because t=
he XFixesSelectSelectionInput() call specifies that the event should be del=
ivered to winId(). KSelectionOwner does not send XFixes events; they are ge=
nerated 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 aga=
inst 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 how=
ever is ignored)

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

- Thomas


On January 5th, 2013, 2:38 p.m., Thomas L=C3=BCbking wrote:

Review request for kdelibs, kwin, Plasma, Aaron J. Seigo, Marco Martin= , Martin Gr=C3=A4=C3=9Flin, and Fredrik H=C3=B6glund.
By Thomas L=C3=BCbking.

Updated Jan. 5, 2013, 2:38 p.m.

Descripti= on

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

Technically:
I do not at all understand why KWindowSystem is *not* watching the root win=
dow - KSelectionOwner for one is sending events to the root and this also s=
eems the case for all other WMs (at least everything now starts to cause th=
e 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 remain=
s.

Testing <= /h1>
see summary
Bugs: 179042

Diffs=

  • kdeui/windowmanagement/kwindowsystem_x11.cpp (f9b3cc1)

View Diff

--===============0102138236002274129==-- --===============0089319203455108396== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel --===============0089319203455108396==--