[Clam-devel] Copy & Paste processings on canvas patch
Natanael Olaiz
nolaiz at gmail.com
Fri Jun 6 23:16:54 PDT 2008
A corrected version of the patch (previously I putted the actions for
copying on NetworkCanvas, with only an implementation on ClamNetworkCanvas).
Plus, I extended the copy functionality to a new "cut" clearly than my
previous suggestion (all just in the canvas).
Regards,
Natanael.
El 06/06/2008 08:38 PM, Natanael Olaiz escribió:
> Here is the new version.
> How can I protect the new CLAM::Network methods from other calls than
> from ClamNetworkCanvas?
>
> If you think it's going well, I can add a new bool attribute of
> "isCutMode", to erase the processings once are copied.
>
> Regards,
> Natanael.
>
> El 06/05/2008 12:04 PM, Pau Arumí Albó escribió:
>> El dj 05 de 06 de 2008 a les 12:37 +0200, en/na David García Garzón va
>> escriure:
>>
>>> On Dijous 05 Juny 2008, Pau Arumí Albó wrote:
>>>
>>>> El dj 05 de 06 de 2008 a les 06:15 -0300, en/na Natanael Olaiz va
>>>>
>>>> escriure:
>>>>
>>>>> El 06/04/2008 06:17 AM, Pau Arumí Albó escribió:
>>>>>
>>>>>> El dc 04 de 06 de 2008 a les 03:58 -0300, en/na Natanael Olaiz va
>>>>>>
>>>>>> escriure:
>>>>>>
>>>>>>> El 06/03/2008 03:16 PM, Pau Arumí escribió:
>>>>>>>
>>>>>>>> After some chat with David about this, I think it would be good to
>>>>>>>> start with 1) reuse the network loading/saving code, before
>>>>>>>> starting
>>>>>>>> 2) adding positions to the xml. This is because having 2) will
>>>>>>>> make
>>>>>>>> the load/save more difficult, as needs transferring data from
>>>>>>>> canvas/procboxes to the network, and should be better
>>>>>>>> approached as a
>>>>>>>> posterior refactoring.
>>>>>>>>
>>>>>>>> Don't hesitate to ask if find problems
>>>>>>>>
>>>>>>> Should I store the positions & sizes within the Network root
>>>>>>> path, or
>>>>>>> on a separate one (let's call it "NetworkCanvas", for instance)? In
>>>>>>> the second case I will need to make two calls to dump/restore
>>>>>>> methods
>>>>>>> (one within the network -as right now-, and the other within the
>>>>>>> canvas), but that keeps the data separated and doesn't need to
>>>>>>> transfer any new data to the network.
>>>>>>>
>>>>>>> Is my question clear enough? What do you prefer?
>>>>>>>
>>>>>> It makes sense to me but I'm not sure about the details -- specially
>>>>>> who and how to close the xml doc if we have two dump calls?
>>>>>> One possible solution that comes to my mind is adding a new string
>>>>>> argument to the Dump mothod (or function, don't remember)
>>>>>> containing an
>>>>>> "extra root" with the positions and sizes.
>>>>>>
>>>>>> However, this is 2) and, IMO, 1) should be done before.
>>>>>>
>>>>> Sorry to insist.... but thinking about it, I'm wondering how to reuse
>>>>> the code to save selections without get the same problem of
>>>>> positions.
>>>>> The selections are attributes of ProcessingBoxes, just like
>>>>> positions!
>>>>> So, I can pass the list of selected processings to the Network, but I
>>>>> think doing that is maybe more weired than just start doing the
>>>>> integration in a higher level, in ClamNetworkCanvas, deriving it from
>>>>> Components, redefining StoreOn and LoadFrom, and make the
>>>>> ProcessingBoxes correspondents definition adaptions...
>>>>>
>>>> Well yes I see it's not an easy problem.
>>>> The main problem I see implementing Store and Load methods in
>>>> NetworkCanvas is that will duplicate the code in Network::StoreOn.
>>>> And we need this functinality in Network for the NE-less use cases.
>>>> What about adding optional decorations (in the design pattern
>>>> sense) in
>>>> the Processing in the network containing the Canvas data: position,
>>>> size, isSelected (so that you can store only the selected
>>>> processings in
>>>> a given string).
>>>>
>>> I think that the decorator already exists: it is the
>>> ProcessingDefinitionAdapter it is a matter of adding the position
>>> information besides the name.
>>>
>>>
>>>> Then when the Canvas store would consist on first pushing the
>>>> canvas-related data into the network and then call the normal Store
>>>> (or
>>>> Dump). And similarly for Loading.
>>>>
>>>> However at this point I'd like to have David's input, he is the expert
>>>> on NE user-interface.
>>>>
>>> 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.
>>>
>>
>> I agree with the approach.
>> Now let's see if Natanel can defeat the evil details :-)
>> As David says, let's first address the selections part, since this will
>> define the PBox-Canvas-Network communication while maintaining the
>> changeset small.
>>
>> P
>>
>>
>>
>>
>> _______________________________________________
>> Clam-devel mailing list
>> Clam-devel at llistes.projectes.lafarga.org
>> https://llistes.projectes.lafarga.org/cgi-bin/mailman/listinfo/clam-devel
>>
>>
>>
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: CopyAndPasteProcessingsFromCanvas.patch
Type: text/x-patch
Size: 12424 bytes
Desc: not available
URL: <http://lists.clam-project.org/pipermail/clam-devel-clam-project.org/attachments/20080607/31e78585/attachment-0004.bin>
More information about the clam-devel
mailing list