[Kwin] Re: Embedding multible java applets and focus problems

[Lubos Lunak]

On Sunday 12 of October 2003 21:01, Koos Vriezen wrote:
> On Sun, 12 Oct 2003, Koos Vriezen wrote:
> > hi,
> >
> > HTML pages with multible applets have sometimes trouble embedding some of
> > those. I sometimes see this as debug output:
> >
> > kjas: swallowing our window: KJAS Applet - Ticket number 24, window id =
> > 31457789 konqueror: ************************** Embed 0x1e001fd into
> > 0x1803cb8 window=0x0 ********** konqueror: >>> before reparent:
> > parent=0x41
> > konqueror: >>> Loop 0: reparent of 0x1e001fd into 0x1803cb8 successful
> > kjas: swallowing our window: KJAS Applet - Ticket number 25, window id =
> > 31457795 konqueror: ************************** Embed 0x1e00203 into
> > 0x1803ccd window=0x0 ********** konqueror: >>> before reparent:
> > parent=0x41
> > konqueror: >>> Loop 0: reparent of 0x1e00203 into 0x1803ccd successful
> > konqueror: ************************** Embed 0x1e001fd into 0x1803cb8
> > window=0x1e001fd ********** konqueror: ************************** Embed
> > 0x1e00203 into 0x1803ccd window=0x1e00203 **********

 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' ?

[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()?

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

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.

-- 
Lubos Lunak
KDE developer
---------------------------------------------------------------------
SuSE CR, s.r.o.  e-mail: l.lunak at suse.cz , l.lunak at kde.org
Drahobejlova 27  tel: +420 2 9654 2373
190 00 Praha 9   fax: +420 2 9654 2374
Czech Republic   http://www.suse.cz/