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

[Natanael Olaiz]

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: 11797 bytes
Desc: not available
URL: <http://lists.clam-project.org/pipermail/clam-devel-clam-project.org/attachments/20080606/2ab1b28e/attachment-0003.bin>