Playing Flash movies in-image

> Bert Freudenberg wrote:
>> On 17.01.2011, at 17:32, Juan Vuletich wrote:
>>
>>  
>>> Bert Freudenberg wrote:
>>>    
>>>> On 30.12.2010, at 18:31, John M McIntosh wrote:
>>>>
>>>>      
>>>>> Since you are in there, and dragging the FFI stuff about you might consider grabbing the clipboard stuff
>>>>> so that we can copy/paste graphics on windows/mac to/from squeak? I took a run at it a year back but I'm afraid the Windows community just couldn't care less so I couldn't get any testers or confirmation  that it worked there. Today I'd suggest we just abandon them and let them sort it out later.        
>>
>>  
>>>>> I put the image & changes at ftp://ftp.smalltalkconsulting.com/experimental
>>>>>
>>>>> pharo.extendedClipboard.2.zip
>>>>>
>>>>>
>>>>> For image read/writing it uses  SophieImageReadWriter which uses Quicktime's api to translate any supported media types into bitmaps. If that fails or is not available it just like SophieMovie grinds down a decsion tree to find a supported Squeak plugin or smalltalk code to decode the supplied mime-type.
>>>>> PS ya, I see currentMIMETypes := SophieBookEditor clipboardMimeTypes.  but SophieBookEditor is not there and ExtendedClipboardMacInterface>>copyImageDataFromClipboard   but is that used? or did I replace it with ExternalClipboard
>>>>>          
>>>> We use the extended clipboard plugin in Etoys. Copying/pasting bitmaps or rich text between apps works nicely (on Mac and Unix anyway, Windows remains to be implemented).
>>>>
>>>> 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 -
>>>>      
>>> Hi Bert,
>>>
>>> I installed Etoys 4.1 on my Mac mini with Mac OS X 10.5.8. I was neither able to copy nor paste RTF from to Etoys. I tried both with AbiWord and TextEdit, and all I get is a String (without font styles, alignment or color). I also tried to paste a graphic (created with the Grab app) and I also failed (I get the previous String clipboard).
>>>
>>> In the first case, ExtendedClipboardInterface current readAvailableFormats answered an OrderedCollection(text/rtf text/utf8-unicode text/plain text/unicode), in the second case it answered an OrderedCollection(image/tiff).
>>>
>>> Besides, #readRTFClipboardData and #readTIFFClipboardData have no senders.
>>>
>>> What am I doing wrong?
>>>
>>> Thanks,
>>> Juan Vuletich
>>>    
>>
>> Ah, I misremembered. Neither RTF nor TIFF reading is implemented. On Unix we get text/html as rich-text format, and that works. Now I remember something about a RichText Squeak reader somewhere, but can't place it ...
>>
>> Bitmap pasting works only if the format is PNG or JPG, which a lot of apps produce, but not all, apparently. For screenshots I use shift-control-command-4 which puts a PNG into the clipboard and that can be pasted fine.
>>
>> HTH,
>>
>> - Bert
>
> Everything makes sense now. Thank you.
>
> It seems that Grab, Preview, Safari, Firefox and Chrome export only TIFF to clipboard. I'm working on that. I hope to have news soon.
>
> Cheers,
> Juan Vuletich

>  
>>> Ah, I misremembered. Neither RTF nor TIFF reading is implemented. On Unix we get text/html as rich-text format, and that works. Now I remember something about a RichText Squeak reader somewhere, but can't place it ...
>>>
>>> Bitmap pasting works only if the format is PNG or JPG, which a lot of apps produce, but not all, apparently. For screenshots I use shift-control-command-4 which puts a PNG into the clipboard and that can be pasted fine.
>>>
>>> HTH,
>>>
>>> - Bert
>>>      
>> Everything makes sense now. Thank you.
>>
>> It seems that Grab, Preview, Safari, Firefox and Chrome export only TIFF to clipboard. I'm working on that. I hope to have news soon.
>>
>> Cheers,
>> Juan Vuletich
>>    
>
> Great! However, Safari works fine for me. E.g. I go to
>
> http://squeakland.org/showcase/
>
> then right-click on the girl holding the star, choose "Copy Image", switch to Etoys, Cmd-V, and get the image pasted fine ...
>
> Possibly I changed the default format on my Mac at some point in the distant past? Hmm. But others are reporting it works for them ...
>
> - Bert -
>  

