Wiki

Case Status Kiln
Log In

Wiki

 
Morphic Cleanup»Themes
  • RSS Feed

Last modified on 23/01/2014 06:51 p.m. by User.

Tags:

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:
 
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