From kde-devel Sun Nov 26 18:37:28 2006 From: Thomas Friedrichsmeier Date: Sun, 26 Nov 2006 18:37:28 +0000 To: kde-devel Subject: Re: Two QXEmbed issues Message-Id: <200611261937.32441.thomas.friedrichsmeier () ruhr-uni-bochum ! de> X-MARC-Message: https://marc.info/?l=kde-devel&m=116456745200547 MIME-Version: 1 Content-Type: multipart/mixed; boundary="--===============1864072608==" --===============1864072608== Content-Type: multipart/signed; boundary="nextPart5973867.XzZ767LQbS"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit --nextPart5973867.XzZ767LQbS Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Hi, CCing this to kwin, with the second issue quoted in full, as this probably= =20 really is a bug in KWin. On Sunday 26 November 2006 14:50, koos vriezen wrote: > 2006/11/25, Thomas Friedrichsmeier > > I don't know about the specs, but it seems to me, the following code: > > " The event member is set either to the reconfigured window or to its > parent, depending on whether StructureNotify or SubstructureNotify > was selected. The window member is set to the window whose size, positio= n, > border, and/or stacking order was changed" > > Since the sendSyntheticConfigureNotifyEvent() sets the > StructureNotifyMask, you're might be right here. Yeah, I did read that paragraph, but by "don't know about the specs", I mea= nt,=20 I do not really understand what it says about this matter. Anyway, I suppos= e,=20 at least in the XPLAIN case, we should probably try to make the embedded=20 window/application feel as much "at home" as possible, and that means passi= ng=20 it the window id it expects and knows about. > > The second issue is much more harmless, but still quite annoying, and > > should affect all applications: Sometimes (roughly on every 10th attempt > > on this machine), embedding would fail. After much trial and error, I > > found out, this is a problem while trying to withdraw the window (in > > QXEmbed::embed()). Currently, we have this code there: > > > > // L1710: Try hard to withdraw the window. > > // This makes sure that the window manager will > > // no longer try to manage this window. > > if ( !wstate_withdrawn(window) ) { > > XWithdrawWindow(qt_xdisplay(), window, qt_xscreen()); > > QApplication::flushX(); > > // L1711: See L1610 > > while (!wstate_withdrawn(window)) > > USLEEP(1000); > > } > > > > The problem is, that wstate_withdrawn () =3D=3D true does not seem to be > > enough. Sometimes the window is marked as withdrawn, but is not yet > > reparented to the root window by the window manager. However, the latter > > seems to be a pre-requisitive to successful embedding. Hence, I changed > > the above code to: > > > > if ( !wstate_withdrawn(window) ) { > > XWithdrawWindow(qt_xdisplay(), window, qt_xscreen()); > > QApplication::flushX(); > > // L1711: See L1610 > > for (int i=3D0; i < 10000; ++i) { > > if (wstate_withdrawn(window)) { > > Window parent =3D 0; > > get_parent(w, &parent); > > if (parent =3D=3D qt_xrootwin()) break; > > else qDebug ("not really withdrawn, yet, in loop > > #%d", i); } > > USLEEP(1000); > > } > > } > > > > in my local copy of QXEmbed. This is *much* more reliable. On most > > attempts to embed, the debug statement will not be hit at all. On every > > 10th attempt, or so, the code will spend a few, up to several hundred > > interations with the window being "withdrawn", but not yet reparented to > > the root window. > > > > Again, my workaround fixes this issue pretty reliably. However, I suspe= ct > > (but do not know), that this might actually be something that also needs > > fixing in the window manager. > > Looks sane to me. But I guess you may contact the kwin guy and/or the > one adding the comments above. I have now tried this under FVWM and TWM. with both, the debug statement is= =20 never hit, so the window is not marked as "withdrawn", until it is reparent= ed=20 to the root window. With KWin I keep seeing the reported behavior roughly 1= =20 in 10 times. So it really does look like a bug in KWin. My workaround works around most of these cases, but sometimes the window st= ill=20 is not reparented to the root window even after the 10000 iterations. > At least check that the embedding of java applet still work relyable > and the nspluginviewer. I don't think this will affect kicker applets, > since that maintainer would have responded by now if so :-) Actually, if it's not too much to ask, could somebody else please test this= =20 (and also commit if ok, I do not even have SVN write access)? I do not have= a=20 KDE 3 source install at all. My testing is done using a modified copy of th= e=20 QXEmbed class, not modified kdeui library. Setting up a real testing=20 environment for these checks would require quite a bit of work, and I would= =20 not get around to doing that anytime soon. Regards Thomas --nextPart5973867.XzZ767LQbS Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (GNU/Linux) iD8DBQBFad7sEKRv+5DVNhgRAnn5AKCvvSIjCuSSUEwLJqiGCf6kplfKVgCgtDZj 0tU7CuyIx2hCYZB1a1rmc7Q= =Uckl -----END PGP SIGNATURE----- --nextPart5973867.XzZ767LQbS-- --===============1864072608== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline >> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe << --===============1864072608==--