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

[Lubos Lunak]

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.

>
> After playing with it, I believe that QXEmbed should never perform
> XAddToSaveSet.

 The first one is removing of that XAddToSaveSet(). If you restart kicker, the 
systrayed window is destroyed, and you get what described here http://
lists.kde.org/?l=kde-core-devel&m=106684827930992&w=2 . And I think you're 
wrong about this. The first reason is backwards compatibility, but not only 
that.

>
> If the embedding application terminates on xkill, we never want the
> embedded application to resist the change and stick around.

 You think only in terms of Java and applets. There may be cases where you 
want to embed some window from other process. Systray is one example.

>  In fact, if we
> really want this, it is quite easy for the embedding application to call
> XAddToSaveSet just after calling QXEmbed::embed().

 And what if the embedding is done the other way (which, as you noted above, 
by mistake didn't do XAddToSaveSet() at all until the change, but that's not 
really relevant)?

>
> If the embedding application exits cleanly, we want the embedded
> application to exit cleanly too. This is already the case because
> autoDelete() takes care of this.
>
> The only case when it does not happen is when we forget to properly
> destroy the hierarchy of Qt widgets.   This can happen when the
> toplevel widget is allocated with new and someone calls qApp->quit()
> and exits without performing a delete.  This is in fact the only case where
> the XAddToChangeSet makes a difference.  Maybe this is what is happening
> with the java viewer.

 You forgot one special case, called crash. If Kicker crashes, the trayed 
icons should survive (and let me repeat 'backwards compatiblity' here again).

 Therefore I propose that XAddToSaveSet() goes back in (and in the right place 
this time). I'm just not sure how to differentiate the various cases, because 
I'm not entirely convinced that this corresponds exactly to autoDelete(). 
Could there be a case when there should be no WM_DELETE_WINDOW but there 
should be XAddToSaveSet() ?

 Maybe it would be better to extend setAutoDelete() to have more states, and 
the old bool one would be marked deprecated. As that one wasn't documented 
anyway, I don't think there would be a problem, as long as they do reasonably 
similar things as they used to (which is not the case with the present 
state).

 What exactly is the state with Java applets? Given the description above, I 
see there shouldn't be XAddToSaveSet(), but how about WM_DELETE_WINDOW? 
Systray most probably should have XAddToSaveSet() but no WM_DELETE_WINDOW. 
Would there be more cases?


 Problem with systray #2 - not really QXEmbed's fault. The XAddToSaveSet() 
above is only for cases when Kicker restarts or crashes. The rest of the 
problem is by removing some of the embedding code from QXEmbed::embed(), and 
doing it after getting ReparentNotify. That was a good thing, the real 
problem is that KDE's mechanism for the sytray icon is just one big race 
condition, and worked until recently only because QXEmbed tried harder than 
KWin to get the window, and was lucky. I think the right solution would be 
using the XDG systray spec, but given the close 3.2 release, I'm not sure if 
this option is possible.

 Anyway, this second problem is rather a KWin problem (i.e. my problem, I 
guess). I'll have a closer look at implementing the XDG spec in KSystemTray, 
otherwise I'll try to add some terrible hack. I'd rather not to revert that 
related QXEmbed change, as it was right, and IIRC it fixed some other 
problem.

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