[Clam-devel] subnetworks interfacing - NE several opened files
Pau Arumí
parumi at iua.upf.edu
Tue Jul 29 01:47:36 PDT 2008
On dt, 2008-07-29 at 04:03 -0300, Natanael Olaiz wrote:
> Sending a first attempt of using BaseNetwork abstract to decouple NE
> from Network.
> It still needs clean-up, there is no FlattenedNetwork yet, neither
> subnetworks or changes in the XML methods.... But CLAM::BaseNetwork here
> doesn't use/have any flow/player related method, and is used on
> ClamNetworkCanvas instead of CLAM::Network.
>
> BTW: almost all methods on BaseNetwork are virtual (some could be changed).
Well, Some methods in BaseNetwork are virtual pure (=0) but, at the same
time, they are implemented. No sense. (I don't understand why the
compiler does not complain)
What I see is that you've moved stuff from Network to BaseNetwork. No,
the idea is maintain all the implementation in Network and create a new
"interface" class BaseNetwork. By interface I mean a class made of
abstract (virtual pure) methods. No attributes, no code.
Making NE to be coupled only to the interface class is the first step.
Then we can substitute the FlattenedNetwork (the current Network class)
to the new Network class. This new class will have code. It will
actually maintain a hierarchical representation of the graph, whose
leafs are ID strings (ex: Network/Subnetwork/Processing) that relates
the the actual processing in the FlattenedNetwork.
Smaller things:
In MainWindow.hxx you are still using Network while should be
BaseNetwork. But maybe it is just that you wanted to concentrate on
changing object for pointer first...
Then, about the change "Network _network" to "BaseNetwork * _network" in
MainWindow. It is ok, but since the object ownership is still in
MainWindow, use a normal attribute instead of a dynamic object (created
with new). I mean: "_network = & _flattenedNetwork". This is simpler
because we don't have to worry about freeing memory.
Waiting for a new patch. Its a good start though :-)
P
> Next discussed IRC steps:
> 1-
>
> * Rename Network to FlattenedNetwork
> * Improve the "graph getter" interface (used by Canvas and FlowControl)
> * Refactor FLowControl so it have a unique GraphChanged() method
>
> 2-
>
> * Create a new class Network and duplicate the graph model, using
> IDs that refers to the flattened network. Eacy graph change is
> automatically sync with the flattened network.
>
> 3
>
> * introduce subnetworks with a Composite (truly Composite) pattern.
> Thoroughly unit tested
>
> 4-
>
> * User Interface, and complex workflows (like create subnetwork)
>
>
> I'll continuing on the next steps, but meanwhile we could test and
> define the BaseNetwork interface.
>
>
> Regards,
> Natanael.
>
> El 07/24/2008 05:51 AM, Pau Arumí escribió:
> > On dc, 2008-07-23 at 23:06 -0300, Natanael Olaiz wrote:
> >
> >> El 07/23/2008 06:42 PM, Pau Arumí escribió:
> >>
> >>> On dc, 2008-07-23 at 17:58 -0300, Natanael Olaiz wrote:
> >>>
> >>>
> >>>> So, with all this context I ask: what do you think to add the Window
> >>>> menu item, and a "close network" subitem on "file", to allow having
> >>>> severals opened networks? The active one will be the one you are
> >>>> seeing (on the original "Network" tab).
> >>>>
> >>>>
> >>> And what would you do with the NetworkPlayer if the user change tabs
> >>> while running?
> >>>
> >>>
> >> Ignore the requests? :)
> >>
> >> I don't know what is the best way to manage that. Maybe letting the
> >> user to chose the view and the active one, maybe having another tab...
> >>
> >
> > But now that we have copy-paste we can easily move portions of networks
> > from one NE instance to another, I really don't see the need for
> > multidocument (other that editing multiple levels of a hierarchy).
> > Maybe we should do like inkscape (yes, I love that app!): File->Open
> > starts a new app instance instead of changing the content of the
> > existing one.
> >
> >
> >> Hernán had suggested something similar:
> >> https://llistes.projectes.lafarga.cat/pipermail/clam-devel/2008/001875.html
> >>
> >>
> >>> I don't see multi-document useful in NetworkEditor (though I'm always
> >>> open to get convinced)
> >>>
> >>> I think that NE with subnetworks should look like a code debugger: you
> >>> deal with two views: 1. the stack showing a list higher contexts of the
> >>> current inner executing line and 2. the code in the chosen context.
> >>>
> >>> Now, back to NE: of course 2. corresponds to the network selected in 1.
> >>> And 1, could be a textual list, as a first version, and a "list" of
> >>> networks miniatures as a second version.
> >>>
> >>>
> >> I imagined a main running-capable network canvas, from where you can
> >> make/open a subnetwork (in the same, or other tab), and if from the
> >> new canvas view you can do the same, and so on with
> >> sub-sub-...-networks.
> >>
> >>
> >>> However, in my opinion subnetworks should not be approached from the UI,
> >>> but from the model. Because now it's hard to decide how will be the
> >>> model the UI will interact till it's not done.
> >>>
> >>>
> >> Yes. That is the reason because I said to duplicate some parameters
> >> for now, on the main canvas. But I though the graphical management
> >> (canvas) as a useful tool to test and see the models. Anyway, now I
> >> understand better your idea on the reply to Hernán in the previous
> >> thread.
> >>
> >>
> >>> Refreshing a talk at irc, this should be the steps:
> >>> 1. improve current Network interface to facilitate Network clients
> >>> (basically NetworkCanvas and FlowControl) getting the graph
> >>> 2. make Network a composite (as in the pattern).
> >>> 3. work ou the UI
> >>>
> >>>
> >> But on 1. I used methods of ClamNetworkCanvas and inherited members.
> >> For instance, how would you make the subnetworks? I started with
> >> selecting the processings on the canvas, and reusing the actual
> >> network xml dump and restore methods (used for loading/saving and
> >> copy&paste). Another option I think could be to import a network as a
> >> subnetwork. But the positions are managed from ClamNetworkCanvas, not
> >> NetworkCanvas. Should I ignore the geometries for now, or implement
> >> those methods on NetworkCanvas as a part of the refactoring and let
> >> all the CLAM::Networks management be just on NetworkCanvas?
> >>
> >
> >
> > It is interesting to analyze how subnetworks will be created, from the
> > user point of view. I can think of this:
> > 1. the user starts a new subnetwork from scratch, and then
> > populates it.
> > 2. the user adds a subnetwork choosing from a network file (or a
> > network-tree, similar or merged with processing-tree.
> > 3. the user select a subset of a network and hits a "extract to
> > subnetwork" button
> > 4. the user select a subset of a network and hits a "save as
> > network file" (we might want to have the saved network in the
> > network-tree)
> >
> > 2,3 and 4 are basically 1 doing some "extra work". I'm not sure if this
> > "extra work" should be responsibility of the NetworkCanvas or the
> > Network (I would say the first).
> > So we should begin addressing the interface (and tests) to Network in
> > order to do 1. For example:
> >
> > Network subnet;
> > subnet.AddProcessing(..);
> > ...
> > Network net;
> > net.AddNetwork( subnet );
> >
> > Or maybe we should generalize Processing/Network -> Module? so
> > net.AddModule
> >
> >
> > About the NCanvas and Network relation:
> > I think we should have NCanvas instances only for (sub)networks that are
> > currently opened --so, not for the whole hierarchy because this would be
> > like duplicating the model, making difficult to add and remove subtrees.
> > Therefore the position information should reside in the Network object
> > (we already have this), that means that each time a canvas is closed it
> > must synchronize its position info to its network.
> >
> > P
> >
> >
> >
> >>> Point 2 is difficult. My design proposal (discussed with David) is the
> >>> following: the root of the composite should have a FlattenedNetwork
> >>> object associated. FlattenedNetwork and Network both derive from an
> >>> abstract BaseNetwork. Only FlattenedNetwork have a NetworkPlayer and a
> >>> FlowControl, and owns all the processings in the hierarchy.
> >>> This should be more discussed, and developed test-driven in small steps.
> >>>
> >>>
> >> OK.
> >>
> >>
> >> Regards,
> >> Natanael.
> >>
> >>> P
> >>>
> >>>
> >>> _______________________________________________
> >>> Clam-devel mailing list
> >>> Clam-devel at llistes.projectes.lafarga.org
> >>> https://llistes.projectes.lafarga.org/cgi-bin/mailman/listinfo/clam-devel
> >>>
> >>>
> >>>
> >> _______________________________________________
> >> Clam-devel mailing list
> >> Clam-devel at llistes.projectes.lafarga.org
> >> https://llistes.projectes.lafarga.org/cgi-bin/mailman/listinfo/clam-devel
> >>
> >
> >
> > _______________________________________________
> > Clam-devel mailing list
> > Clam-devel at llistes.projectes.lafarga.org
> > https://llistes.projectes.lafarga.org/cgi-bin/mailman/listinfo/clam-devel
> >
> >
>
> _______________________________________________
> Clam-devel mailing list
> Clam-devel at llistes.projectes.lafarga.org
> https://llistes.projectes.lafarga.org/cgi-bin/mailman/listinfo/clam-devel
More information about the clam-devel
mailing list