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
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Clam-devel mailing list [email protected] https://llistes.projectes.lafarga.org/cgi-bin/mailman/listinfo/clam-devel
