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

Natanael Olaiz nolaiz at gmail.com
Tue Jul 29 00:03:03 PDT 2008 

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).

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
>
>   

-------------- next part --------------
A non-text attachment was scrubbed...
Name: NetworkRefactoring.patch
Type: text/x-diff
Size: 71774 bytes
Desc: not available
URL: <http://lists.clam-project.org/pipermail/clam-devel-clam-project.org/attachments/20080729/71580ec8/attachment-0004.patch>

More information about the clam-devel mailing list