Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sun-barr!apple!agate!ucbvax!dolphin.aaet.ti.com!ctim
From: ctim@dolphin.aaet.ti.com (Craig Timmerman)
Newsgroups: comp.windows.x.motif
Subject: Re: C++ interface to Motif 1 of 2 (long)
Message-ID: <9011191652.AA01032@dolphin.aet_austin>
Date: 19 Nov 90 16:52:20 GMT
References: <901117000115.9011@alphalpha>
Sender: daemon@ucbvax.BERKELEY.EDU
Distribution: inet
Organization: The Internet
Lines: 91

> > The bindings keep a global hash table of widget id to class instance
> > mappings.  When you call the object's constructor the mapping entry is
> > put into the hash table.  When an object is destroyed the hash table
> > entry is removed.  The bindings use the hash table for mapping Xt
> > calls which return widgets to the objects that you want to really use
> > in your C++ program.
> That sound expensive.  Are all of the X[tm] functions really defined as
> member functions?  E.g. What about XmProcessTraversal (well, I
> suppose that's only 1.1) or XtMapWidget.  If every one of those is
> there that sounds like a fairly heavy object.

I haven't done an exhaustive search, but most of the Xt/Xm calls are
member functions (X11R3 and Motif 1.0 only).  I don't really know what
you mean by heavy.  There is a short stub function for each Xt/Xm call
supported as a member function.  The added code for each function will
add code size, but only once, not per created object.  The objects are
call overhead heavy since the member functions are true functions.
This is one area that should be fixed.  It would be much more
efficient if they were just inlines.  The only true overhead each
object carries are data members for the Widget, arglist, and a
argcount.

> > instance.  This way you can keep the code for the callbacks in C++ and
> > never have to worry about referencing widgets.  This is a big
> But it must produce a dummy callback routine no?  Or does it
> just assume it knows the C++ calling conventions?  Or does it have
> one callback for each signature, which then converts to object and
> calls the C++ callback?

I should have been more explicit here.  The macros you use to define
the callbacks do create normal Xt callbacks.  The macros actually just
define the first three/four lines of the callback (the callback
definition, opening brace, do the widget->object hash table look up).
You provide the rest of the callback code including the terminating
brace.  The thing this scheme buys you is the widget to object
mapping.  All of the code you write/see only deals with the object and
not the widget.

> > The first thing has to do with the destructors.  The only thing the
> > class destructors do is remove the widget<->object mapping from the
> > hash table.  The object instance will be destroyed but not the widget
> > itself.  
> This is not an easy problem.  I fouled it up several times.  My solution was
> to not actually use the destructor for the widget (except at the very
> base class).  Particularly because in some instances I want to do
> window cacheing and don't *really* want to destroy the widget.  What
> I did was have the object constructor put a delete callback on the
> widget.  When I want to destroy an object I call a special deleteWidget
> member function.  That function then calls XtDestroyWidget on the
> widget, which then calls back to destroy the object when the time
> comes.  This allows caching and also ensures that the object doesn't
> get referenced after it's been deleted.

I don't know if I follow all your reasoning here.  Since I create 99%
of these wdiget objects using the new operator they are going to be
around (cached) until I explicitly delete them.  Therefore the
destructor seems to be the right place to put the widget destruction. 

> > There needs to be more convenence functions/classes added.  Creating
> > menus is one places where this is nice.  I have created a menu item
> They don't do that?  That's the main reason for using wrappers in 
> my mind.  I don't create them for lower class objects, just for the
> complicated ones (like list, text, dialog, main window) and for complex
> ones like menubar, pulldown, optionmenu.

I agree fully.  They only provide equvilents for what already exists.
They didn't try to add functionality.  This is probably just because
of time constraints and lack of trying this out on a large scale
product.  All of the demo/test programs that came with it are just
variations on "Hello World".  You don't get a very good feel for what
additions need to be made with tests like that.  This is a major area
for expansion IMHO.  Any expansion should also be done in pure C++.
I.E. Use C++ classes where ever possible. 

> > window.  Asking for its parent gets a hash table error since there is
> > no C++ object for the clip window.
> But you need to know the parent for lots of things!  Or does it not
> do the convenience widgets like ScrolledText and ScrolledList?

It supports all of the widgets.  This is why this is such a big
problem.  I have only run into it on scrolled windows, but any Motif
widget that creates widgets for you will be a problem.  I think it's a
fixable problem (some of the constructors would need to be smarter and
create extra objects), but it's a problem none the less.


----------------------------------------------------------------------
Craig Timmerman 	ctim@aaet.csc.ti.com
Texas Instruments	
Austin, TX		
----------------------------------------------------------------------