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

[Pau Arumí Albó]

El dt 10 de 06 de 2008 a les 06:53 -0300, en/na Natanael Olaiz va
escriure:
> 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?

Er yes could lead to potential problems. We don't want duplicated
information and the original info sits in the canvas, so let's use it
when loading and saving and keep it clean the rest of the time.

> > 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 like it concise as is now.

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

First finish the current part, of course.

About the subnetworks, let's keep it in the fridge till next week. 
A related feature you could add, though is "insert network from file"
which is not really a subnetwork, and seems trivial to do now.

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

Yeah, feel free to propose new features.

My list of little interesting features are (all of them needs
discussion):
* Comments boxes in the Canvas
* Step-by-step network execution
* Processing errors handling and notification to the user

> and on the other 
> hand, the OSC Blender sender and integration to ChoreoSequencer....

I think you won't get bored this summer :)

P