From kde-devel  Sat Nov 25 18:57:28 2006
From: Thomas Friedrichsmeier <thomas.friedrichsmeier () ruhr-uni-bochum ! de>
Date: Sat, 25 Nov 2006 18:57:28 +0000
To: kde-devel
Subject: Two QXEmbed issues
Message-Id: <200611251957.32122.thomas.friedrichsmeier () ruhr-uni-bochum ! de>
X-MARC-Message: https://marc.info/?l=kde-devel&m=116448102901184
MIME-Version: 1
Content-Type: multipart/mixed; boundary="--===============0214857813=="

--===============0214857813==
Content-Type: multipart/signed;
  boundary="nextPart41591913.CIrMpd0jz7";
  protocol="application/pgp-signature";
  micalg=pgp-sha1
Content-Transfer-Encoding: 7bit

--nextPart41591913.CIrMpd0jz7
Content-Type: text/plain;
  charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

Hi!

This is about KDE 3.5, but probably applies to KDE 4, too.

I'm trying to use QXEmbed in rkward (http://rkward.sf.net) to embed X11=20
windows from R (http://www.r-project.org). The first - and most important -=
=20
issue, I ran into is this:

In QXEmbed::sendSyntheticConfigureNotifyEvent(), we have:

        c.event =3D window;
        c.window =3D winId();

note, how we're passing the embedding window's ID to the embedded window in=
=20
the synthetic configure event. Most applications probably do not care about=
=20
the window parameter of the event, but R happens to do. It has code like=20
this:

    if (event.type =3D=3D ConfigureNotify) {
	XFindContext(display, event.xconfigure.window,
		     devPtrContext, &temp);
	// now try to work with temp -> crash
	// ...
    }

This is due to R being ignorant about embedding. It assumes (rightfully?) t=
hat=20
all windows it receives events about are it's own, with window ids it knows=
=20
about, and has saved a context for. This assumption is being violated by th=
e=20
synthetic configure events sent by QXEmbed, causing R to crash when its=20
windows are embedded.

I don't know about the specs, but it seems to me, the following code:

        c.event =3D window;
        c.window =3D window;

would make much more sense in QXEmbed::sendSyntheticConfigureNotifyEvent().=
 It=20
does fixes the crash in R, I'm seeing.

The second issue is much more harmless, but still quite annoying, and shoul=
d=20
affect all applications: Sometimes (roughly on every 10th attempt on this=20
machine), embedding would fail. After much trial and error, I found out, th=
is=20
is a problem while trying to withdraw the window (in QXEmbed::embed()).=20
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 en=
ough.=20
Sometimes the window is marked as withdrawn, but is not yet reparented to t=
he=20
root window by the window manager. However, the latter seems to be a=20
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=20
embed, the debug statement will not be hit at all. On every 10th attempt, o=
r=20
so, the code will spend a few, up to several hundred interations with the=20
window being "withdrawn", but not yet reparented to the root window.

Again, my workaround fixes this issue pretty reliably. However, I suspect (=
but=20
do not know), that this might actually be something that also needs fixing =
in=20
the window manager.

Does my analysis of these two issues seem half correct?

Regards
Thomas

--nextPart41591913.CIrMpd0jz7
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (GNU/Linux)

iD8DBQBFaJIbEKRv+5DVNhgRAuYTAJ0WaXzjUyJHvwSaUWRojr/ldNyvYACdFMdm
6nQeNPei6O+2cn7cWGo6Ch4=
=BQDJ
-----END PGP SIGNATURE-----

--nextPart41591913.CIrMpd0jz7--

--===============0214857813==
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 <<

--===============0214857813==--