Ha, I was busy with these yesterday.

Worse bit is not the morphExtension or otherProperties stuffed into them, but rather the fact that when one puts a value into #paneColor for example, themes are not respecting that.

The morphExtension rationale is to have lightweight and heavyweight morphs.

It is not easy to balance what should be put into a method or kept into those extra places.

Now try to make a SystemWindow use the selected window color in the little downarrow menu.

You'll get into the morphs creating the sides and having a transparent fillstyle, and override the paneColor thing.

I am glad to have the dark theme. I am sad to not be able to set colors on my system windows easily (Yeah, I like the Play-Doh UI).

Maybe subclassing those Morphs making up SystemWindows would be a good idea so that we can start having a theming for the windows borders and title.��

I want put the TilingWindowManager icons in the SystemWindow title bar. So, I need something more focused than just an aligment morph etc.

So we will be able to plugin a couple interesting features in it.

Phil

On Thu, Nov 3, 2016 at 8:47 PM, stepharo <stepharo@free.fr> wrote:

I would like to be able to compare the **arguments** passed to

setProperty:toValue:

and

the ones of valueOfProperty:, valueOfProperty:ifAbsent:, valueOfProperty:ifAbsentPut:,

and

hasProperty:

I quite sure that we will discover more deadcode in morphic.

Any ideas?

PS: I hope (but I cannot read the code of Bloc because it crashes my vm at startup) that Bloc and Brick will not use such patterns.

There are plague and lead to shitty and crappy code.

Stef