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

List:       kwin
Subject:    Re: Two QXEmbed issues
From:       Thomas Friedrichsmeier <thomas.friedrichsmeier () ruhr-uni-bochum ! de>
Date:       2006-11-26 18:37:28
Message-ID: 200611261937.32441.thomas.friedrichsmeier () ruhr-uni-bochum ! de
[Download RAW message or body]

[Attachment #2 (multipart/signed)]


Hi,

CCing this to kwin, with the second issue quoted in full, as this probably 
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, position,
> 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 meant, 
I do not really understand what it says about this matter. Anyway, I suppose, 
at least in the XPLAIN case, we should probably try to make the embedded 
window/application feel as much "at home" as possible, and that means passing 
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 () == 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.

I have now tried this under FVWM and TWM. with both, the debug statement is 
never hit, so the window is not marked as "withdrawn", until it is reparented 
to the root window. With KWin I keep seeing the reported behavior roughly 1 
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 still 
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 
(and also commit if ok, I do not even have SVN write access)? I do not have a 
KDE 3 source install at all. My testing is done using a modified copy of the 
QXEmbed class, not modified kdeui library. Setting up a real testing 
environment for these checks would require quite a bit of work, and I would 
not get around to doing that anytime soon.

Regards
Thomas

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

_______________________________________________
Kwin mailing list
Kwin@kde.org
https://mail.kde.org/mailman/listinfo/kwin


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