Hi,
On May 14, 2013, at 10:18 PM, stephane ducasse <[email protected]> wrote:
>
>> 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?
Because you will need a place that will orchestrate how multiple morphs look.
Of course, some of the properties can become part of the morph, but you will
still need the theme responsible object.
>> - 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.
I am not sure what you mean by removable, but I think we should be able to
remove a particular theme, but not the theme as a concept.
>> - the UITheme will have no more subclasses.
>
> But you will have multiple subclasses of each of the factories?
Yes.
>> - 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
GroupBoxMorph>>doSomething
self theme groupBoxFactory doSomethingWith: self
The two will work together tightly.
The advantage is that you will not have all drawing methods in one class, but
nicely separated into dedicated classes.
And then I can do:
UITheme current
textFactory: StandardTextFactory new;
groupBoxFactory: FancyGroupBoxFactory new;
...
Cheers,
Doru
>>
>> 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."
>>
>>
>
>
--
www.tudorgirba.com
"What is more important: To be happy, or to make happy?"
