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

List:       kde-devel
Subject:    Re: Two QXEmbed issues
From:       "koos vriezen" <koos.vriezen () gmail ! com>
Date:       2006-11-26 13:50:12
Message-ID: d4e708d60611260550p3b96e554v5c5add3295098b21 () mail ! gmail ! com
[Download RAW message or body]

Hi,

2006/11/25, Thomas Friedrichsmeier <thomas.friedrichsmeier@ruhr-uni-bochum.de>:
[..]
> 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;
>

There are man pages about this, maybe you have to install some extra
packages, but I can do
  man XConfigureEvent
and see among other stuff:

"     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, position,
       border, and/or stacking order was changed"

Since the sendSyntheticConfigureNotifyEvent() sets the
StructureNotifyMask, you're might be right here.

> 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.

Looks sane to me. But I guess you may contact the kwin guy and/or the
one adding the comments above.
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 :-)

Koos

> Does my analysis of these two issues seem half correct?
>
> Regards
> Thomas
>
>
>
> >> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
>
>
>
>
 
>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
[prev in list] [next in list] [prev in thread] [next in thread]