[squeak-dev] We need to talk about graphics

Thiede, Christoph Christoph.Thiede at student.hpi.uni-potsdam.de
Sat Jul 11 18:44:42 UTC 2020


Hi Stephen,


> 1. There’s a reason views and controllers were initially separated; that reason is reusability and better factoring.

Afaik a good equivalent for that separation in Morphic are morph + model. If you are going to develop a sophisticated UI, you can use the ToolBuilder framework, and your tool will be even decoupled from the UI framework.

> 2. The composite design pattern is a good thing (https://en.wikipedia.org/wiki/Composite_pattern) and should be applied to everything where one builds trees, such as view hierarchies.

Morphic uses the composite pattern, too, doesn't it? All morphs are nested in each other, beginning at the root morph (the world), and form a big object tree, just like MVC does. Please correct me if I am wrong.

> 3. In a good OO framework, the more abstract classes generally have the minimum necessary state (or none at all). Class Morph has 7 instance variables.

And class View has 13 instance variables. :-) I agree with you that abstract class should not have any unnecessary state, but in fact, graphics aren't a completely abstract domain. A minimum of geometry information (bounds) is vital for graphic representation, and some node links (submorphs, owner) are vital, too, for navigating through the Morphic tree. Note that Morph even has a cleaned-up state by extracting all non-crucial fields into the extension object.

> 4. The goal of OO design is to reuse specifications across multiple implementations, so why does class Morph rename the usual geometry methods of bounds, extent, width, height, etc. as (e.g.,) morphBounds?

I'm afraid I don't get your point here. My image does not even know the selector #morphBounds. But #extent, #width, and #height, for example, are derived attributes, which means that an implementor only needs to manipulate the single underlying representation, which is bounds, in order to adjust all specified attributes.
Are you desiring something like an abstract morph interface that does not yet define core and derived attributes? It's true that Morph is not an abstract class (Morph new openInWorld works like a charm), but in which practical example would you need this?

> It would be really nice to have a simple MVC (and display-list graphics) framework that could be placed on top of several graphics back-ends including BitBLT, OpenGL and HTML5.

That's an interesting thought! As said above, Morphic is a composite framework, too, so couldn't you start by implementing #printHtmlOn: on Morph, next to #drawOn:? But in practice, I guess your desire would be very hard to achieve because HTML5 is a high-level OO framework while OpenGL operates on a quite low level. HTML5 is kind of a competing object tree against Morphic, so you could either try to keep two trees in sync or rebuild one of the trees periodically, which would be performance-extensive. For OpenGL, couldn't something like an OpenGLCanvas be a starting point?

Best,
Christoph

________________________________
Von: Squeak-dev <squeak-dev-bounces at lists.squeakfoundation.org> im Auftrag von Stephen Pope <stephen at heaveneverywhere.com>
Gesendet: Samstag, 11. Juli 2020 20:02:37
An: The general-purpose Squeak developers list; Discussion of Cuis Smalltalk
Betreff: Re: [squeak-dev] We need to talk about graphics


To put it bluntly: I gave porting old-school MVC to Cuis.

[flame on] Morphic is miserable and really needs to be replaced by MVC, though (IMHO).

Why?

1. There’s a reason views and controllers were initially separated; that reason is reusability and better factoring.

2. The composite design pattern is a good thing (https://en.wikipedia.org/wiki/Composite_pattern) and should be applied to everything where one builds trees, such as view hierarchies. The root view object should not have subviews, the view-composite should. (I know that old-school MVC didn’t do it that way, but new implementations certainly should).

3. In a good OO framework, the more abstract classes generally have the minimum necessary state (or none at all). Class Morph has 7 instance variables.

4. The goal of OO design is to reuse specifications across multiple implementations, so why does class Morph rename the usual geometry methods of bounds, extent, width, height, etc. as (e.g.,) morphBounds?

I could go on… [flame off]

It would be really nice to have a simple MVC (and display-list graphics) framework that could be placed on top of several graphics back-ends including BitBLT, OpenGL and HTML5.

stp


--

                    Stephen Travis Pope   Santa Barbara, California, USA
          http://HeavenEverywhere.com        http://FASTLabInc.com
                       https://vimeo.com/user19434036/videos      http://heaveneverywhere.com/Reflections

--



On Jul 9, 2020, at 11:12 PM, stephen at heaveneverywhere.com<mailto:stephen at heaveneverywhere.com> wrote:


…on a related topic, I’ve started porting old-school MVC* to Cuis with the intention of replacing Morphic with a generic framework that can be back-ended by BitBLT, OpenGL or HTML5.

Anybody want to help?

Stephen

* = starting with traditional MVC classes and system windows, and following that with some version of the “Wrapper” framework as still used in VisualWorks.


--

                    Stephen Travis Pope   Santa Barbara, California, USA
 <pastedGraphic.tiff>         http://HeavenEverywhere.com<http://heaveneverywhere.com/>        http://FASTLabInc.com<http://fastlabinc.com/>
                       https://vimeo.com/user19434036/videos      http://heaveneverywhere.com/Reflections

--



On Jun 28, 2020, at 5:53 PM, tim Rowledge <tim at rowledge.org<mailto:tim at rowledge.org>> wrote:

Seriously. We've been sitting around twiddling thumbs about better graphics for decades now.

We had Balloon2D & 3D.
We had 'Pooh graphics' to do vector forms.
We have some excellent stuff being done by the Cuis crew.
We have some amazing ideas from Nile/Gezira.
We have a number of potential 3rd party graphics libraries we might adopt.
We have an advanced JIT that could be used to make on-demand graphics routines either on their own or working with pretty much any of the above.
We probably have other options I've not even heard of.

Maybe we should actually do something? Can we at least talk about it?

tim
--
tim Rowledge; tim at rowledge.org<mailto:tim at rowledge.org>; http://www.rowledge.org/tim
Strange OpCodes: SVE: Skip on Vernal Equinox





-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20200711/85234304/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pastedGraphic.tiff
Type: image/tiff
Size: 2442 bytes
Desc: pastedGraphic.tiff
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20200711/85234304/attachment.tiff>


More information about the Squeak-dev mailing list