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

Natanael Olaiz nolaiz at gmail.com
Thu Jun 5 02:15:13 PDT 2008


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

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.




More information about the clam-devel mailing list