[Cuis-dev] Pluggable Windows experiment (was: Embedded Squeak/Cuis)

Mariano Montone marianomontone at gmail.com
Fri Sep 4 17:24:25 PDT 2020


Hello.

I decided to try a quick experiment of pluggable windows.

So, changed all SystemWindow subclasses to subclass from a "window less"
morph, WindowAreaMorph.

And implemented a PluggableWindowMorph.

This is a very simple experiment, but could be worth exploring, I don't
know.

I think having tools not being windows has potential for things like:

* Inlining code tools, like say, inline an object inspector in some
fancy Smalltalk code editor or REPL.
* Create new tools with panels, like for example, a panel with an
inspector, etc.
* Easily combine tools.

You can try my experiment here:
https://github.com/mmontone/Cuis-Smalltalk-Dev/releases/tag/0.0.1

Cheers!

Mariano


El 4/9/20 a las 12:04, Douglas Brebner via Cuis-dev escribió:
> On 04/09/2020 15:53, Mariano Montone via Cuis-dev wrote:
>> El 4/9/20 a las 09:28, Douglas Brebner via Cuis-dev escribió:
>>> On another note, why SystemWindows? Shouldn't this be handled by a
>>> Morph? (Which may, in turn, be in a SystemWindow.)
>>>
>>>
>>> SystemWindows have been bugging me for a while and I just realised why.
>>> They can't really be composed with other Morphs.
>>>
>> I'm of the same opinion. I've found myself being incapable of reusing or
>> embedding some morph because it was implemented as a SystemWindow
>> (subclass). In my opinion, a better design would be to implement every
>> morph as one that can stand on its own without a window, and then have
>> SystemWindowMorph as a pluggable morph. Like: (SystemWindow on: myMorph)
>> openInWorld.
> 
> 
> Yes, something like this :)
> 
> 
> IIRC (and I may be very wrong), back in the Squeak Central days,
> PasteUpMorphs were used a lot for new creations (Fabrik, BookMorph)
> while SystemWindows were mostly used for MVC ports. Might it be worth
> looking into that approach again?
> 
> 



More information about the Cuis-dev mailing list