[Clam-devel] Copy & Paste processings on canvas patch

Natanael Olaiz nolaiz at gmail.com
Fri Jun 6 23:16:54 PDT 2008

A corrected version of the patch (previously I putted the actions for 
copying on NetworkCanvas, with only an implementation on ClamNetworkCanvas).
Plus, I extended the copy functionality to a new "cut" clearly than my 
previous suggestion (all just in the canvas).


El 06/06/2008 08:38 PM, Natanael Olaiz escribió:
> Here is the new version.
> How can I protect the new CLAM::Network methods from other calls than 
> from ClamNetworkCanvas?
> If you think it's going well, I can add a new bool attribute of 
> "isCutMode", to erase the processings once are copied.
> Regards,
> Natanael.
> El 06/05/2008 12:04 PM, Pau Arumí Albó escribió:
>> El dj 05 de 06 de 2008 a les 12:37 +0200, en/na David García Garzón va
>> escriure:
>>> On Dijous 05 Juny 2008, Pau Arumí Albó wrote:
>>>> El dj 05 de 06 de 2008 a les 06:15 -0300, en/na Natanael Olaiz va
>>>> escriure:
>>>>> El 06/04/2008 06:17 AM, Pau Arumí Albó escribió:
>>>>>> El dc 04 de 06 de 2008 a les 03:58 -0300, en/na Natanael Olaiz va
>>>>>> escriure:
>>>>>>> El 06/03/2008 03:16 PM, Pau Arumí escribió:
>>>>>>>> After some chat with David about this, I think it would be good to
>>>>>>>> start with 1) reuse the network loading/saving code, before 
>>>>>>>> starting
>>>>>>>> 2) adding positions to the xml. This is because having 2) will 
>>>>>>>> make
>>>>>>>> the load/save more difficult, as needs transferring data from
>>>>>>>> canvas/procboxes to the network, and should be better 
>>>>>>>> approached as a
>>>>>>>> posterior refactoring.
>>>>>>>> Don't hesitate to ask if find problems
>>>>>>> Should I store the positions & sizes within the Network root 
>>>>>>> path, or
>>>>>>> on a separate one (let's call it "NetworkCanvas", for instance)? In
>>>>>>> the second case I will need to make two calls to dump/restore 
>>>>>>> methods
>>>>>>> (one within the network -as right now-, and the other within the
>>>>>>> canvas), but that keeps the data separated and doesn't need to
>>>>>>> transfer any new data to the network.
>>>>>>> Is my question clear enough? What do you prefer?
>>>>>> It makes sense to me but I'm not sure about the details -- specially
>>>>>> who and how to close the xml doc if we have two dump calls?
>>>>>> One possible solution that comes to my mind is adding a new string
>>>>>> argument to the Dump mothod (or function, don't remember) 
>>>>>> containing an
>>>>>> "extra root" with the positions and sizes.
>>>>>> However, this is 2) and, IMO, 1) should be done before.
>>>>> Sorry to insist.... but thinking about it, I'm wondering how to reuse
>>>>> the code to save selections without get the same problem of 
>>>>> positions.
>>>>> The selections are attributes of ProcessingBoxes, just like 
>>>>> positions!
>>>>> So, I can pass the list of selected processings to the Network, but I
>>>>> think doing that is maybe more weired than just start doing the
>>>>> integration in a higher level, in ClamNetworkCanvas, deriving it from
>>>>> Components, redefining StoreOn and LoadFrom, and make the
>>>>> ProcessingBoxes correspondents definition adaptions...
>>>> Well yes I see it's not an easy problem.
>>>> The main problem I see implementing Store and Load methods in
>>>> NetworkCanvas is that will duplicate the code in Network::StoreOn.
>>>> And we need this functinality in Network for the NE-less use cases.
>>>> What about adding optional decorations (in the design pattern 
>>>> sense) in
>>>> the Processing in the network containing the Canvas data: position,
>>>> size, isSelected (so that you can store only the selected 
>>>> processings in
>>>> a given string).
>>> I think that the decorator already exists: it is the 
>>> ProcessingDefinitionAdapter it is a matter of adding the position 
>>> information besides the name.
>>>> Then when the Canvas store would consist on first pushing the
>>>> canvas-related data into the network and then call the normal Store 
>>>> (or
>>>> Dump). And similarly for Loading.
>>>> However at this point I'd like to have David's input, he is the expert
>>>> on NE user-interface.
>>> Well i think it is very important to keep the network, canvas 
>>> agnostic, as well as keeping the NetworkCanvas clam agnostic. But as 
>>> we are introducing the positions and the selections as part of the 
>>> network itself i propose to add such an information to the network 
>>> itself, not as part of the processings but as network optional 
>>> attributes. That is duplicating the information but just during 
>>> loading and storing. The key to eliminate a duplication hell is 
>>> declaring such information in the Network is not reliable, is the 
>>> canvas who set it before loading and recovers it after saving but 
>>> clears it afterwards. So there is no temptation on using it in a 
>>> different place than load/store.
>>> So how to implement that? For selections adding the network a 
>>> std::set attribute of selected processing names. It has just effect 
>>> on storing and only if it is not empty. If it is not empty the 
>>> network should check if the name is in the set before storin it. On 
>>> storing a selection and just on storing a selection call 
>>> Network::UpdateSelections(list or other container), do the store and 
>>> then clear them Network::ClearSelections.
>>> The Network::StoreOn will only store the processing whose name is in 
>>> the set, or all of them if the set is empty. I think that this one 
>>> would be the easier one and the first to be addressed.
>>> About the positions and sizes, i would use the same strategy. On 
>>> load/store push or extract such information into the network being 
>>> reliable just on load and store time, clearing it afterwards to be 
>>> sure we don't rely on it after load/store. Such information should 
>>> be transfered if present to the ProcessingDefinitionAdapter to xml 
>>> them. Not that clear about the structure to store size and position 
>>> but let's address first selections and then, let's see what about 
>>> sizes and positions.
>> I agree with the approach.
>> Now let's see if Natanel can defeat the evil details :-)
>> As David says, let's first address the selections part, since this will
>> define the  PBox-Canvas-Network communication while maintaining the
>> changeset small.
>> P
>> _______________________________________________
>> 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: CopyAndPasteProcessingsFromCanvas.patch
Type: text/x-patch
Size: 12424 bytes
Desc: not available
URL: <http://lists.clam-project.org/pipermail/clam-devel-clam-project.org/attachments/20080607/31e78585/attachment-0004.bin>

More information about the clam-devel mailing list