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

Juan Vuletich (mail lists) juanlists at jvuletich.org
Sun Apr 28 09:47:55 EDT 2013


Hi Matthias,

My name is Juan Vuletich, and I lead the development of Cuis Smalltalk  
and Morphic 3. I am happy to see any and all initiatives and efforts  
to advance the Smalltalk world.

Let's see how your project matches with what I'm doing. I'll sketch  
briefly my projects and their state.

Cuis is a fork of Squeak (like Pharo, Etoys, Scratch, Tweak,  
OpenCobalt, OpenQwaq, and others). The main objective that sets Cuis  
apart from other Squeak variants, is to enable and ease evolution as  
the top priority. For this, the strategy is to simplify the code as  
much as possible, so it becomes easier to understand. Right now, in  
lines of code, Cuis is about 1/3 the size of Squeak or Pharo. Cuis MIT  
license, and freely available. It is a pretty mature and solid  
Smalltalk environment, used for several commercial and non-commercial  
projects. I started Cuis to make Morphic 3 possible:

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.

I've been thinking for some time on doing something to enable Cuis  
powered web servers running Morphic applications that are rendered in  
the client web browser. This has indeed some overlap with what you  
want to do. I would be delighted if you could work on this. But this  
is not exactly what you are proposing, so I'll comment inline below  
(please continue reading):

Quoting Matthias Springer <me at matthiasspringer.de>:

> Hi Smalltalkers,
> ...
> Amber is a Smalltalk implementation running in a web browser. It is  
> written in JavaScript. Amber provides some basic Smalltalk classes  
> and methods. It is also possible to render HTML code in a  
> Seaside-like way. But in contrast to Seaside, Amber has the  
> advantage that the whole Smalltalk VM runs inside the browser. Code  
> written in Amber can be automatically filed out to the hard disk  
> (using a NodeJS server running in the background).

Good. Amber looks like the perfect environment to do web-based  
Smalltalk stuff.

> My proposal is to reimplement parts of the Morphic framework in  
> Amber. This would have several advantages.
>
> ...(abridged)...
>
> My vision is to provide a fully-featured Smalltalk programming  
> environment running in the browser that provides all features that  
> are offered by Squeak/Pharo (class browsers, Monticello, ...).  
> ...(abridged)...
>
> Here's some technical stuff about how my current implementation works.
> - All morphs need to be rendered as HTML DOM elements.
> - Morphs are rendered using "HTMLCanvas" and "Widget", both classes  
> are provided by Amber.
> - Morphs are rendered inside a div container, submorphs can be added  
> by adding the submorph's div container to the owner's div container  
> and setting its position and so on.
> - Not all HTML tags can be reused. For instance, the HTML text  
> box/text area does not support text with different text formats  
> (color, emphasis, ...). I had to reimplement text areas for editable  
> "TextMoprh"s with DOM manipulation.

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.

>
> ...(abridged)...
>
> A proposal on how to get started and structure the project.
> - 1st week: think about architecture (how to do the rendering, ...),  
> class structures (e.g. which Morph classes are needed) and choose  
> some existing Squeak/Pharo applications that use an  
> important/representative subset of Morphic.

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

Take a look at  
http://forum.world.st/How-to-code-to-move-a-morph-td3937438.html where  
some experiments with Amber and morphic.js are discussed.

If you follow the gobal coordinates path, compatibility with Squeak  
and Pharo will be easier. If you follow the local coordinates path,  
compatibility with Cuis and Morphic 3 will be easier.

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.

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.

If you do an html based implementation, compatibility with Squeak /  
Pharo would be limited. In this case I could help a bit, but as this  
would go closer to Seaside/Aida/Iliad than to Morphic, my help would  
be limited.

I tried to be objective when comparing options, but let me say now  
that I think the Cuis / Morphic 3 way is the best, and that I want to  
convince you to follow it!

>
> ...(abridged)...
>
> I'm looking for a mentor for the GSoC 2013. Ideally, the mentor has  
> a good understanding of the Morphic framework and maybe even HTML,  
> JavaScript and CSS (but I'm already quite familiar with this).
>
> Best regards,
> Matthias Springer
>
> -- 
> Matthias Springer * me at matthiasspringer.de * +49-1577-3814255
> Student B.Sc. IT-Systems Engineering (Hasso-Plattner-Institut)
> Stahnsdorfer Straße 144c, 14482 Potsdam
>
>
>

Cheers,
Juan Vuletich





More information about the Esug-list mailing list