> Bert Freudenberg wrote:
>>  
>>>> Ah, I misremembered. Neither RTF nor TIFF reading is implemented. On Unix we get text/html as rich-text format, and that works. Now I remember something about a RichText Squeak reader somewhere, but can't place it ...
>>>>
>>>> Bitmap pasting works only if the format is PNG or JPG, which a lot of apps produce, but not all, apparently. For screenshots I use shift-control-command-4 which puts a PNG into the clipboard and that can be pasted fine.
>>>>
>>>> HTH,
>>>>
>>>> - Bert      
>>> Everything makes sense now. Thank you.
>>>
>>> It seems that Grab, Preview, Safari, Firefox and Chrome export only TIFF to clipboard. I'm working on that. I hope to have news soon.
>>>
>>> Cheers,
>>> Juan Vuletich
>>>    
>>
>> Great! However, Safari works fine for me. E.g. I go to
>>
>> http://squeakland.org/showcase/
>>
>> then right-click on the girl holding the star, choose "Copy Image", switch to Etoys, Cmd-V, and get the image pasted fine ...
>>
>> Possibly I changed the default format on my Mac at some point in the distant past? Hmm. But others are reporting it works for them ...
>>
>> - Bert -
>>  
>
> Not here. I get TIFF. Googled a bit, searched into preferences, could not find a way to modify that. It could be a Safari issue, or most likely an OS X issue, as the same happens to me in Firefox and Chrome. FWIW, I'm using Safari 5.0.3 (5533.19.4) on OS X 10.5.8.

>
> On 17.01.2011, at 20:18, Juan Vuletich wrote:
>
>> Bert Freudenberg wrote:
>>>
>>>>> Ah, I misremembered. Neither RTF nor TIFF reading is implemented. On Unix we get text/html as rich-text format, and that works. Now I remember something about a RichText Squeak reader somewhere, but can't place it ...
>>>>>
>>>>> Bitmap pasting works only if the format is PNG or JPG, which a lot of apps produce, but not all, apparently. For screenshots I use shift-control-command-4 which puts a PNG into the clipboard and that can be pasted fine.
>>>>>
>>>>> HTH,
>>>>>
>>>>> - Bert      
>>>> Everything makes sense now. Thank you.
>>>>
>>>> It seems that Grab, Preview, Safari, Firefox and Chrome export only TIFF to clipboard. I'm working on that. I hope to have news soon.
>>>>
>>>> Cheers,
>>>> Juan Vuletich
>>>>
>>>
>>> Great! However, Safari works fine for me. E.g. I go to
>>>
>>>    http://squeakland.org/showcase/
>>>
>>> then right-click on the girl holding the star, choose "Copy Image", switch to Etoys, Cmd-V, and get the image pasted fine ...
>>>
>>> Possibly I changed the default format on my Mac at some point in the distant past? Hmm. But others are reporting it works for them ...
>>>
>>> - Bert -
>>>
>>
>> Not here. I get TIFF. Googled a bit, searched into preferences, could not find a way to modify that. It could be a Safari issue, or most likely an OS X issue, as the same happens to me in Firefox and Chrome. FWIW, I'm using Safari 5.0.3 (5533.19.4) on OS X 10.5.8.
>
> I'm on Snow Leopard (OS X 10.6.6) and there the format is PNG.
>
>> Anyway, the TIFF reader is working here and solves the issue for good. Now I just need to get permission to publish it.
>>
>> Cheers,
>> Juan Vuletich
>
> Great! :)
>
> - Bert -
>
>
>

