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

List:       kfm-devel
Subject:    Re: [Kwin] Re: Embedding multible java applets and focus problems
From:       Lubos Lunak <l.lunak () suse ! cz>
Date:       2003-10-30 13:23:11
[Download RAW message or body]

On Thursday 30 of October 2003 07:19, Leon Bottou wrote:
> On Wednesday 29 October 2003 12:26, Lubos Lunak wrote:
> > On Tuesday 14 of October 2003 00:42, Leon Bottou wrote:
> > > On Monday 13 October 2003 04:35 pm, Leon Bottou wrote:
> > > > As it is now, the XAddToSaveSet is only performed
> > > > when the embedding is achieved by calling embed().
> > > > Not when using QXEmbed::embedClientIntoWindow().
> > > > Nobody noticed...
> >
> >  Well, well ... it may work with Java and so on, but not only them use
> > QXEmbed. The reason why systray doesn't work anymore are these recent
> > QXEmbed changes.
>
> I am running it daily and did not notice anything special in the system
> tray.

 http://bugs.kde.org/show_bug.cgi?id=66062 (in fact four bugs in total, 
differing in the way it breaks).

> However, I did not experience a panel crash or restart.
> I understand that a panel crash or restart can indeed cause problems:
> The systray applications terminate. Restarting the panel does not restart
> them. Logging out might save a session without these applications. Etc.

 No, the systray apps don't terminate on kicker crash/restart. The problem is 
that in that case the embedded window is destroyed. That's why http://
lists.kde.org/?l=kde-core-devel&m=106684827930992&w=2 has the X errors related 
to drawing.

>
> > The first reason is backwards compatibility.
>
> The problem with qxembed is that what is backward compatible
> for one application is a bug for another.  The core problem is to
> define what qxembed should do when the embedding applications terminates.
> Not only was this behavior poorly specified, but also was it inconsistent:
> using embed() or embedClientIntoWindow() gave different behaviors.
>
> Let's first see what can be implemented:
>
> When the embedding application crashes,
>  1- we can let the embedded application crash, or
>  2- we can make it survive the crash using XAddToSaveSet.
>      the embedded application then gets reparented and mapped
>      into the root window.
>
> When the embedding application terminates,
>  a- we can let the embedded application crash,
>  b- we can reparent it into the root window and map it,
>  c- we can reparent it into the root window, map it, and send a WM_DELETE
> message, d- we can reparent it into the root window and hide it,
>  e- we can reparent it into the root window, hide it, and send a WM_DELETE
> message.
>
> This is pretty trivial to implement, but this also makes a lot of
> options...
>
> The current QXEmbed only provides 1-a and 1-e.
> By explicitly using XAddToSaveSet one can do 2-b or 2-e instead.
> For reference, the old QXEmbed was doing 2-b or 2-e when
> using embed() and 1-b or 1-e when using embedClientIntoWindow().
>
> - The system tray needs 2-b (or maybe 2-d).

 There's actually no big difference between 2-b and 2-d. Even with 2-d, the 
case of being remapped to root and being visible has to be handled, for the 
case of a crash. Also note that with the current QXEmbed, we don't have b. In 
QXEmbed dtor, the reparenting back has to be done even if !autoDelete(), 
otherwise the window will be deleted by X11 because of being inferior of 
QXEmbed's window. XAddToSaveSet() only affects the case when the clients 
disconnects/crashes.

> - The java embedding needs 1-a (or maybe 1-e).
> - The nsplugin embedding needs 1-e.
> - The control panel (administrator mode) needs 1-c or 1-e.
> - The vimpart embedding should work with either 1-c or 1-e.
[snip]
> > Therefore I propose that XAddToSaveSet() goes back in
> > (and in the right place this time).
>
> Out of the five embedding cases I know (systray, java, nsplugin,
> control panel, vimpart), that would fix one and break four.
> Maybe I am forgetting some other cases...

 I think I disagree about the cases where XEMBED is used (XPLAIN is our hack, 
so it can do whatever we see fit). The XEMBED specification doesn't talk 
about WM_DELETE_WINDOW at all. If you have a look at the bottom of http://
pdx.freedesktop.org/Standards/xembed-spec/0.5/ar01s04.html , the only way how 
the embedder terminates the embedding is by remapping to root and that's 
about it. The embedded app has to check itself for this case, and, as it 
already has to support XEMBED anyway, having this is just having part of the 
XEMBED spec. Quiting the embedded app on reparent back to root will have the 
nice effect of always exiting cleanly, even in the case of a crash.

 That leaves us with only one option for XEMBED, 2-d (I think that's better 
than 2-b, the spec doesn't seem to specify that it has to be visible after 
reparenting to root). This will take care of all cases. Systray will work, 
and won't quit, KControl and KVim (they're both XEMBED, aren't they) will 
tell QXEmbed they want to quit after the embedding ends, and it's done.

 The XPLAIN case is up to you, I don't know how exactly the embedded apps are 
written for that case.

 Comments? I'll do the necessary changes for XEMBED if we agree on doing it 
that way, I have part of it done already anyway for systray.


[kwin<->qxembed races]
 I've already committed a workaround for the second problem, but systray still 
needs the XAddToSaveSet() changes to be handled.

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

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