[Pipet Devel] executing a network script

[Jean-Marc Valin]

Brad Chapman a écrit :
> 
> [...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)?

Sounds fine! I'm not sure I understand the modifications you want to make,
though... could you explain more? Here's another precision I'd like to make
about the way Overflow works... I'm going to compare 3 classes: Node, UINode,
and GUINode

Node is the (abstract) base class for all operations (including the Network
class; a Network is a Node) if a certain node in the "program" is included twice
(because of subnet inclusion) then, there are two instances of these Nodes. 

UINode is not an abstract class and can represent any node type in the
"program". It is used to save/load XML and has a "build" method, which returns a
Node (actually an object of a class that derives from Node). 

GUINode derives from UINode and adds some Gnome functionalities. If I were to
write a KDE GUI, I'd simply create a KUINode that derives from UINode.

Note that the Node/UINode/GUINode is about the same for
Network/UINetwork/GUINetwork. Also, I think using swig is a good idea, as I'd
like to be able to use the original Overflow without python.

	Jean-Marc