OD Container Interface
Volume Number: 12
Issue Number: 5
Column Tag: Opendoc
Rethinking the Interface 
Getting the look and feel of a container application
By Tantek Çelik and David Curbow
Many OpenDoc parts are being created, and much has been written about how to do so;
but very little has appeared about how to “host” OpenDoc parts - that is, how to be a
container application. Indeed, as of this writing, only five container applications are
even known to exist. Issues both of Human Interface and of programming technique are
at last being worked out; and here, two leading authorities in the field expound for the
first time what an existing application needs to do in order to become a container
application.
Adding OpenDoc support to your application requires rethinking your application’s
human interface design a bit. In many ways, adding OpenDoc embedding is no more
intrusive than adding QuickTime movie embedding. However, because of OpenDoc’s
generality, it relies on sharing various application-owned structures. In short, these
are: document files, menus, windows and events, clipboard, drag and drop, and, of
course, the application heap. Most of these affect the human interface of your
application.
OpenDoc part editors assume there is a document shell which provides certain
functions, such as default menus and a document model. Parts also assume that either
they are the root part of a document or they are embedded into a containing part. In the
latter case, they will interact with this containing part in certain ways, for example
through frame negotiation. It is also important that the containing part provide access
to the Part Info dialog for all the parts it contains. We did our best to strike a good
balance between ease of development for the part editor, on the one hand, and minimal
change for the container application, on the other. This article both delineates the
practical minimum of what an application must do to adapt its human interface to