[Cuis-dev] Pluggable Windows experiment

[Juan Vuletich]

Hi Mariano,

Haven't checked what you did yet, but one comment. All SystemWindow have 
a single LayoutMorph in invar layoutMorph, using all the client area of 
the Window. I guess it could make sense to make all the tools subclass 
LayoutMorph instead, and use (for example) a specific BrowserLayoutMorph 
inside a generic SystemWindow, instead of today's specific BrowserWindow 
holding a generic LayoutMorph. No need to add anew class.

(15 minutes later...)

Now I looked at what you did. It looks exactly what I was suggesting. I 
think it could be a nice improvement to the system.

Cheers,

On 9/4/2020 9:24 PM, Mariano Montone via Cuis-dev wrote:
> 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?
>>
>>


-- 
Juan Vuletich
www.cuis-smalltalk.org
https://github.com/Cuis-Smalltalk/Cuis-Smalltalk-Dev
https://github.com/jvuletich
https://www.linkedin.com/in/juan-vuletich-75611b3
@JuanVuletich