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

[Natanael Olaiz]

El 06/13/2008 06:39 AM, Pau Arumí Albó escribió:
> El dj 12 de 06 de 2008 a les 20:02 -0300, en/na Natanael Olaiz va
> escriure:
>   
>> Well, sorry for the late patch. I was quite busy with other things, and 
>> in the middle thinking and testing different types and ways to pass the 
>> data between classes.
>>     
>
> Sure, no need for hurrying.
>
>   
>> Here is my actual solution (which I don't know if it's so good): I made 
>> a subclass of network: ProcessingGeometry[1]. I think maybe it would be 
>> simpler with just a structure, or putting it on other place 
>> (Processing?). Any critic is welcome.
>>     
>
> Ok, I see that you made an "inner" class.
>
> * A formatting issue: we follow the rule of adhering to "local"
> formatting convention. So in Network, let's use Method() instead of
> method()
>
> * I much prefer a simple structure with no getters. But specially
> without string conversion methods. The conversion to XML should be done
> in the ProcessingDefinitionAdapter, using XMLAdapter<int>. Much simpler!
>   

So, I'll use: x='...', y='...', width='...', height='...', it's that OK?
Plus, how should I pass the data from the Network to 
ProcessingDefinitionAdapter, in 4 int variables, or one structure? If a 
structure, where could I put it definition?

>> On MainWindow I added a line to load the geometries from the XML, and if 
>> it fails try with the .pos file.
>> I would need to add a checkbox when saving, to select what format do you 
>> want. By now, it write only the traditional .pos file (for development 
>> testings you can paste the clipboard after copy / paste to a file, and 
>> load it).
>>     
>
> No, I think this features/complexity doesn't pay its cost in this case.
> Let's do the jump without fear doing:
>
> * we'll ask for extensive testing when committed (and revert if
> something fails).
>
> * You could leave the code depending on a constant like this
> const saveUsingOldPosFiles=false;
> So that if we find problems, reverting the behavior costs nothing.
> And when tested all the .pos stuff will be kicked out.
>   

OK.

> A different issue:
>
> Have you considered not passing the geometryMap between Network and
> Canvas?
> The network could offer two methods with a processing key, like this.
>
>         Network::AddProcessingGeometry(processing, geometry)
>         ProcessingGeometry = Network::GetProcessingGeometry(processing)
>   

Yes, but I think that could difficult to clear the Network map (now you 
read and clear after at once). If not, I need to erase element by 
element every time you get a geometry from the canvas, and check allways 
if it's empty and do the clear. Hmm... yes, it could be even simpler 
that the actual code. :)


Regards,
Natanael.

>         
> Wouldn't this be simpler (in terms of interface and avoiding coupling)?
> But maybe I'am missing something. Natanael, David, please go on with
> your opinions.
>
> (If finally agree, we could as well live this as a posterior
> refactoring, after commit)
>
>
> P
>
>
>
> _______________________________________________
> Clam-devel mailing list
> Clam-devel at llistes.projectes.lafarga.org
> https://llistes.projectes.lafarga.org/cgi-bin/mailman/listinfo/clam-devel
>
>