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

[Natanael Olaiz]

El 06/05/2008 06:57 AM, Pau Arumí Albó escribió:
> 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ó:
>>>>     
>>>>         
>>>>> On dt, 2008-06-03 at 04:48 -0300, Natanael Olaiz wrote:
>>>>>   
>>>>>       
>>>>>           
>>>>>> El 06/02/2008 08:14 AM, David García Garzón escribió:
>>>>>>     
>>>>>>         
>>>>>>             
>>>>>>> On Dilluns 02 Juny 2008, Pau Arumí Albó wrote:
>>>>>>>   
>>>>>>>       
>>>>>>>           
>>>>>>>               
>>>>>>>> El dl 02 de 06 de 2008 a les 06:19 -0300, en/na Natanael Olaiz va
>>>>>>>>
>>>>>>>> escriure:
>>>>>>>>     
>>>>>>>>         
>>>>>>>>             
>>>>>>>>                 
>>>>>>>>> Finally!
>>>>>>>>> I need to clean up the code, optimize some rutines, and it doesn't save
>>>>>>>>> the positions. But it works. :-)
>>>>>>>>>       
>>>>>>>>>           
>>>>>>>>>               
>>>>>>>>>                   
>>>>>>>> Wow, this is big step forwards! :-)
>>>>>>>>
>>>>>>>> Some questions mainly for Natanael and David,
>>>>>>>>
>>>>>>>> Have you evaluated if the onPasteProcessingsFromClipboard() could reuse
>>>>>>>> the normal xml network loading function? (maybe would need adaptation) ?
>>>>>>>> That would reduce a lot of code (and duplication)
>>>>>>>>     
>>>>>>>>         
>>>>>>>>             
>>>>>>>>                 
>>>>>>> I think so but some adaptation should be done to the NetworkAdapters to store 
>>>>>>> just the selected processings and related connections.
>>>>>>>   
>>>>>>>       
>>>>>>>           
>>>>>>>               
>>>>>> OK, I'll see that. It could be also good to start thinking about 
>>>>>> subnetworks paths.
>>>>>>
>>>>>>     
>>>>>>         
>>>>>>             
>>>>>>>> I think that this feature (and the future sub-networks) is asking for
>>>>>>>> embedding processing-boxes positions in the clamnetwork xml (instead of
>>>>>>>> keeping a separate binary .pos file). Getting rid of .pos files was a
>>>>>>>> TODO actually. Do you agree?
>>>>>>>>     
>>>>>>>>         
>>>>>>>>             
>>>>>>>>                 
>>>>>>> I fully agree.
>>>>>>>   
>>>>>>>       
>>>>>>>           
>>>>>>>               
>>>>>> Me too. Another task to add. :-)
>>>>>>     
>>>>>>         
>>>>>>             
>>>>> 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). 
> 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.
>   

Yes, it sounds like a good solution.

> However at this point I'd like to have David's input, he is the expert
> on NE user-interface.
>   
OK.


Regards,
Natanael.
> P
>
>
>
>   
>> Am I wrong?
>>
>> What I can do without that problem is to load(/merge) into a used 
>> network. Is only that what you originally mean?
>>
>>
>> Regards,
>> Natanael.
>>     
>
>
> _______________________________________________
> Clam-devel mailing list
> Clam-devel at llistes.projectes.lafarga.org
> https://llistes.projectes.lafarga.org/cgi-bin/mailman/listinfo/clam-devel
>
>