Hi,
I have been playing with the source code of Sugar last week. So I'm ready to go further. To break a barrier between eToys and another activities, I think it is necessary to make eToys' clipboard work with Sugar clipboard properly. http://wiki.laptop.org/go/OLPC_Human_Interface_Guidelines/The_Laptop_Experie... Currently, only you can copy a string from eToys to others, but apparently that's too inconvenience. So my plan is:
1) Simple string Copy a string between eToys and another activity both way.
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.
4) Formatted text I think it is harder part than others. Using RTF???
5) Drag and drop
I guess most of them can be done just by using X11's clipboard. But if I realize to need dbus, I'll wait for Michael's dbus implementation. And more challenge would be UI issue. For example, we don't have an easy way to copy neither a simple text or a morph. But I could implement internal code without waiting the discussion.
Cheers, - Takashi
On Apr 16, 2007, at 12:10 , Takashi Yamamiya wrote:
Hi,
I have been playing with the source code of Sugar last week. So I'm ready to go further. To break a barrier between eToys and another activities, I think it is necessary to make eToys' clipboard work with Sugar clipboard properly. http://wiki.laptop.org/go/OLPC_Human_Interface_Guidelines/ The_Laptop_Experience/The_Frame#Objects Currently, only you can copy a string from eToys to others, but apparently that's too inconvenience.
I think there is a bug in Sugar's clipboard handling, because we never get an XdndEnter event. Because of this, not even dropping files works correctly in Sugar, whereas it works in normal X desktop.
So my plan is:
- Simple string
Copy a string between eToys and another activity both way.
Should be simple, although we need to take care of character sets. But apparently everyone is settling on utf-8.
Although we need to define the interaction with the image which currently only handles url lists ...
- Graphics image
Copy an image between eToys and another activity both way.
- 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).
- 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)
- Drag and drop
I guess most of them can be done just by using X11's clipboard. But if I realize to need dbus, I'll wait for Michael's dbus implementation.
As far as I know, dbus should not be necessary for clipboard interaction. It will use the X11 clipboard and Xdnd protocols. We still need to extend the VM for this, as currently it allows only dropping files, it rejects everything else.
I know the Sophie developers have implemented this, but only for Mac and Windows using FFI I think. IMHO this would be valuable to have on every platform.
We should discuss this with the other platform developers on the vmdev-list.
And more challenge would be UI issue. For example, we don't have an easy way to copy neither a simple text or a morph. But I could implement internal code without waiting the discussion.
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. 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 ...
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. There are some ideas needed to make this work reasonably - for example, dropping some selected text on a free space should create a new text morph, whereas dropping into some other text should insert it. Also, if the original text becomes empty, we might want to delete the morph in some cases - maybe if it was a direct child of the World, but not if it was the text pane of a browser.
- Bert -
Hi Bert,
- Graphics image
Copy an image between eToys and another activity both way.
- 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...
- 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?
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.
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 prefer to start stupidly simple at first. What about to use X halo for cut, and duplicate halo for copy?
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.
Cheers, - Takashi
On Apr 17, 2007, at 4:35 , Takashi Yamamiya wrote:
Hi Bert,
- Graphics image
Copy an image between eToys and another activity both way.
- 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 ...
- 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 -
Bert,
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.
Wow! That's perfect!
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 think we could remain it if it's just a visual effects issue.
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.
We will use the grab handle to drag to the sugar frame, of course. But X handle is not so strange than it looks. Because X doesn't delete anything, but actually it moves a morph to the trash can, and you can use it later when you want. That's exactly same behavior of "cut" operation. This was Abe-san's Idea, sometimes he uses the trash can as just a clipboard.
Cheers, - Takashi
On Apr 17, 2007, at 15:06 , Takashi Yamamiya wrote:
Bert,
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.
Wow! That's perfect!
I thought so :) You can even drag translucently:
| c | c := CursorWithAlpha fromUser. c copyBits: c boundingBox from: c at: 0@0 colorMap: (ColorMap shifts: #(-1 -1 -1 -1) masks: #(16rFE000000 16rFE0000 16rFE00 16rFE)). c show
And I also just committed a patch so that large cursors work on the Unix Mac VM. So if you get Ian to build a Mac VM from the olpc branch for you, you can experiment with large cursors on your desktop machine.
Ian: cursor support code attached.
Adding this was pretty trivial since the Unix VM uses Cocoa's NSCursor support already. John wrote that he needs to rewrite the Carbon cursor code to Cocoa, which might take a little while.
- Bert -
etoys-dev@lists.squeakfoundation.org