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.
Why a factory and not just the morph?
- the UITheme simply stores all these factories, and the morph looks the factory up via the theme.
I do not get it. One key question is do we want to have the theme removable or not. Now if we would pushed only data through the hooks of the widgets it could work but we will have to be able to specify specific computation for a given widgets and theme. So may be this is what you mean by factory but this is still not clear to me.
- the UITheme will have no more subclasses.
But you will have multiple subclasses of each of the factories?
- 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.
Yes but the GroupBoxFactory will also be out of the GroupBoxMorph so this is not clear to me how this is different
Cheers, Doru
On May 14, 2013, at 9:24 PM, Stéphane Ducasse <stephane.ducasse@inria.fr> 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."