On 15 February 2012 21:18, Stéphane Ducasse <stephane.duca...@inria.fr> wrote:
>> I am not sure I understand, so let's get more specific. We talk about one
>> package which contains one Morph.
>>
>> I thought the purpose of UITheme is to encapsulate all decisions related to
>> how a morph gets rendered. It's like a strategy.
>>
>> For example, we have UITheme>>plainGroupPanelBorderStyleFor: and this is
>> called by the PlainGroupboxMorph.
>>
>> In the same style, I have:
>> UITheme>>growlLabelColorFor: aGrowlMorph
>> ^ Color white
>> GrowlMorph>>labelColor
>> ^ self theme growlLabelColorFor: self
>>
>> Is this not the intended way?
>
> I do not know :)
> Because if we generalize that to all the widgets UITheme will explode. And
> you cannot use a widget without a theme.
> Then you always asks the theme. I do not like that
>
> - Do we want UITheme to be a facade?
> - Is UITheme our new preference class?
> - I would prefer to get something like setting
> - GrowlMorph has a class Var for its labelColor
> - and somehow The UITheme push its value inside
> may be the GrowlMorph initialize ask the theme or
> something like that.
> - may each UI could register to the UItheme and the UItheme
> propagate its changes by saying to the widgets
> I changed ask me what you need.
> and the widget say I need these values.
>
> Now I do not see how Uitheme defining the logic of a widget can scale.
>
> Now I'm trying to understand the flow and architecture that the system could
> have. So we should get some more exercises to see.
>
Yes, different themes can be aware about new widget(s) or not..
I think then we should have some safe way of querying theme
GrowlMorph>>labelColor
^ self theme setting: #growlLabelColor default: self defaultColor
Can't say that i like this "pulling" model, querying theme over and over again..
I think it would be much nicer to actually use push model, i.e. let
theme push a props to widget,
and do it once at initialization stage:
Morph>>initialize
....
self applyThemeSettings
Morph>>applyThemeSettings
self theme
applySettings: self class name
to: self
defaults: self applyDefaultSettings.
Morph>>applyDefaultSettings
"do nothing, subclasses may do otherwise"
so, now if theme has some settings for new kid on the block (like
GrowlMorph), it will apply it directly to newly created widget, if
not, then widget will apply own defaults.
So, then all the #labelColor can be turned into simple:
GrowlMorph>>labelColor
^ labelColor
(or #propertyAt: .., if you don't like inst vars) whatever.
A good reason to have defaults, that it is actually serves as a guide
for theme makers, what properties affecting widget
appearance/behavior.
Yeah.. but it will require a bit of refactoring :)
--
Best regards,
Igor Stasenko.
