[...snip, discussion about what Overflow code does and how to use it in Piper...] Jean-Marc Valin wrote: > in the vflow/src directory there are UI* classes and GUI* classes. The UI* > classes (as in UINetwork, UINode, ...) are toolkit-independent (and are used > in > the command-line tool). They take care of XML saving/parsing, and building > runnable networks from the object description. the GUI* classes (as in > GUINode, > GUINetwork, ...) are gnome-dependent and hadle the canvas items in the GUI. I definately want to make use of the UI* classes in the dl! The structure of your classes is very similar to what I have mapped out for trying to do the same thing (from scratch) in the dl (you can take a look at the class design I sketched out in the loci module in middle/library/modules/bl/blrepresentation.py--and no, I swear I didn't rip my design off from you!). Thanks for clarifying what the different classes in vflow do so I could see this incredible similarity; I apologize that I didn't see this earlier (although it was probably good for me to think through the design on my own so I can understand your code better). The approach I'd like to try and take for incorporating them is to use SWIG (swig.sourceforge.net) to wrap the C++ into python and then just have my python skeleton classes to inheret from your C++ classes (just to provide a basic python-looking wrapper around the actual C++ functionality). I can start tackling this over the next week. I'm learning SWIG right now to mess with XDBM in python, so hopefully by the time I get into wrapping your code I'll be able to do it properly :-) It looks like most of the classes just take strings (and other UI* objects) for initialization, so what I'll be doing is feeding this information into the objects from stored xml describing the gui, instead of from the GUI itself (this is due to the separation of build time from run time what Jeff mentioned earlier). So essentially the code rewrites for Overflow should be very little. Under this scheme you can modify the underlying C++ as much as you want, and I'll just have to fix things if you modify the interface. How does this approach sound (especially to Jean-Marc and Dominic)? Brad