[...snip...my description of SWIGing the UI* classes of Overflow in the dl...] > Sounds fine! I'm not sure I understand the modifications you want to make, > though... could you explain more? Well, I don't really know if I'll have to make any modifications. Let me start working on it and see how things fit and we can discuss more... I just wanted to make the goal "a little bit of code rewriting" so then we could be excited if we had "no code rewriting." :-) > 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). Cool, this makes a lot of sense, since the dl is set up in a very similar way, except for the fact that I don't have an abstract node class. In the case of the dl, we have a non-abstract locus class, from which all other classes derive, including workspaces (the equivalent of your network). I also have the basic locus class derive from what is kind of a "persistence" class. Right now this class defines stuff for directly interacting with the file describing a locus (ie. loading it into DOM, and even actually getting the location of it), and then derived classes implement functions like create (like your "build") and remove that interact with this specific persistant representation. I forget exactly where I read about this and ripped it off from, but the idea is that we could change the underlying storing mechanism without totally having to completely gut and revamp the code. > 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. Loci doesn't have this formal inheritence of both the ui class and the dl class from an abstract base class. The reason for this is the goal of making ui's implementatble in any language. When the ui and dl were together, This kind of mechanism was starting to creep in (until I forcibly drug them apart). Personally, I like the goal of multiple UIs in different langauges, and not just different toolkits. This way maybe one day I'll be able to run Piper on my Mac with a java ui or something :-) > Also, I think using swig is a good idea, as I'd > like to be able to use the original Overflow without python. Great! I'll start taking a look at it and give updates as it goes along. As I said my goal is to not mess with your code, so you definately shouldn't have to give up the stand alone operation of Overflow. Of course, I'm positive that eventually you will be drawn into the wonderful world of python and won't want Overflow to run without python wrapping it :-) Brad