When I drag and drop from the Sugar clipboard into Etoys, I get
consistent segmentation faults.
I am using the x86_64 Fedora 16 distribution of Sugar and Etoys.
(Essentially this is is SoaS pineapple with updates from the Fedora
RPM repository.)
Is it just me? Do you think any of etoys-dev, Fedora or Sugar might
benefit from a bug report?
The image is Etoys 4.1 build 2390. The vm version is:
$ squeak -version
3.10-5 #1 Mon Jun 21 22:10:08 UTC 2010 gcc 4.4.4
Squeak3.10beta of 22 July 2007 [latest update: #7159]
Linux x86-04.phx2.fedoraproject.org 2.6.18-194.3.1.el5 #1 SMP Sun May
2 04:17:42 EDT 2010 x86_64 x86_64 x86_64 GNU/Linux
default plugin location: /usr/lib64/squeak/3.10-5/*.so
Here are a couple of stack dump extracts from org.vpri.EtoysActivity-n.log
Firstly dropping some text (from a web browser):
Segmentation fault
25651976 ExtendedClipboardInterface>readClipboardData:
25651884 ExtendedClipboardUnixInterface>readHTMLClipboardData
25651524 ExtendedClipboardUnixInterface>readTextClipboardData
25651432 Clipboard>clipboardText
25651316 Clipboard class>clipboardText
25651212 ParagraphEditor>clipboardText
25651004 ParagraphEditor>paste
25641572 [] in PluggableTextMorph>paste
25647380 [] in PluggableTextMorph>handleEdit:
25645636 TextMorph>handleEdit:
25641664 PluggableTextMorph>handleEdit:
25641480 PluggableTextMorph>paste
25641296 PluggableTextMorph>dropFiles:
25641192 Morph>handleDropFiles:
25641100 DropFilesEvent>sentTo:
25640904 Morph>handleEvent:
Secondly dropping a photo from the Record activity via the Journal:
Segmentation fault
27104368 JPEGReadWriter2>nextImageSuggestedDepth:
27103820 JPEGReadWriter2>nextImage
27092592 [] in ImageReadWriter class>formFromStream:
27103664 BlockContext>ensure:
27091904 Cursor>showWhile:
27047352 ImageReadWriter class>formFromStream:
27047168 Form class>fromBinaryStream:
27047260 [] in ExternalDropHandler class>defaultImageHandler
27046616 ExternalDropHandler>handle:in:dropEvent:
27046984 [] in PasteUpMorph>dropFiles:
27046524 BlockContext>ensure:
27041148 PasteUpMorph>dropFiles:
David
This is a very poor attempt to do what Matt Fulmer did with OpenCobalt:
integrate overlapping Morphic windows with OpenGL.
The only advantage is that it doesn't require OpenCobalt.
https://www.youtube.com/watch?v=Ctm-Q39nd-k
The entire World is being rendered onto an OpenGL texture which is
updated with every tick. With the proper scaling , the destop could be
repositioned along the z access at any point within the fustrum and
still keep the default mouse handling. Add mouse handling from OpenGL
itself, and you can have 2D widgets projected onto 3D objects, not to
mention 3D widgets fully integrated with the Squeak desktop.
Time to revive/revitalize Balloon3D, perhaps? Whatever happened to 3D
Morphic?
There's obviously a great deal of room for optimization, and of course,
the sky is the limit for what could be done in terms of lighting,
materials, etc.
Using more modern APIs of OpenGL (I'm using immediate mode! (!) and only
stuff from the first 6 NeHe tutorials) one could have an awful lot of
interesting stuff going on.
Lawson
