On Feb 16, 2012, at 2:20 PM, Henrik Johansen wrote:

On Feb 16, 2012, at 2:05 PM, Igor Stasenko wrote:

...

On 16 February 2012 13:53, Henrik Johansen <henrik.s.johansen@veloxit.no> wrote:

...

On Feb 16, 2012, at 12:52 PM, Igor Stasenko wrote:

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,

IIRC from what Gary has posted, it was done that way to easily: 1) have morphs respond to a theme change. (since they fetch values from the theme each draw cycle) 2) not have to hold the state in each individual morph.

Now: 1) should be much easier/cleaner to do using Announcements. 2) is still an issue. However, since most calls create new objects (the different Theme colors are usually created from scratch each call, for instance), and writing it to include caching also leads to ugly code, it might not be as bad.

As for adding values for new widgets - Why do you need a specific label color for growl rather than use the default theme label color? - If you really do, why not use one of the base label colors from the theme (as presented by the facade), and then modify it accordingly instead? (#lighter, #darker, etc)

Yes, status-quo. I agree, that most of the time widgets should use base set of colors (what they are . btw?) provided by theme. But it is not always possible, since some widget could have absolutely unique properties, which cannot be synthesized from any other properties. For example, speaking about Growl morph, it could have settings controlled by theme like: - in what corner of screen to pop up - after how many seconds it should start to fade - should it fade or just disappear immediately - and how long it should fade. Again, if they are fully unique, then why are you consulting a Theme in the first place?

By which I mean; A Theme provides an API to a consistent look and feel (color scheme, roundness of widgets etc). As for what you specified, either that IS specific to the Growl Morph, and should therefore be contained in the growl morph (with appropriate settings), or you encase in the theme settings related to generic *pop-up* behavior. I just don't see the use of providing styling info like #growlLabelColor from a *Theme*, for the same reason I don't think #debuggerScrollbarThickness would be an appropriate thing to ask of a Theme. Cheers, Henry