[Clam-devel] subnetworks interfacing - NE several opened files

[Pau Arumí]

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