[Etoys] Clipboard between eToys and Sugar

[Bert Freudenberg]

On Apr 17, 2007, at 4:35 , Takashi Yamamiya wrote:

> Hi Bert,
>
>>> 2) Graphics image
>>> Copy an image between eToys and another activity both way.
>>>
>>> 3) Morph
>>> Copy a morph to another instance of etoy's image through the
>>> clipboard or export as a graphics to another activity.
>> We should handle both of these similarly ... when dragging a morph  
>> into some other activity it might be just an image. We should also  
>> provide strings for morph (working like the copy text halo menu).
>
> I agree. It's simple for user. Actually, I didn't know there is copy
> items in the halo menu. That's too tricky UI...

Oh there's a whole lot of cool stuff in the halo menu that did not  
fit elsewhere ...

>>> 4) Formatted text
>>> I think it is harder part than others. Using RTF???
>> I think it uses the text/richtext MIME standard.
>> Dragging some text from open office into Squeak produces these  
>> formats:
>>   type 0 == 379 text/plain;charset=utf-8
>>   type 1 == 220 UTF8_STRING
>>   type 2 == 397 application/x-openoffice-embed-source- 
>> xml;windows_formatname="Star Embed Source (XML)"
>>   type 3 == 398 application/x-openoffice-objectdescriptor- 
>> xml;windows_formatname="Star Object Descriptor (XML)"
>>   type 4 == 399 text/richtext
>>   type 5 == 400 text/html
>> (I compiled sqUnixXdnd with DEBUG_XDND enabled)
>
> Thank you for the information. I'll take a look deeper. I thought RTF
> just because Sugar's clipboard (right edge of the frame) said "RTF
> File" when I copied in Write activity. Maybe RTF is text/richtext?

text/richtext is a lot simpler, it looks vaguely like HTML actually:

	http://www.w3.org/Protocols/rfc1341/7_1_Text.html

>> We should discuss this with the other platform developers on the  
>> vmdev-list.
>
> Sure.
>
>> That would be great. As I understand, the proper interaction will  
>> be dragging text or objects into the frame. This means the Hand's  
>> contents needs to be visually on top of the frame. The only way to  
>> implement this properly would be to use the new large cursor  
>> support - you can make the cursor be as large as the whole screen.
>
> I didn't quite understand though, You mean that the drag target is
> drawn on out of the squeak image? That's attractive.

What I mean is that the Sugar frame is drawn on top of Squeak, but  
the System Cursor is drawn on top of both. So if you let the System  
cursor display an image of a morph, you can drag it into the frame.  
Try this while running in Sugar with the Sugar frame visible:

	CursorWithAlpha fromUser show

As you can see, you can move stuff from the image over the sugar frame.

>> IIUC the Hand already has its own canvas onto which it renders its
>> submorphs, logically these are on a layer above the world. So the
>> basics are there already. I'm not sure if you want to tackle this or
>> if we need a Morphic guru to do it ...
>
> umm, it seems not to be easy to make for me...

I guess I could tackle it then if there are no other takers ... I  
have an idea how to do that. However, I fear there are many places  
that reference cursors directly, so it may be a bit tricky to make  
work while not breaking things on cursor-challenged VMs. But the  
design of HandMorph lends itself naturally to a separate display  
surface, kudos to whoever came up with that ...

> I prefer to start
> stupidly simple at first. What about to use X halo for cut, and
> duplicate halo for copy?

If you mean the black grab halo handle I'd agree ... X is for  
deleting, and we should keep it at that IMHO.

>> Another issue is the dragging interaction - if there is some  
>> selected text, dragging it should move it around. Dropping into  
>> the frame should be the equivalent of "copy", but dropping it onto  
>> some other place inside squeak should be "cut&paste", that is,  
>> delete it from the original place and append to the target.
>
> Yes. Let's follow Write's convention as well as possible.

Well, only as far as Write matches what the OLPC designers envision ...

- Bert -