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

Igor Stasenko siguctua at gmail.com
Sun Apr 28 10:57:16 EDT 2013

On 28 April 2013 16:50, Matthias Springer <me at matthiasspringer.de> wrote:
> 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.

yes, and in that regard,  http://gsoc2013.esug.org/projects/athens-html5-canvas
is way better alternative.

>> 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
> _______________________________________________
> Esug-list mailing list
> Esug-list at lists.esug.org
> http://lists.esug.org/mailman/listinfo/esug-list_lists.esug.org

Best regards,
Igor Stasenko.

More information about the Esug-list mailing list