From kfm-devel  Mon Oct 13 16:15:56 2003
From: Koos Vriezen <koos.vriezen () xs4all ! nl>
Date: Mon, 13 Oct 2003 16:15:56 +0000
To: kfm-devel
Subject: Re: [Kwin] Re: Embedding multible java applets and focus problems
X-MARC-Message: https://marc.info/?l=kfm-devel&m=106606189602246

On Mon, 13 Oct 2003, Lubos Lunak wrote:

> On Sunday 12 of October 2003 21:01, Koos Vriezen wrote:
>
>  The only thing I can see about this is that windows are embedded twice. Is
> the problem that embed() can't handle that, even though it checks for 'window
> == w' ?

Still, doing the stuff after the 'if ( !has_window ) {....}' twice is
unnecessary, no?

> [snip]
> > If ReparentNotify is a guaranteed event, I think second patch is
> > preferable (might make QApplication::syncX() not needed any more ... yes
> > work like before).
>
>  ReparentNotify is a guaranteed event, you'll get it after doing
> XReparentWindow() into the embedder. However, given my comment above,
> wouldn't it be simpler to add 'if( w == window ) return;' at the top of
> embed()?

My first thought too, but ReparentNotify does
            window = e->xreparent.window;
            embed( window );
and assuming this code is there for a good reason, I made those two
alternative patches.

> > One additional remark, the XAddToSaveSet call prevents the embedded window
> > to be destroyed when the parent (QXEmbed) gets destroyed. Do we really
> > want that for java/nsplugin? (protecting this call with 'if (!d->xplain)'
> > does seem to get rid of those ugly window flashes after closing konq)
>
>  I don't think you can do this for XEmbed mode, but AFAIK XPLAIN is not a real
> protocol, so it can do whatever it finds appropriate.

Yes, that's why the 'if (!d->xplain)' guard. George, what do you think,
make embedding with XPLAIN always destroy the embedded window or should
we add add a QXEmbed::destroyWithParent(bool) or something member for
that?

 > On Sunday 12 of October 2003 16:20, Koos Vriezen wrote:
> > Another thing is focus on applets (again), a java text box doesn't get any
> > keys delivered when it has the focus. Also, hopefully this is a hint, if
> > you ALT-TAB to another window, so that the java text box hides behind the
> > new active window, the konqueror taskbar item starts to blink a few time.
>
>  http://webcvs.kde.org/cgi-bin/cvsweb.cgi/kdelibs/kdeui/
> qxembed.cpp.diff?r1=1.34&r2=1.35&f=h - this change is the reason for the
> blinking. I'm not very familiar with QXEmbed internals, but I find the log
> message 'Smallish improvement of focus signaling.' both useless and not true.
> Definitely at least setting focus back after geting focus out event is wrong,
> and the other changes are suspicious too. Hard to say for sure without really
> knowing what the code is supposed to do - it seems to be a common KDE
> standard not to bother with explanatory comments, but X11 related code is way
> too complicated to be understood just from reading it.
>
>  However, reverting this change doesn't affect this problem itself, and when
> comparing HEAD and KDE_3_1_BRANCH versions of qxembed.cpp, I don't see
> anything relevant; with KDE-3.1.4 it works for me though.

I must have noticed that earlier if that particular patch was to blame.
I'm guessing of course, but the kwin-iii merge with the 'focus stealing
prevention'. At least that sounds suspicious :) Also this focus problem is
a recent one for sure (haven't seen it before the merge, and I use an
applet with a text box quite often - but don't ask when exactly).

Koos