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

List:       kde-devel
Subject:    Re: Two QXEmbed issues
From:       Lubos Lunak <l.lunak () suse ! cz>
Date:       2006-11-29 13:31:57
Message-ID: 200611291431.57951.l.lunak () suse ! cz
[Download RAW message or body]

On Saturday 25 November 2006 19:57, Thomas Friedrichsmeier wrote:
> Hi!
>
> This is about KDE 3.5, but probably applies to KDE 4, too.

 QXEmbed is dropped for KDE4 in favour of Qt4 classes.

> 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();
...
> 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().

 Yes. Since the event is sent with StructureNotifyMask, the first one looks 
wrong.

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

 Setting to withdrawn state used to be done very late in the code but I moved 
it because of #103301 where it caused problems because of changes happening 
to the window without first being marked as withdrawn. As moving things 
around should leave a problem one or another way it'll need to grab X during 
the window withdrawal.

> Does my analysis of these two issues seem half correct?

 No. It seems to be two halves correct. I'll do the necessary commits.

-- 
Lubos Lunak
KDE developer
--------------------------------------------------------------
SUSE LINUX, s.r.o.   e-mail: l.lunak@suse.cz , l.lunak@kde.org
Lihovarska 1060/12   tel: +420 284 028 972
190 00 Prague 9      fax: +420 284 028 951
Czech Republic       http//www.suse.cz
 
>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
[prev in list] [next in list] [prev in thread] [next in thread]