Quoting Matthias Springer <me@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. 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 * me@matthiasspringer.de * +49-1577-3814255 > Student B.Sc. IT-Systems Engineering (Hasso-Plattner-Institut) > Stahnsdorfer Straße 144c, 14482 Potsdam Cheers, Juan Vuletich

Quoting Matthias Springer <me@matthiasspringer.de>: > 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 * me@matthiasspringer.de * +49-1577-3814255 > Student B.Sc. IT-Systems Engineering (Hasso-Plattner-Institut) > Stahnsdorfer Straße 144c, 14482 Potsdam Cheers, Juan Vuletich