Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!wuarchive!usc!ucsd!ucbvax!alphalpha.com!nazgul
From: nazgul@alphalpha.com (Kee Hinckley)
Newsgroups: comp.windows.x.motif
Subject: Re: C++ interface to Motif 1 of 2 (long)
Message-ID: <901117000115.9011@alphalpha>
Date: 17 Nov 90 04:01:15 GMT
References: <9011161934.AA00403@dolphin.aet_austin>
Sender: daemon@ucbvax.BERKELEY.EDU
Distribution: inet
Organization: The Internet
Lines: 76

> element array.  If I were to go into full production with my code this
> arg list would need to be changed to an array (preferably a C++ list
> object) which could grow as needed.  100 elements is a bit excessive
That's exactly what I did for my Motif wrappers.

> 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.

> 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?

> The callbacks, actions and event handlers are written as standalone
> C++ functions (not member functions).  I found this a bit limiting
> since you either have to make the functions friends of your class or
> make any extra data members public (this applies only if you
> subclassed the objects as I did).  What I did was write another set of 
> callback, actions and event handler macros to make them call member
> functions on my subclasses instead of being standalone C++ functions.
I  made dummy callbacks in C that called the C++ member functions.

> 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.

> 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.

> 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?

>> in class libraries like NIH.  One function in particular would be a
> overloaded (char*) operator so XMStrings could be easily converted to
> normal char pointers.  In contrast to the WWL, the XMString class has
That can't be done without modifying the header files (since XmString
was typedef'd to char *).  At 1.1.1 it should be fixed to be unsigned char *,
which will allow overloading like that.

Thanks for the summary!

					-kee

P.S.  I should mention that the reason I haven't released my widget classes
is that they are a) pretty tightly bound with very non-widget related
classes and b) only cover the subset of widgets that I cared about.  However
if anyone wants specific examples (menu stuff, or base classes or whatever)
I'd be happy to ship out pieces, but they'll be more useful as a reference
than a toolkit.