Theming should be orthogonal to the widget, so subclassing isn't an option. But making it so isn't trivial either.
However, instead of subclassing, each widget might have a theme, to which it could delegate it's rendering, or fallback to the default "theme" in case no custom theming has been defined. However, I favor "descriptive" theming (like CSS) rather than "programmed" theming (like the actual). Regards, Esteban A. Maringolo 2014/1/6 Stéphane Ducasse <[email protected]>: > Now in the car I was thinking > > > if each Widget acts as a factory and theme are subclasses. > - each widget should have/inherit a factory system (may be not good) > - to change a theme we will have to get instance of different widget > subclasses (so it is not good). > > So I like the theme as strategy approach we should try on another widget. > > Stef > > >> Ok I read >> >> >> UITheme would act as a theme factory. >> and each widget delegate to the Themer associated to themselve and the >> current theme >> >> So subclasse of UITheme can propose different themer for the same widget. >> >> Now since the themer is a separate class (from the morph it means that you >> must have all the hooks to customise it). >> So why not. >> I was also thinking that a widget could be an “abstract” class whose >> subclasses implement the themes. >> >> Then you would create a widget like that >> >> >> SpolightItemMorph forThemer: UITheme blue >> and it would create an instance of a subclas SpotligherBluerItemMorph. >> >> Did you try this design? >> >> Stef > >
