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

Juan Vuletich (mail lists) juanlists at jvuletich.org
Sun Apr 28 18:52:57 EDT 2013

Quoting Matthias Springer <me at matthiasspringer.de>:

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

The difference doesn't really matter, but I'd rather say that Morphic  
3 is the morphs + rendering engine, and that the Morphic variant is  
Cuis is called Morphic 3.

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

The idea of local coordinates is to make them local to the owner. For  
instance, if you add a button at 10 at 20 pixels from the topLeft corner  
of the window, and you later move the window to some position, the  
position ivar of the button doesn't change: the button is still 10 at 20  
pixels from the topLeft of the window.

With global coordinates, when moving the window around you need to  
also adjust the position ivar of every submorph down the tree. Inspect  
and browse a bit Cuis and Squeak/Pharo to see the difference.

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

It is fast enough, as hundreds of multiplayer web based javascript games show.

In any case, it's your call. Turning Amber into a full Morphic  
environment is a great project too.

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

Yes. You'll also need to grab mouse / keyboard events from the user  
and feed them to the morphs, but you already knew that. You also need  
to handle screen damage to be repaired on the next cycle.

> 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

Juan Vuletich

More information about the Esug-list mailing list