From kwin Sat Jan 05 17:08:13 2013 From: =?utf-8?q?Thomas_L=C3=BCbking?= Date: Sat, 05 Jan 2013 17:08:13 +0000 To: kwin Subject: Re: Review Request: Fix KWindowSystem::compositingChanged signal Message-Id: <20130105170813.12620.12946 () vidsolbach ! de> X-MARC-Message: https://marc.info/?l=kwin&m=135740575108262 MIME-Version: 1 Content-Type: multipart/mixed; boundary="--===============7991804908634907923==" --===============7991804908634907923== Content-Type: multipart/alternative; boundary="===============2253893132523716196==" --===============2253893132523716196== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable ----------------------------------------------------------- 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, Mar= tin Gr=C3=A4=C3=9Flin, and Fredrik H=C3=B6glund. Changes ------- Modified patch to check the root event but let it unconditionally pass to Q= t (to preserve other SelectionOwner notifications) This does also stop additional notifications on winId(), so my guess is tha= t 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 implem= entation - from the simple testcase the answer is "yes") Summary (updated) ----------------- Fix KWindowSystem::compositingChanged signal Description ------- It works fine here (tested so far KWindowSystem signal, KSelectionWatcher o= nly 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 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. This addresses bug 179042. http://bugs.kde.org/show_bug.cgi?id=3D179042 Diffs (updated) ----- kdeui/windowmanagement/kwindowsystem_x11.cpp f9b3cc1 = Diff: http://git.reviewboard.kde.org/r/107983/diff/ Testing ------- see summary Thanks, Thomas L=C3=BCbking --===============2253893132523716196== 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/

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, 5:08 p.m.

Changes 
Modified patch to check the root event but let it unconditio=
nally pass to Qt (to preserve other SelectionOwner notifications)
This does also stop additional notifications on winId(), so my guess is tha=
t 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 im=
plementation - from the simple testcase the answer is "yes")

Summary (= updated)

Fix KWindowSystem::compositingChanged signal

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= (updated)

  • kdeui/windowmanagement/kwindowsystem_x11.cpp (f9b3cc1)

View Diff
--===============2253893132523716196==-- --===============7991804908634907923== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ kwin mailing list kwin@kde.org https://mail.kde.org/mailman/listinfo/kwin --===============7991804908634907923==--