Embedding a top-level window in another application

["Marisha Ray & Neil Jerram" <mpriz dircon co uk>]

Hello!  My name is Neil Jerram.  I've been lurking around on this list for a
few weeks and, I hope, got a clue or two about Gnome.  This post is about a
simple way of embedding top-level windows of one application within the UI
of another application, and whether the proposed implementation has any
merit
alongside the more generic CORBA/COM (Baboon?) model of embedding components
that encapsulate certain functionality.  Please accept my apologies in
advance if this is a completely non-original idea that has already been done
to death by other people!

Two motivations: (1) I've long wanted to be able to get the full
functionality of Emacs text editing in the text editing areas of other
applications.  (2) I recently read Jim Pick's ideas (follow the Ideas link
from the Gnome home page) on an Emacs buffer-style interface to Gnome
applications, where each application would be like a buffer and you could
switch between them like documents in Emacs.  (For Emacs read whatever is
your favorite text editor - this isn't really Emacs-specific.)

It occurred to me that you could implement the display side of these aims
very simply by extending the window manager's idea of what it can do with
new top-level windows:

(1) In addition to its normal window placement options, the window manager
is allowed to reparent top-level windows within "frames" that are advertised
by other applications.

(2) X frame-providing applications use a new WM protocol (to be defined) to
tell the WM that they are advertising a frame.  For GTK applications, the
frame X window and protocol can be encapsulated within a new GtkFrame
widget.

(3) When another application creates a top-level window that it wants to
appear inside a frame, it somehow (to be defined, but perhaps another WM
hint) tells the WM the name/ID of the target frame.  For GTK apps, there
could be a standard "-frame" command line option that is automatically
processed by gtk_init and the GtkWindow widget.

That's all.  With this, you could implement Jim Pick's buffer-style
interface as a tabbed notebook of GtkFrame widgets.  To launch a new
application within the interface, create a new notebook page with a child
GtkFrame widget called MyAppFrame, then fork and exec the application with
an option "-frame MyAppFrame"; then the WM reparents the application's
top-level window within the GtkFrame widget instead of within the normal WM
decoration windows.

Note that this idea doesn't address at all the question of communication
between the host application and the embedded application - in this model
display and communication are seen as orthogonal problems.

Question is, would such a mechanism be useful in the CORBA-enabled world of
Gnome, given that it addresses a CORBA-ish problem in a different way?  What
do you think?

    Neil