Bert Freudenberg wrote:
> On 19.01.2011, at 20:36, Juan Vuletich wrote:
>
>   
>> Juan Vuletich wrote:
>>     
>>> Bert Freudenberg wrote:
>>>       
>>>> On 19.01.2011, at 16:31, Juan Vuletich wrote:
>>>>
>>>>
>>>>         
>>>>> Bert Freudenberg wrote:
>>>>>   
>>>>>           
>>>>>> However, there is one major issue: When pasting, we have not found a way to determine which clipboard should take precedence - Squeak's text clipboard, Morphic's object clipboard, the system's string clipboard, or the extended Text/Bitmap/Etc. clipboard. In Sophie I guess you used the extended clipboard exclusively, but for Squeak it's not quite as clear-cut ...
>>>>>>
>>>>>> - Bert -
>>>>>>       
>>>>>>             
>>>>> I found a solution for this. The trick is to always store something in the OS clipboard when doing 'copy'.
>>>>>           
>> Done. Works great here. Using a new content type 'cuis-id', to be sure apps using clipboard will get real content (i.e. the Form) and not the id. Fallback to using regular primitives if no ExtendedClipboard.
>>
>> Cheers,
>> Juan Vuletich
>>     
>
> Great! :)
>
> Hehe, we could even serialize the Morph and paste it into another running image, with all attached scripts still working ... The code is all there, basically like saving a Morph in a file. And in Etoys we can already send objects to other OLPC machines. 
>
> - Bert -

If you'll pay the price for serialization on 'copy', maybe store just 
the resulting bytes and not a copy of the morph in the internal 
clipboard contents. Then you can recreate a copy of the object by 
deserialization on 'paste' even if local to the image. That would make 
the 'remote paste' less bug-prone and use less memory.

Cheers,
Juan Vuletich