From kwin Mon Oct 13 13:55:26 2003 From: Lubos Lunak Date: Mon, 13 Oct 2003 13:55:26 +0000 To: kwin Subject: Re: [Kwin] Re: Embedding multible java applets and focus problems X-MARC-Message: https://marc.info/?l=kwin&m=106605374224508 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@suse.cz , l.lunak@kde.org Drahobejlova 27 tel: +420 2 9654 2373 190 00 Praha 9 fax: +420 2 9654 2374 Czech Republic http://www.suse.cz/ _______________________________________________ Kwin mailing list Kwin@mail.kde.org http://mail.kde.org/mailman/listinfo/kwin