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

Natanael Olaiz nolaiz at gmail.com
Tue Jun 10 02:53:19 PDT 2008


El 06/10/2008 06:03 AM, Pau Arumí Albó escribió:
> El dt 10 de 06 de 2008 a les 03:31 +0200, en/na David García Garzón va
> escriure:
>   
>> Pau, i just commited the patch previous to the pos and sizes because it 
>> modifies the network XML and further changes might be done with care because 
>> they might break stored networks. We should be sure that the format is the 
>> one to stay for a while.
>>     
>
> Yes we'll need to be sure about the new format.
> And I expect that backwards compatibility won't be a problem. Natanael,
> warn us if you think so.
>   

Well, in the processing adapter I putted a check line to don't store the 
new attributes if are not given, but any check on the load... since it 
works good reading a file with or without the new attributes. I don't 
think it would affect other uses (i.e. the backwards compatibility 
wouldn't be affected).
The major problem as it's now is if you load a network with the 
attributes, it will fill the _processingsBoxesAttributes map. So, I send 
here a new patch for Network.cxx that clear it every time you do a load, 
to avoid fill all the memory if you load so much times without clear it.

Do you think it's  a problem that _processingsBoxesAttributes could be 
non-empty without using it?

> BTW, I notice that the size/position extension only effects the
> copy-paste and not the network saving. Is this expected?
>   
Yes, to try it on clipboard before files (i.e., non-intrusive test)... :)

>> The point is that the proposed patch stores the position and the size as 
>> string:
>> boxPos="20,25" boxSize="400,20"
>> Is that what we want?
>> not x='20' y='25 height='20' widht='400'
>> or even position='20,25' size='400,20'?
>>     
>
> My vote is clearly for the last one (away with boxXxx). 
> And using integers (or floats) all the way till the very last step is
> safer, and more coherent with the existing format. 
> However, if changing this is too complex we might leave it as is now.
> Natanael?
>   
I don't think so.
Do you still want the attributes inside the processing path? Because as 
I wrote, another option could be using another path for boxes related 
attributes.

>> I also guess that the procAttribMap to store such attributes is a too generic 
>> tool that can become subject of abuse if it is in the api. We are expected to 
>> have some kind of network configuration/attributes and i don't know if this 
>> is missleading when we actually want pos and size. Just a feeling not a 
>> conviction. In this part we are more in Pau's zone.
>>     
>
> Well in the patch I'm looking now, if I see it correclty, the name is
> always "BoxesAttributes".
Yes, I changed it on the last patch.

>  It sound ok, though not perfect, to me. Maybe
> "ProcessingAppearance"? 
>   
OK.
>> Natanael, you should also review the naming conventions in the new functions: 
>> Some local variables starting with upper case and some CripAbrvOnNams. 
>> The worst thing on abreviating words is that you never remember which letters 
>> you removed. Modern editors have completition. You can also use the context, 
>> if the only ones in your context to have positions and sizes are processings  
>> you can remove the Proc and call them prositions and sizes.
>>     
>
> And also: ifHasSelectionAndContains(...) ->
> HasSelectioniAndContains(...)
>   
OK.

> Great work!
>   

Thanks!

BTW.... Now what? ;-P Do you think is a good time to start looking at 
ProcessingComposite and subnetworks related code?
If you suggest me some little improvements to do about it (or another 
related task) as these on the interface I'll appreciate it... I like it 
as a funny way to learn doing useful tasks on the way. :)
Anyway, meanwhile I want to make something to manage groups in the 
canvas, and sendings/receivings processing boxes... and on the other 
hand, the OSC Blender sender and integration to ChoreoSequencer....


Regards,
Natanael.
> Pau
>   

-------------- next part --------------
A non-text attachment was scrubbed...
Name: Network_cxx.patch
Type: text/x-patch
Size: 3166 bytes
Desc: not available
URL: <http://lists.clam-project.org/pipermail/clam-devel-clam-project.org/attachments/20080610/7dc839e1/attachment-0003.bin>


More information about the clam-devel mailing list