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

David García Garzón dgarcia at iua.upf.edu
Sun Jun 8 02:20:46 PDT 2008


I would like to have a commit on the cut&paste patch, to accept this one 
separately. (i want the c&p working :-))) ) 

Pau, i'll do the commit of the patch before the positions in 30 min if you 
don't do it first.


On Diumenge 08 Juny 2008, Natanael Olaiz wrote:
> The same with little improvements in the code (deleted some unuseful
> loops).
>
> El 06/08/2008 01:43 AM, Natanael Olaiz escribió:
> > El 06/05/2008 07:37 AM, David García Garzón escribió:
> >> Well i think it is very important to keep the network, canvas
> >> agnostic, as well as keeping the NetworkCanvas clam agnostic. But as
> >> we are introducing the positions and the selections as part of the
> >> network itself i propose to add such an information to the network
> >> itself, not as part of the processings but as network optional
> >> attributes. That is duplicating the information but just during
> >> loading and storing. The key to eliminate a duplication hell is
> >> declaring such information in the Network is not reliable, is the
> >> canvas who set it before loading and recovers it after saving but
> >> clears it afterwards. So there is no temptation on using it in a
> >> different place than load/store.
> >>
> >> So how to implement that? For selections adding the network a
> >> std::set attribute of selected processing names. It has just effect
> >> on storing and only if it is not empty. If it is not empty the
> >> network should check if the name is in the set before storin it. On
> >> storing a selection and just on storing a selection call
> >> Network::UpdateSelections(list or other container), do the store and
> >> then clear them Network::ClearSelections.
> >> The Network::StoreOn will only store the processing whose name is in
> >> the set, or all of them if the set is empty. I think that this one
> >> would be the easier one and the first to be addressed.
> >>
> >> About the positions and sizes, i would use the same strategy. On
> >> load/store push or extract such information into the network being
> >> reliable just on load and store time, clearing it afterwards to be
> >> sure we don't rely on it after load/store. Such information should be
> >> transfered if present to the ProcessingDefinitionAdapter to xml them.
> >> Not that clear about the structure to store size and position but
> >> let's address first selections and then, let's see what about sizes
> >> and positions.
> >
> > This is a first attempt to store & restore positions and sizes too. I
> > make it in two steps, but I think it's not necessary...
> >
> > What do you think?
> >
> > BTW, I don't like that boxPos and boxSize goes first... can you
> > imagine names which begins with a latter letter than "t" (of type)? :-)
> >
> >
> > Regards,
> > Natanael.



-- 
David García Garzón
(Work) dgarcia at iua dot upf anotherdot es
http://www.iua.upf.edu/~dgarcia
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.clam-project.org/pipermail/clam-devel-clam-project.org/attachments/20080608/2a7b66d8/attachment.sig>


More information about the clam-devel mailing list