> Ah, yeah that probably explains it. Apple moved to PNG for a number of things in 10.6.
>
> On Jan 17, 2011, at 11:46 AM, Bert Freudenberg <[hidden email]> wrote:
>
>>
>> On 17.01.2011, at 20:18, Juan Vuletich wrote:
>>
>>> Bert Freudenberg wrote:
>>>>
>>>>>> Ah, I misremembered. Neither RTF nor TIFF reading is implemented. On Unix we get text/html as rich-text format, and that works. Now I remember something about a RichText Squeak reader somewhere, but can't place it ...
>>>>>>
>>>>>> Bitmap pasting works only if the format is PNG or JPG, which a lot of apps produce, but not all, apparently. For screenshots I use shift-control-command-4 which puts a PNG into the clipboard and that can be pasted fine.
>>>>>>
>>>>>> HTH,
>>>>>>
>>>>>> - Bert      
>>>>> Everything makes sense now. Thank you.
>>>>>
>>>>> It seems that Grab, Preview, Safari, Firefox and Chrome export only TIFF to clipboard. I'm working on that. I hope to have news soon.
>>>>>
>>>>> Cheers,
>>>>> Juan Vuletich
>>>>>
>>>>
>>>> Great! However, Safari works fine for me. E.g. I go to
>>>>
>>>>   http://squeakland.org/showcase/
>>>>
>>>> then right-click on the girl holding the star, choose "Copy Image", switch to Etoys, Cmd-V, and get the image pasted fine ...
>>>>
>>>> Possibly I changed the default format on my Mac at some point in the distant past? Hmm. But others are reporting it works for them ...
>>>>
>>>> - Bert -
>>>>
>>>
>>> Not here. I get TIFF. Googled a bit, searched into preferences, could not find a way to modify that. It could be a Safari issue, or most likely an OS X issue, as the same happens to me in Firefox and Chrome. FWIW, I'm using Safari 5.0.3 (5533.19.4) on OS X 10.5.8.
>>
>> I'm on Snow Leopard (OS X 10.6.6) and there the format is PNG.
>>
>>> Anyway, the TIFF reader is working here and solves the issue for good. Now I just need to get permission to publish it.
>>>
>>> Cheers,
>>> Juan Vuletich
>>
>> Great! :)
>>
>> - Bert -
>>
>>
>>
>

> Hi,
>
>  
>>> Possibly I changed the default format on my Mac at some point in the distant past? Hmm. But others are reporting it works for them ...
>>>
>>> - Bert -
>>>  
>>>      
>> Not here. I get TIFF. Googled a bit, searched into preferences, could not find a way to modify that. It could be a Safari issue, or most likely an OS X issue, as the same happens to me in Firefox and Chrome. FWIW, I'm using Safari 5.0.3 (5533.19.4) on OS X 10.5.8.
>>    
>
>
> FWIW, OS X _has_ such a preference. The default seems to be PNG on OS 10.6 (and 10.5, iirc)
> (see: http://www.switchingtomac.com/tutorials/how-to-change-the-screenshot-file-format-in-os-x/
>  and http://secrets.blacktree.com/edit?id=2233 for possible formats)
>
> So Long,
> -Tobias
>  

> 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'. If the object to be stored in the clipboard is not supported by the OS clipboard, then store and id. The id is a string that includes the class name and hash. So, the method to read the clipboard becomes:
>
> Clipboard >> retrieveObject
>   "Answer whatever was last stored in the clipboard"
>   | stringOrNil |
>   "If the OS clipboard has the id for our contents, or the same characters, then answer the richer Smalltalk object."
>   stringOrNil := self retrieveStringFromOS.
>   stringOrNil = (self stringOrIdFor: contents)
>       ifTrue: [ ^contents ].
>
>   "If we have the ExtendedClipboardInterface, try to get an RTF or Form"
>   Smalltalk at: #ExtendedClipboardInterface ifPresent: [ :clipboardInterface |
>       clipboardInterface current retrieveText ifNotNil: [ :text | ^text ].
>       clipboardInterface current retrieveForm ifNotNil: [ :form | ^form ]].
>
>   "Otherwise answer the string brought by ExtendedClipboardInterface or by clipboard primitives"
>   ^stringOrNil
>
> And you get whatever was last copied into the clipboard, regardless of being copied from Squeak or from other application, without losing the ability to store Smalltalk objects in the Squeak clipboard.
>
> (RTF support is not yet done)
>
> Cheers,
> Juan Vuletich

