Qt XEMBED [was: Re: thoughts on the systray]

[Leon Bottou]

In the past few years I did a lot of work to make the QXEmbed class more robust.
Including documenting everything I could (because this is a hopelessly complicated code).

QXEmbed serves three purposes: 
   1- swallowing things that obey the XEMBED protocol (systray icons, kcm modules)
   2- making *all* toplevel QWidgets embeddable with the XEMBED protocol.
   3- swallowing things that do not obey the XEMBED protocol (nsplugins, javaapplets, gvim)

The 1st point is well known.

The 2nd point means that QXEmbed attempts to make any Qt application embeddable.
With the Qt XEMBED classes, you can only do this with a QtXEmbedClient.
Instead QXEmbed creates a complex network of event handlers that change
the toplevel QWidget to make them understand the XEMBED protocol.
Toplevel QWidgets already understand all the window management business. 
Adding XEMBED is a rather small change.

Alas this is very difficult to achieve with just event handlers.
This is why QXEmbed is hopelessly flaky.

I believe that the right way to go (tm) would be to change 
the Qt QWidget X11 implementation to natively understand 
the XEMBED protocol when:
(a) this is a toplevel QWidget,
(b) it has received an XEMBED_EMBEDDED_NOTIFY event,
(c) it has not been reparented away since that initial XEMBED message.

Then, any Qt application could be embedded by either a QXEmbed widget,
a QtXEmbedContainer or a GtkSocket for that matter.

Finally the 3rd point is very important as well because lots of code rely on it.  
Maybe in the future the nsplugins and the javaapplet will obey the XEMBED protocol.
At the moment, they do not.

- Leon Bottou