4. Extending the VendorShell

The objects of the XmVendorShellExtObject class serve for two purposes. First, they provide storage for resources that are new with M*TIF's particular VendorShell. Second, they form a tree (or hierarchy) which shadows the instance hierarchy of all the shell widgets an application has. From now on I'll refer to this hierarchy as the ``shadow shell tree''. But first some more information about the rather less-spotted vendor shell extension objects.

By definition a VendorShell is a subclass of a WMShell and allows software vendors to provide new resources, class methods, etc. to support their custom window managers. So much for theory. In practice the spirit (idea) was willing but the flesh (the implementation) is still weak. If you would have to write your own VendorShell widget class that has additional instance variables (``resources'') you would be in trouble - or rather those programmers writing their X applications using your new VendorShell. As several widget classes are derived from the VendorShell class (for example the TransientShell, the TopLevelShell and the ApplicationShell, see figure on page ) these classes then would have to be recompiled. Otherwise the VendorShell part of an already compiled and older ApplicationShell would differ from that part of a new VendorShell. At this point the object-orientated approach simply can't handle the case where you need to replace a class within the class tree.

Historically, the CSF needed to add new resources to the VendorShell to support resolution independance, specific MWM functions and other ``features''. But extending the existing VendorShell was not desirable at all, as mentioned above, so the programmers at the CSF took another approach.

Figure: Class hierarchy for extension objects.

With M*TIF, every VendorShell widget (as well as every widget created from a subclass of VendorShell) is accompanied by a so-called VendorShell extension object. This VendorShell extension object (or ``VSE object'' for short) is a descendant of XmDesktopObject, XmExtObject, and thus finally of the Intrinsics' Object class (see figure ).

The Object class was made public in X11R4 to enable programmers to use the Intrinsics' classing and resource handling mechanisms for things besides widgets. Within M*TIF, the VSE objects serve to hold all the instance variables (resources) that had to be added to the VendorShell class after the Xt Intrinsics had already been written down.

XmExtObjectXmNlogicalParentThe starting point for all kind of extension object classes within LESSTIF is the XmExtObject class. This class provides for synthetic resources as well as external resources. In addition, every instance of a XmExtObject contains a pointer to its ``logical parent'' (resource XmNlogicalParent) that is the widget that owns the extension object (or that the extension object extends). You'll never find a XmExtObject in its logical parent's child list. One reason is that M*TIF seems to use some kind of self-crafted XtCreateWidget() when creating extension objects. A second reason is that LESSTIF currently uses a call to XtCreateWidget() when creating VSE objects. To cite Mitch, the affected logical parents keep ``those pesky [extension] objects'' out of the child list using special insert_child() and delete_child() methods.