[Pipet Devel] executing a network script
Brad Chapman
chapmanb at arches.uga.edu
Fri May 5 15:09:35 EDT 2000
[...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
More information about the Pipet-Devel
mailing list