[Clam-devel] subnetworks interfacing - NE several opened files
Natanael Olaiz
nolaiz at gmail.com
Tue Jul 29 23:48:43 PDT 2008
Here is almost the same refactoring, but BaseNetwork is all pure
virtual, FlattenedNetwork is the actual Network, and MainWindow uses
_flattenedNetwork for all player/flow management and BaseNetwork (for
now the same FlattenedNetwork) to store/load and set the canvas network.
Plus I changed all the instances of CLAM::Network to FlattenedNetwork
(but the tests). As I said in my previous mail, that need further
revision to see what class use in each case, but I think it could serve
to found easily all the actual uses with the new Network class.
BTW, I'd lost a lot of time searching a compilation error which was
solved with a scons --clear on the library (it was keep searching
CLAM::Network methods).
And I used r11754. See the reason in my next mail...
I'll start filling up the new Network class...
Regards,
Natanael.
El 07/29/2008 05:47 AM, Pau Arumí escribió:
> 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
>>
>
>
> _______________________________________________
> 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_AllInstances.patch
Type: text/x-diff
Size: 101584 bytes
Desc: not available
URL: <http://lists.clam-project.org/pipermail/clam-devel-clam-project.org/attachments/20080730/08c8b6d3/attachment-0004.patch>
More information about the clam-devel
mailing list