GSoC Project Proposal: Morphic for Amber, Looking for mentor

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
15 messages Options
Reply | Threaded
Open this post in threaded view
|

GSoC Project Proposal: Morphic for Amber, Looking for mentor

matthias.springer
Hi Smalltalkers,

I'm a computer science student studying in Potsdam, Germany, in the 6th
semester (take a look at my profile on the ESUG GSoC website,
http://gsoc2013.esug.org/matthias-springer/biography) and want to
propose a GSoC project. I'm looking for a mentor. I know that it's
already late but I started working on this project just some weeks ago.
Regardless of whether you would be willing to participate as a mentor,
I'd like to know if this project is something you're interested in and
what features are most important for you. I'd like to hear about your
ideas.

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

My proposal is to reimplement parts of the Morphic framework in Amber.
This would have several advantages.
- Existing Squeak/Pharo/... applications that use the Morphic framework
can be ported to Amber easily.
- GUI applications can be developed more easily. For complex GUI
applications running in a browser, people usually use JavaScript
libraries like ExtJS. But I think, when someone decides to use Amber, we
can assume that the this person is also fairly familiar with the Morphic
framework. This makes Amber even more interesting. Furthermore, more
people might decide to use Smalltalk.
- GUI applications can be written entirely in Smalltalk, without
JavaScript.
- We can easily provide advanced programming tools like multiple class
browser windows and OmniBrowser.

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, ...). I think not
all of this can be done in the scope of a GSoC project but providing a
Morphic implementation would be the first step. Having multiple class
browsers and all the other components (inspect, debugger; this already
exists in Amber) in a seperate window (instead of tabs) would already be
great!

