Hi, I was rather thinking of having the theme be a composable factory: - for each morph, we would have a factory that would know how to work with that morph. In essence for the GroupBoxMorph, we would have the method below in a GroupBoxFactory. - the UITheme simply stores all these factories, and the morph looks the factory up via the theme. - the UITheme will have no more subclasses. - in this way, you can build a theme by taking factories from other themes without overriding everything simply because you can only subclass from one theme.
This design will work better than the settings-inspired one because typically you need to set more than simple properties. For example, you also need to instantiate things (such as a border morph) and this might be more difficult to set from outside. Cheers, Doru On May 14, 2013, at 9:24 PM, Stéphane Ducasse <[email protected]> wrote: > Looking at the code I have the impression that many UITheme methods should be > moved to the their classes > > Example: > > > UITheme>>newGroupboxIn: aThemedMorph label: aString > "Answer a groupbox with the given label." > > ^GroupboxMorph new > font: self labelFont; > cornerStyle: aThemedMorph preferredCornerStyle; > hResizing: #spaceFill; > vResizing: #spaceFill; > label: aString; > yourself > > Why this is not a creation method on GroupBox? > > Then the trait TeasilyThemed looks suspicious to me. > > > -- www.tudorgirba.com "Presenting is storytelling."
