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

[Leon Bottou]

On Thursday 30 October 2003 08:23 am, Lubos Lunak wrote:
>  http://bugs.kde.org/show_bug.cgi?id=66062 (in fact four bugs in total,
>  differing in the way it breaks).

Well.  I usually look at the systray when I try stuff in qxembed.
But it seems I should consider more test cases...

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

Sounds excellent to me.

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

Vimpart either uses kvim with XEMBED or gvim with XPLAIN ...

Note that you cannot hide the window on a crash. 
The X11 server does not change the mapping state
of the window when it does the save-set thing.

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

They provide absolutely no support!  
XPLAIN is designed to embed applications that either were not designed for 
embedding, or use a toolkit that was not designed for embedding.
They just believe they are dealing with a slightly odd window manager. 
Sending WM_DELETE_WINDOW makes good sense in this context.

===> We will have to document that setAutoDelete is 
           relevant to the XPLAIN protocol only.

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

There should be support on the client side of qxembed.cpp
for detecting the reparent-to-root and doing something appropriate
like simulating a WM_DELETE_WINDOW message, either via XSendEvent 
or by calling qApp->x11ProcessEvent().

The client application can then redefine closeEvent() to 
reject the close request.  Systray applications should 
do this of course.

Note that this is also true in the current code when autoDelete is true.
The client can survive if it ignores the close request.
But that does not work in the case of a crash. 
does.

I believe this is the spirit: XEMBED does things better 
than XPLAIN because it can rely on client support.

In fact your idea is great.

===> Please let me know when you have the changes in.
           More pairs of eyes can see more stuff...

 -L.