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

Koos Vriezen koos.vriezen at xs4all.nl
Mon Oct 13 20:59:59 BST 2003


On Mon, 13 Oct 2003, Leon Bottou wrote:

> On Monday 13 October 2003 12:15 pm, you wrote:
> > > > 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.
> >
> > Yes, that's why the 'if (!d->xplain)' guard. George, what do you think,
> > make embedding with XPLAIN always destroy the embedded window or should
> > we add add a QXEmbed::destroyWithParent(bool) or something member for
> > that?
>
> Destroying the window is not very nice.
> XPLAIN embedded applications, by definition, are not aware they are embedded.
> Granted, this is not true for the java/nsplugin viewers.
>
> Also check the  QXEmbed::setAutoDelete()  undocumented stuff.
> I changes what the QXEmbed destructor does:
>
> - When autoDelete is true, the destructor unmaps the window before reparenting it to the root.
>   So it should not be visible.  No flash.  It also sends a WM_DELETE_WINDOW event to
>   inform the embedded application that it would be safe to quit.
>
> - When autoDelete is false, none of this happen.  The embedding window is destroyed
>   and the X11 save-set thing reparents the embedded window into the root window.

Ah yes, that's even better (like it's already there :)

> Maybe the save set thing should not be enabled when autoDelete is false...
> A brutal destruction of the embedding window would then cause a brutal
> destruction of the embedded window as well.

Makes sense, if one kills konqueror or a crash, seeing all those floating
plugins isn't that nice. However it is a change with current
behaviour...otoh this is an exceptional case..or are there apps freeing
an embed app by killing the host :) out there?

Ok, updated patch attached.

Koos
-------------- next part --------------
Index: qxembed.cpp
===================================================================
RCS file: /home/kde/kdelibs/kdeui/qxembed.cpp,v
retrieving revision 1.44
diff -u -3 -p -r1.44 qxembed.cpp
--- qxembed.cpp	25 Sep 2003 18:16:54 -0000	1.44
+++ qxembed.cpp	13 Oct 2003 19:55:51 -0000
@@ -735,7 +735,8 @@ void QXEmbed::embed(WId w)
     kdDebug() << "************************** Embed "<< QString("0x%1").arg(w, 0, 16) << " into " << QString("0x%1").arg(winId(), 0, 16) << " window=" << QString("0x%1").arg(window, 0, 16) << " **********" << endl; 
     if (!w)
         return;
-    XAddToSaveSet( qt_xdisplay(), w );
+    if (!d->autoDelete)
+        XAddToSaveSet( qt_xdisplay(), w );
     bool has_window =  w == window;
     window = w;
     if ( !has_window ) {
@@ -758,7 +759,8 @@ void QXEmbed::embed(WId w)
             kdDebug() << QString(">>> Loop %1: reparent of 0x%2 into 0x%3 failed").arg(i).arg(w, 0, 16).arg(winId(), 0, 16) << endl;
             USLEEP(1000);
         }
-        QApplication::syncX();
+        //QApplication::syncX();
+        return; // let ReparentNotify finish the job
     }
 
     XResizeWindow(qt_xdisplay(), w, width(), height());
Index: qxembed.h
===================================================================
RCS file: /home/kde/kdelibs/kdeui/qxembed.h,v
retrieving revision 1.21
diff -u -3 -p -r1.21 qxembed.h
--- qxembed.h	21 Aug 2003 09:51:37 -0000	1.21
+++ qxembed.h	13 Oct 2003 19:55:51 -0000
@@ -176,7 +176,14 @@ public:
 
     bool eventFilter( QObject *, QEvent * );
 
+    /**
+     * Default the embedded window is reparented to the root window when
+     * this widget gets deleted.
+     * Calling setAutoDelete(true), unmaps the window and
+     * sends a WM_DELETE_WINDOW event.
+     **/
     void setAutoDelete( bool );
+
     bool autoDelete() const;
 
     bool customWhatsThis() const;


More information about the kfm-devel mailing list