Themes

Right now, as mentioned in the Pharo Vision, themes are severely overloaded. They are responsible for describing, building, and opening various UI controls, as well as serving UI requests!

The question is where is the sweet spot between power/flexibility and simplicity. Right now, the process of routing everything back and forth between TEasilyThemed and the themes themselves seems overcomplicated to me.

Doru's suggestion, which he did a test implementation for Spotlight2Morph:

I added a first shot at theming. The idea is simple:

- we have one method in UITheme called spotterThemer that simply returns a SpotterThemer, and

- all Spotter/Spotlight specific rendering methods are in SpotterThemer

 

I think this should be the design to follow for all morphs. I blogged about it in more details here:

http://www.humane-assessment.com/blog/a-pharo-refactoring-story-adding-theme-ability-to-a-morph/

 

In summary, something like:

 

SpotlightItemMorph>>onSelected

self color: (Color r: 0.2627 g: 0.4588 b: 0.9333).

 

becomes:

 

SpotlightItemMorph>>onSelected

self theme spotterThemer configureSelectedItemMorph: self

 

And the default SpotterThemer says:

 

SpotterThemer>>configureSelectedItemMorph: aMorph

     aMorph color: (Color r: 0.2627 g: 0.4588 b: 0.9333)

 I think a good first step would be to overview what exactly is being customized with the existing themes so we don't over-engineer. Also, split-up the theme's responsibilities:

• if we really need all the newXyz methods, have them come from a factory
• how do we treat the services?

Theme first pass:

• Remove copy pasted one-off constructors
• Move default options into Morph classes themselves
• One constructor with just theme customizations performed. Then it's up to you to use the underlying API