We need to talk about graphics
Locked
12
12
Re: We need to talk about graphics
 
|
[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
|
Re: We need to talk about graphics
|
|
Re: We need to talk about graphics
|
|
In reply to this post by Stephen Pope
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 <[hidden email]> im Auftrag von Stephen Pope <[hidden email]>
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 [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
Carpe Squeak!
|
pastedGraphic.tiff (3K)
Re: We need to talk about graphics
|
|
WatchMorph as an example of anti-aliasing going a bit odd (was Re: We need to talk about graphics)
|
|
Playing with stuff; tried a WatchMorph to look at circles drawn by Balloon.
Grabbing one via World->new morph->from alphabetical list produces a decently round clockface with a coloured centre section. However, using the debug menu to turn on the anti-aliasing results in a rather ugly lumpiness, as if it were a fruit that has been poked a bit too often to test for ripeness.   Weird. The B2Dplugin appears to be active and I can make it do profiling etc that makes it pretty certain it is being used. Is this an ARM/Pi issue... nope, looks the same on a Mac system. tim -- tim Rowledge; [hidden email]; http://www.rowledge.org/tim Gotta run, the cat's caught in the printer. |
Proposal for new BitBlt rules (was: We need to talk about graphics)
|
|
Re: We need to talk about graphics
|
|
Re: We need to talk about graphics
|
|
Re: We need to talk about graphics
|
|
Re: We need to talk about graphics
|
In reply to this post by Stephen Pope
Hi Stephen.
Separation of model, view, and maybe controller-like objects is a choice you can still make in your application designed for and written in Morphic. Try exploring and working with the direct-manipulation concepts Morphic has to offer. Those concepts can speed up the feedback cycle, which can then lead to a better architectural design in your application. Many of your thoughts on a "good OO framework" omits the fact that software rather grows -- refactoring being a vital part in its lifecycle. Happy programming! =) Best, Marcel
|
| Free forum by Nabble | Edit this page |