I'm currently working on porting a very small part of the Morphic
framework to Amber, in order to get Dale Henrichs' tODE
(https://github.com/dalehenrich/tode) working in Amber. I already
implemented some basic Morph classes like "Morph", "SystemWindow",
"TextMorph" and "SimpleButtonMorph", but only very basic methods that
are needed by tODE (see
https://github.com/matthias-springer/tode-web-amber).

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.
- I use JQuery and JQuery UI intensively for DOM manipulations and
events. JQuery is already integrated in Amber and can be used from
Smalltalk code (but I had to implement some additional helper functions).

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.
- Next weeks: implement Morphic classes in order to get the Squeak/Pharo
applications running (start with an easy one).
- Half-time: basic Morphic functionality should be working. Begin
implementing more advanced Morphic classes for getting a class browser
running. We have to think about whether to port an existing class
browser or to reuse parts of the current Amber class browser (atm, I
don't know if it's even implemented in Smalltalk). When we decide to
port an existing class browser, we have to take into account that Amber
has a different way of manipulating and compiling classes (to JavaScript).

Similar previous work: The Lively Kernel (http://www.lively-kernel.org/)
is an implementation of the Morphic framework in JavaScript (no
Smalltalk). I want to do this in Amber.

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 * [hidden email] * +49-1577-3814255
Student B.Sc. IT-Systems Engineering (Hasso-Plattner-Institut)
Stahnsdorfer Straße 144c, 14482 Potsdam



_______________________________________________
Esug-list mailing list
[hidden email]
http://lists.esug.org/mailman/listinfo/esug-list_lists.esug.org

smime.p7s (5K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: GSoC Project Proposal: Morphic for Amber, Looking for mentor

Janko Mivšek
Hi Matthias,

Very good proposal indeed, specially combined with all proposed project
over Spec - a declarative specification and builder for UI, both desktop
and web. Also in Aida/Web we are looking for further enhancements on
that field and if Morphic way of UI building happens to be the superior
way, we will also adapt it.

I therefore propose that you prepare a project proposal ASAP, following
the template other projects are. Send it to me and I'll add it to our
GSoC site. Other half of your proposal then put into a proposal page
after you express an interest on your own project, being invited, etc.

About mentorship, I can be a second mentor, dealing with all web stuff,
while I don't know much about Morphic. But it seems you are quite
knowledgeable of it already? Nico will certainly help too with Amber stuff.

One recommendation: try to stay independent of any outside JS library as
much as possible. For instance, you don't need jQuery nowadays for DOM
and event management because recent browsers have quite decent support
for that. Even that resulting code can be without jQuery a bit uglier,
you are not dependent of jQuery fate. I know that from my own experience
being trapped once into dependence to a Prototype, predecessor of
jQuery, which is nowadays practically defunct...

Best regards
Janko


Dne 26. 04. 2013 22:25, piše Matthias Springer:

> Hi Smalltalkers,
>
> I'm a computer science student studying in Potsdam, Germany, in the 6th
> semester (take a look at my profile on the ESUG GSoC website,
> http://gsoc2013.esug.org/matthias-springer/biography) and want to
> propose a GSoC project. I'm looking for a mentor. I know that it's
> already late but I started working on this project just some weeks ago.
> Regardless of whether you would be willing to participate as a mentor,
> I'd like to know if this project is something you're interested in and
> what features are most important for you. I'd like to hear about your
> ideas.
>
> 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).
>
> My proposal is to reimplement parts of the Morphic framework in Amber.
> This would have several advantages.
> - Existing Squeak/Pharo/... applications that use the Morphic framework
> can be ported to Amber easily.
> - GUI applications can be developed more easily. For complex GUI
> applications running in a browser, people usually use JavaScript
> libraries like ExtJS. But I think, when someone decides to use Amber, we
> can assume that the this person is also fairly familiar with the Morphic
> framework. This makes Amber even more interesting. Furthermore, more
> people might decide to use Smalltalk.
> - GUI applications can be written entirely in Smalltalk, without
> JavaScript.
> - We can easily provide advanced programming tools like multiple class
> browser windows and OmniBrowser.
>
> 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, ...). I think not
> all of this can be done in the scope of a GSoC project but providing a
> Morphic implementation would be the first step. Having multiple class
> browsers and all the other components (inspect, debugger; this already
> exists in Amber) in a seperate window (instead of tabs) would already be
> great!
>
> I'm currently working on porting a very small part of the Morphic
> framework to Amber, in order to get Dale Henrichs' tODE
> (https://github.com/dalehenrich/tode) working in Amber. I already
> implemented some basic Morph classes like "Morph", "SystemWindow",
> "TextMorph" and "SimpleButtonMorph", but only very basic methods that
> are needed by tODE (see
> https://github.com/matthias-springer/tode-web-amber).
>
> 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.
> - I use JQuery and JQuery UI intensively for DOM manipulations and
> events. JQuery is already integrated in Amber and can be used from
> Smalltalk code (but I had to implement some additional helper functions).
>
> 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.
> - Next weeks: implement Morphic classes in order to get the Squeak/Pharo
> applications running (start with an easy one).
> - Half-time: basic Morphic functionality should be working. Begin
> implementing more advanced Morphic classes for getting a class browser
> running. We have to think about whether to port an existing class
> browser or to reuse parts of the current Amber class browser (atm, I
> don't know if it's even implemented in Smalltalk). When we decide to
> port an existing class browser, we have to take into account that Amber
> has a different way of manipulating and compiling classes (to JavaScript).
>
> Similar previous work: The Lively Kernel (http://www.lively-kernel.org/)
> is an implementation of the Morphic framework in JavaScript (no
> Smalltalk). I want to do this in Amber.
>
> 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


--
Janko Mivšek
Aida/Web
Smalltalk Web Application Server
http://www.aidaweb.si

_______________________________________________
Esug-list mailing list
[hidden email]
http://lists.esug.org/mailman/listinfo/esug-list_lists.esug.org
Reply | Threaded
Open this post in threaded view
|

Re: GSoC Project Proposal: Morphic for Amber, Looking for mentor

Sean P. DeNigris
Administrator
In reply to this post by matthias.springer
Matthias Springer wrote
Regardless of whether you would be willing to participate as a mentor,
I'd like to know if this project is something you're interested in and
what features are most important for you.
This is a /fantastic/ proposal. I am extremely interested in having the ability to write a non-standard Morphic UI and have it show up in a webpage without any extra work. In fact, that would be amazing! I'm also interested in your idea for another important reason... Morphic is a mess!! What would be great is if you focus on the required behavior without copying too much of the implementation details. In this way, hopefully, we could backport your clean implementation into Morphic and benefit from fresh eyes. I would be happy to mentor as I'm more familiar with Morphic than I ever wanted to be ;) But what would be /great/ is if you could hook up with Juan Vuletich and pitch it to him. He did a rewrite of Morphic a while back and would be an invaluable resource. Even if he can consult, it would be a huge help.
Cheers,
Sean
Reply | Threaded
Open this post in threaded view
|

Re: GSoC Project Proposal: Morphic for Amber, Looking for mentor

matthias.springer
Hi Sean,

I'm happy to hear that!

I also took a look at Juan Vuletich's Morphic3 Project
(http://www.jvuletich.org/Morphic3/Morphic3-201006.html). I think he did
not (re)implement Morphic yet but implemented algorithms for
high-quality rendering (e.g. anti-aliasing) so far. But I'll ask him if
he's interested in this project.

Best regards,
Matthias

Am 27.04.2013 16:47, schrieb Sean P. DeNigris:

> Matthias Springer wrote
>> Regardless of whether you would be willing to participate as a mentor,
>> I'd like to know if this project is something you're interested in and
>> what features are most important for you.
> This is a /fantastic/ proposal. I am extremely interested in having the
> ability to write a non-standard Morphic UI and have it show up in a webpage
> without any extra work. In fact, that would be amazing! I'm also interested
> in your idea for another important reason... Morphic is a mess!! What would
> be great is if you focus on the required behavior without copying too much
> of the implementation details. In this way, hopefully, we could backport
> your clean implementation into Morphic and benefit from fresh eyes. I would
> be happy to mentor as I'm more familiar with Morphic than I ever wanted to
> be ;) But what would be /great/ is if you could hook up with Juan Vuletich
> and pitch it to him. He did a rewrite of Morphic a while back and would be
> an invaluable resource. Even if he can consult, it would be a huge help.
>
>
>
> -----
> Cheers,
> Sean
> --
> View this message in context: http://forum.world.st/GSoC-Project-Proposal-Morphic-for-Amber-Looking-for-mentor-tp4683856p4683986.html
> Sent from the ESUG mailing list archive at Nabble.com.
>
> _______________________________________________
> Esug-list mailing list
> [hidden email]
> http://lists.esug.org/mailman/listinfo/esug-list_lists.esug.org

--
Matthias Springer * [hidden email] * +49-1577-3814255
Student B.Sc. IT-Systems Engineering (Hasso-Plattner-Institut)
Stahnsdorfer Straße 144c, 14482 Potsdam



_______________________________________________
Esug-list mailing list
[hidden email]
http://lists.esug.org/mailman/listinfo/esug-list_lists.esug.org

smime.p7s (5K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: GSoC Project Proposal: Morphic for Amber, Looking for mentor

Bert Freudenberg
In reply to this post by Sean P. DeNigris
On 2013-04-27, at 16:47, "Sean P. DeNigris" <[hidden email]> wrote:

> Matthias Springer wrote
>> Regardless of whether you would be willing to participate as a mentor,
>> I'd like to know if this project is something you're interested in and
>> what features are most important for you.

Great proposal indeed!

I see you mention Lively Kernel as "related". There is also Jens Mönig's Morphic implementation:

        http://www.chirp.scratchr.org/blog/?p=34

which is used in Snap (a Scratch variant):

        http://snap.berkeley.edu/snapsource/snap.html

And big kudos to Sean for volunteering to mentor!

- Bert -

> This is a /fantastic/ proposal. I am extremely interested in having the
> ability to write a non-standard Morphic UI and have it show up in a webpage
> without any extra work. In fact, that would be amazing! I'm also interested
> in your idea for another important reason... Morphic is a mess!! What would
> be great is if you focus on the required behavior without copying too much
> of the implementation details. In this way, hopefully, we could backport
> your clean implementation into Morphic and benefit from fresh eyes. I would
> be happy to mentor as I'm more familiar with Morphic than I ever wanted to
> be ;) But what would be /great/ is if you could hook up with Juan Vuletich
> and pitch it to him. He did a rewrite of Morphic a while back and would be
> an invaluable resource. Even if he can consult, it would be a huge help.
>
>
>
> -----
> Cheers,
> Sean
> --



_______________________________________________
Esug-list mailing list
[hidden email]
http://lists.esug.org/mailman/listinfo/esug-list_lists.esug.org
Reply | Threaded
Open this post in threaded view
|

Re: GSoC Project Proposal: Morphic for Amber, Looking for mentor

J. Vuletich (mail lists)
In reply to this post by matthias.springer
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 <[hidden email]>:

> 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 * [hidden email] * +49-1577-3814255
> Student B.Sc. IT-Systems Engineering (Hasso-Plattner-Institut)
> Stahnsdorfer Straße 144c, 14482 Potsdam
>
>
>

Cheers,
Juan Vuletich


_______________________________________________
Esug-list mailing list
[hidden email]
http://lists.esug.org/mailman/listinfo/esug-list_lists.esug.org
Reply | Threaded
Open this post in threaded view
|

Re: GSoC Project Proposal: Morphic for Amber, Looking for mentor

J. Vuletich (mail lists)
In reply to this post by Sean P. DeNigris
Hi Sean,

Quoting "Sean P. DeNigris" <[hidden email]>:

> Matthias Springer wrote
>> Regardless of whether you would be willing to participate as a mentor,
>> I'd like to know if this project is something you're interested in and
>> what features are most important for you.
>
> This is a /fantastic/ proposal. I am extremely interested in having the
> ability to write a non-standard Morphic UI and have it show up in a webpage
> without any extra work.

Please see my response to Matthias' original message. The possibility  
of writing non-standard Morphic UIs and running them in Amber would  
depend on the approach taken. I don't see it possible if doing it in  
html. Something closer to morphic.js and Lively Kernel would be needed.

Besides, the best (and esiest) way to do what you want is what I  
suggest to Matthias: Use a Smalltalk Morphic server (better yet if it  
is Cuis / Morphic 3), and a remote Amber morphic canvas. Something  
like a Morphic specific VNC client done in Amber + Canvas.

> In fact, that would be amazing! I'm also interested
> in your idea for another important reason... Morphic is a mess!! What would
> be great is if you focus on the required behavior without copying too much
> of the implementation details. In this way, hopefully, we could backport
> your clean implementation into Morphic and benefit from fresh eyes. I would
> be happy to mentor as I'm more familiar with Morphic than I ever wanted to
> be ;) But what would be /great/ is if you could hook up with Juan Vuletich
> and pitch it to him. He did a rewrite of Morphic a while back and would be
> an invaluable resource. Even if he can consult, it would be a huge help.

I'd be really happy to help. To what extent I can do it depends on the  
chosen path. The closer Matthias goes to my preferred path, the more I  
can help :)

> -----
> Cheers,
> Sean
> --
> View this message in context:  
> http://forum.world.st/GSoC-Project-Proposal-Morphic-for-Amber-Looking-for-mentor-tp4683856p4683986.html
> Sent from the ESUG mailing list archive at Nabble.com.
>
> _______________________________________________
> Esug-list mailing list
> [hidden email]
> http://lists.esug.org/mailman/listinfo/esug-list_lists.esug.org
>


Cheers,
Juan Vuletich


_______________________________________________
Esug-list mailing list
[hidden email]
http://lists.esug.org/mailman/listinfo/esug-list_lists.esug.org
Reply | Threaded
Open this post in threaded view
|

Re: GSoC Project Proposal: Morphic for Amber, Looking for mentor

matthias.springer
In reply to this post by J. Vuletich (mail lists)
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@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 * [hidden email] * +49-1577-3814255
Student B.Sc. IT-Systems Engineering (Hasso-Plattner-Institut)
Stahnsdorfer Straße 144c, 14482 Potsdam



_______________________________________________
Esug-list mailing list
[hidden email]
http://lists.esug.org/mailman/listinfo/esug-list_lists.esug.org

smime.p7s (5K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: GSoC Project Proposal: Morphic for Amber, Looking for mentor

Igor Stasenko
On 28 April 2013 16:50, Matthias Springer <[hidden email]> 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@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 * [hidden email] * +49-1577-3814255
> Student B.Sc. IT-Systems Engineering (Hasso-Plattner-Institut)
> Stahnsdorfer Straße 144c, 14482 Potsdam
>
>
>
> _______________________________________________
> Esug-list mailing list
> [hidden email]
> http://lists.esug.org/mailman/listinfo/esug-list_lists.esug.org
>



--
Best regards,
Igor Stasenko.

_______________________________________________
Esug-list mailing list
[hidden email]
http://lists.esug.org/mailman/listinfo/esug-list_lists.esug.org
Reply | Threaded
Open this post in threaded view
|

Re: GSoC Project Proposal: Morphic for Amber, Looking for mentor

matthias.springer
>> 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.
>
>
OK, I'm getting the feeling that it's probably best to implement a
proper HTML Canvas rendering engine (Athens) first and build a
Morphic(-like) framework (e.g. the morphs from Cuis) on top of that
afterwards. Having a good architecture is more important to me than
getting results as fast as possible.

--
Matthias Springer * [hidden email] * +49-1577-3814255
Student B.Sc. IT-Systems Engineering (Hasso-Plattner-Institut)
Stahnsdorfer Straße 144c, 14482 Potsdam



_______________________________________________
Esug-list mailing list
[hidden email]
http://lists.esug.org/mailman/listinfo/esug-list_lists.esug.org

smime.p7s (5K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: GSoC Project Proposal: Morphic for Amber, Looking for mentor

J. Vuletich (mail lists)
In reply to this post by matthias.springer
Quoting Matthias Springer <[hidden email]>:

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

Good.

>> 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@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@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@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 * [hidden email] * +49-1577-3814255
> Student B.Sc. IT-Systems Engineering (Hasso-Plattner-Institut)
> Stahnsdorfer Straße 144c, 14482 Potsdam

Cheers,
Juan Vuletich


_______________________________________________
Esug-list mailing list
[hidden email]
http://lists.esug.org/mailman/listinfo/esug-list_lists.esug.org
Reply | Threaded
Open this post in threaded view
|

Re: GSoC Project Proposal: Morphic for Amber, Looking for mentor

J. Vuletich (mail lists)
In reply to this post by matthias.springer
Quoting Matthias Springer <[hidden email]>:

> OK, I'm getting the feeling that it's probably best to implement a  
> proper HTML Canvas rendering engine (Athens) first and build a  
> Morphic(-like) framework (e.g. the morphs from Cuis) on top of that  
> afterwards. Having a good architecture is more important to me than  
> getting results as fast as possible.

It doesn't really matter. Given that you are using HTML Canvas for  
drawing, the only thing you take from Athens or Morphic 3 is the api.  
And both are based on SVG, so they are essentially equivalent.

As the rendering api is really close to the Canvas backend, it is  
rather easy to do. The interesting part of the project is to make a  
working Morphic world on top of that.

> --
> Matthias Springer * [hidden email] * +49-1577-3814255
> Student B.Sc. IT-Systems Engineering (Hasso-Plattner-Institut)
> Stahnsdorfer Straße 144c, 14482 Potsdam

Cheers,
Juan Vuletich


_______________________________________________
Esug-list mailing list
[hidden email]
http://lists.esug.org/mailman/listinfo/esug-list_lists.esug.org
Reply | Threaded
Open this post in threaded view
|

Re: GSoC Project Proposal: Morphic for Amber, Looking for mentor

matthias.springer
In reply to this post by matthias.springer
Hi,

I decided to write a proposal for both the Athens HTML5 Canvas project
and the Morphic for Amber project. The Athens project will be my primary
(favorite) project and in case it does not get accepted by Google
hopefully the Morphic project does. Does that make sense? Is there a way
to prioritize the Athens proposal?

Juan, would you like to be the primary mentor for the Morphic project?

Either way, I plan to do the Morphic project now or after the GSoC
(built on top of Athens). Thanks for your ideas and comments!

Best regards,
Matthias

--
Matthias Springer * [hidden email] * +49-1577-3814255
Student B.Sc. IT-Systems Engineering (Hasso-Plattner-Institut)
Stahnsdorfer Straße 144c, 14482 Potsdam



_______________________________________________
Esug-list mailing list
[hidden email]
http://lists.esug.org/mailman/listinfo/esug-list_lists.esug.org

smime.p7s (5K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: GSoC Project Proposal: Morphic for Amber, Looking for mentor

Igor Stasenko


On 29 April 2013 23:30, Matthias Springer <[hidden email]> wrote:
Hi,

I decided to write a proposal for both the Athens HTML5 Canvas project and the Morphic for Amber project. The Athens project will be my primary (favorite) project and in case it does not get accepted by Google hopefully the Morphic project does. Does that make sense? Is there a way to prioritize the Athens proposal?

Everything comes at cost, if Athens will be selected, that will mean some other project will not.

 
Juan, would you like to be the primary mentor for the Morphic project?

Either way, I plan to do the Morphic project now or after the GSoC (built on top of Athens).

What a spirit! :)
 
Thanks for your ideas and comments!

 

Best regards,
Matthias

--
Matthias Springer * [hidden email] * <a href="tel:%2B49-1577-3814255" value="+4915773814255" target="_blank">+49-1577-3814255
Student B.Sc. IT-Systems Engineering (Hasso-Plattner-Institut)
Stahnsdorfer Straße 144c, 14482 Potsdam



_______________________________________________
Esug-list mailing list
[hidden email]
http://lists.esug.org/mailman/listinfo/esug-list_lists.esug.org




--
Best regards,
Igor Stasenko.
_______________________________________________
Esug-list mailing list
[hidden email]
http://lists.esug.org/mailman/listinfo/esug-list_lists.esug.org
Reply | Threaded
Open this post in threaded view
|

Re: GSoC Project Proposal: Morphic for Amber, Looking for mentor

J. Vuletich (mail lists)
In reply to this post by matthias.springer
Hi,

Quoting Matthias Springer <[hidden email]>:

> Hi,
>
> I decided to write a proposal for both the Athens HTML5 Canvas  
> project and the Morphic for Amber project. The Athens project will  
> be my primary (favorite) project and in case it does not get  
> accepted by Google hopefully the Morphic project does. Does that  
> make sense? Is there a way to prioritize the Athens proposal?
>
> Juan, would you like to be the primary mentor for the Morphic project?

Sure.

> Either way, I plan to do the Morphic project now or after the GSoC  
> (built on top of Athens). Thanks for your ideas and comments!
>
> Best regards,
> Matthias
>
> --
> Matthias Springer * [hidden email] * +49-1577-3814255
> Student B.Sc. IT-Systems Engineering (Hasso-Plattner-Institut)
> Stahnsdorfer Straße 144c, 14482 Potsdam

Cheers,
Juan Vuletich


_______________________________________________
Esug-list mailing list
[hidden email]
http://lists.esug.org/mailman/listinfo/esug-list_lists.esug.org