[Esug-list] GSoC Project Proposal: Morphic for Amber, Looking for mentor

Matthias Springer me at matthiasspringer.de
Sun Apr 28 10:50:52 EDT 2013


Hi Juan,

>
> Morphic 3 is a reimplementation of Squeak Morphic with these 
> fundamental changes:
> - Drawing is vector graphics (like HTML5 Canvas and SVG)
> - Each morph defines a local coordinate system
> - Coordinates are float, and not tied to Display coordinates
> - Code is simplified and easier to understand
> The new drawing engine will be published this year (MIT license). The 
> rest of the work is in the Morphs themselves, and is done 
> incrementally in the Cuis project. This means that the latest Cuis 
> default and only GUI is always the most current state of this work. 
> Right now, in Cuis, all morphs are specified in local float 
> coordinates, and the Morphic code is much smaller and easier to 
> understand that in other Squeak variants.
So Morphic3 is the rendering/drawing engine and Cuis provides the morphs 
on top of Morphic3?

>
> If I understand this correctly, this means not using Canvas for 
> drawing graphics (like LivelyKernel and morphic.js do), but using the 
> html rendering in the browser (more like Seaside, Iliad and and Aida). 
> This approach has pros and cons, but to me, it essencially means it is 
> not a real Morphic. A fundamental feature of Morphic is that the look 
> and behavior of morphs is completely done in Smalltalk, and therefore, 
> only limited by what the Display can show. This means not using any 
> external widgets library (like html widgets, or qt, or native OS 
> widgets, etc). In Morphic, it is possible to do stuff like the 
> EnvelopeEditorMorph, and what you see in LivelyKernel and morphic.js. 
> In html, we are limited to what the browsers provide.
I talked with several people about this and I think it is indeed better 
and cleaner to use an HTML canvas for drawing. Putting divs together 
with position:absolute - that's what I'm currently doing - is really 
ugly. My plans for the next days are to experiment with HTML canvas and 
try to shift all rendering to the canvas.
>
> This means that you want the real Morphic power and flexibility. Then 
> the strategy would be to start by making a Morphic World that can host 
> the most basic morphs, maybe not unlike what morphic.js is doing, but 
> in Smalltalk (Amber). If you follow this path, the next question is 
> whether to use global coordinates (like Squeak, Pharo and other 
> derivatives, except Cuis, and like morphic.js) or local coordinates 
> (like LivelyKernel, Self and Cuis).
Sounds like a plan. My initial motivation was to get an existing Pharo 
application running in Amber without changing too much code. But I'd 
also be willing to change that application in order to get a better 
Morphic implementation.

I didn't think about coordinate systems yet. In my current 
implementation the top, left corner of a window is always 0 at 0 regardless 
of where the window is located. That's the idea of local coordinates, right?

> If you consider doing a remote, web based canvas for Cuis / Morphic 3 
> servers, I would be delighted to be your mentor, as your work would be 
> closely related to mine. Besides, I believe this would be the easiest 
> way to enable fully Morphic webapps in Smalltalk.
In my opinion, one of the biggest advantages of Amber is that you don't 
need any particular web server or backend. A web browser is everything 
you need and the whole Smalltalk VM is running in the web browser (it's 
also much easier to set up). I'm also wondering whether remote rendering 
is fast enough. You need to talk to the server on every event (mouse 
click, mouse move (this is really expensive), keyboard, ...) and every 
primitive you render must be sent to the client.
>
> If you do a SVG Morphic for Amber, similar to morphic.js, I could also 
> help. This would mean that a longer term project would be needed to 
> bring it to the point of real compatibility with Squeak / Pharo / Cuis.
This is more or less what I had in mind, probably by drawing morphs onto 
an HTML canvas. Maybe we can share code between Cuis and Amber for the 
actual morphs, once I have implemented the drawing/rendering component. 
It should be sufficient to implement the Morphic3 interface that is used 
by Cuis and I can render all Cuis morphs from then on, right?

Best regards,
Matthias

-- 
Matthias Springer * me at matthiasspringer.de * +49-1577-3814255
Student B.Sc. IT-Systems Engineering (Hasso-Plattner-Institut)
Stahnsdorfer Straße 144c, 14482 Potsdam


-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4471 bytes
Desc: S/MIME Kryptografische Unterschrift
URL: <http://lists.esug.org/pipermail/esug-list_lists.esug.org/attachments/20130428/f731a56b/attachment.p7s>


More information about the Esug-list mailing list