> 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'. If the object to be stored in the clipboard is not supported by the OS clipboard, then store and id. The id is a string that includes the class name and hash. So, the method to read the clipboard becomes:
>>
>> Clipboard >> retrieveObject
>>   "Answer whatever was last stored in the clipboard"
>>   | stringOrNil |
>>   "If the OS clipboard has the id for our contents, or the same characters, then answer the richer Smalltalk object."
>>   stringOrNil := self retrieveStringFromOS.
>>   stringOrNil = (self stringOrIdFor: contents)
>>       ifTrue: [ ^contents ].
>>
>>   "If we have the ExtendedClipboardInterface, try to get an RTF or Form"
>>   Smalltalk at: #ExtendedClipboardInterface ifPresent: [ :clipboardInterface |
>>       clipboardInterface current retrieveText ifNotNil: [ :text | ^text ].
>>       clipboardInterface current retrieveForm ifNotNil: [ :form | ^form ]].
>>
>>   "Otherwise answer the string brought by ExtendedClipboardInterface or by clipboard primitives"
>>   ^stringOrNil
>>
>> And you get whatever was last copied into the clipboard, regardless of being copied from Squeak or from other application, without losing the ability to store Smalltalk objects in the Squeak clipboard.
>>
>> (RTF support is not yet done)
>>
>> Cheers,
>> Juan Vuletich
>>    
>
> This is better than our current solution but not perfect yet. E.g. when copying a morph we put a bitmap in the OS clipboard and the morph in the Morphic clipboard. When pasting, how do we know we should prefer the Morphic clipboard over the OS bitmap? Is it possible to store a text id and a bitmap at the same time?
>
> - Bert -
>  

> 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'. If the object to be stored in
>>> the clipboard is not supported by the OS clipboard, then store and
>>> id. The id is a string that includes the class name and hash. So,
>>> the method to read the clipboard becomes:
>>>
>>> Clipboard >> retrieveObject
>>>   "Answer whatever was last stored in the clipboard"
>>>   | stringOrNil |
>>>   "If the OS clipboard has the id for our contents, or the same
>>> characters, then answer the richer Smalltalk object."
>>>   stringOrNil := self retrieveStringFromOS.
>>>   stringOrNil = (self stringOrIdFor: contents)
>>>       ifTrue: [ ^contents ].
>>>
>>>   "If we have the ExtendedClipboardInterface, try to get an RTF or
>>> Form"
>>>   Smalltalk at: #ExtendedClipboardInterface ifPresent: [
>>> :clipboardInterface |
>>>       clipboardInterface current retrieveText ifNotNil: [ :text |
>>> ^text ].
>>>       clipboardInterface current retrieveForm ifNotNil: [ :form |
>>> ^form ]].
>>>
>>>   "Otherwise answer the string brought by ExtendedClipboardInterface
>>> or by clipboard primitives"
>>>   ^stringOrNil
>>>
>>> And you get whatever was last copied into the clipboard, regardless
>>> of being copied from Squeak or from other application, without
>>> losing the ability to store Smalltalk objects in the Squeak clipboard.
>>>
>>> (RTF support is not yet done)
>>>
>>> Cheers,
>>> Juan Vuletich
>>>    
>>
>> This is better than our current solution but not perfect yet. E.g.
>> when copying a morph we put a bitmap in the OS clipboard and the
>> morph in the Morphic clipboard. When pasting, how do we know we
>> should prefer the Morphic clipboard over the OS bitmap? Is it
>> possible to store a text id and a bitmap at the same time?
>> - Bert -
>>  
>
> Yes, it can be done. That's why you usually send #clearClipboard prior
> to storing suff. I haven't done this yet because I haven't implemented
> copy Morph to OS clipboard.
>
> Cheers,
> Juan Vuletich

> 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

> 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 -