[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-devel
Subject:    Two QXEmbed issues
From:       Thomas Friedrichsmeier <thomas.friedrichsmeier () ruhr-uni-bochum ! de>
Date:       2006-11-25 18:57:28
Message-ID: 200611251957.32122.thomas.friedrichsmeier () ruhr-uni-bochum ! de
[Download RAW message or body]

[Attachment #2 (multipart/signed)]


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 
windows from R (http://www.r-project.org). The first - and most important - 
issue, I ran into is this:

In QXEmbed::sendSyntheticConfigureNotifyEvent(), we have:

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

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

    if (event.type == 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?) that 
all windows it receives events about are it's own, with window ids it knows 
about, and has saved a context for. This assumption is being violated by the 
synthetic configure events sent by QXEmbed, causing R to crash when its 
windows are embedded.

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

        c.event = window;
        c.window = window;

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

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 () == 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=0; i < 10000; ++i) {
                if (wstate_withdrawn(window)) {
                    Window parent = 0;
                    get_parent(w, &parent);
                    if (parent == 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 suspect (but 
do not know), that this might actually be something that also needs fixing in 
the window manager.

Does my analysis of these two issues seem half correct?

Regards
Thomas

[Attachment #5 (application/pgp-signature)]

>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<


[prev in list] [next in list] [prev in thread] [next in thread]