We do plan to refactor a lot of what is currently in Terra into
abstract base classes. Any styles that could potentially be applied to
multiple concrete skin implementations will be moved there. However, I
don't think I'd want to go as far as moving to a "key" model. The
reason is that it's very likely that different concrete themes will
expose very different styles. The example I commonly refer to is OSX's
Aqua L&F - Aqua buttons simply don't look like other buttons, and
generic styles such as "Button.borderColor", "Button.backgroundColor",
etc. simply don't apply to them. As a result, I think it is preferable
to have skins continue to expose styles via bean getters and setters,
even if it that means possible duplication across various theme
packages.
But maybe I'm misunderstanding your suggestion. It's possible that
Terra itself could use a key model internally, if it made sense. It
sounds like you have a particular problem in mind that you are trying
to solve. Maybe if you describe the use case you are trying to
satisfy, we could come up with a workable solution?
On Mar 28, 2009, at 4:56 PM, Noel Grandin wrote:
Hi
This is a fairly late night idea, but here goes:
The default Terra theme uses a fairly simple JSON file to specify it's
basic color palette.
Which is fine for the Terra theme.
But other theme designers are going to want to assign colors to
elements in the widgets differently, and it would nice if we could do
this without replicating the Terra code for each new theme.
But in order to make the Terra theme more generic, we would also need
to move the brighter()/darker() methods out of the code and into the
configuration file.
But code in data files is generally bad idea.
So... rather than generating some horribly complex data format, how
about the current Terra LF classes use well-known keys like
"TextInput.background" to get their styling information, and make the
TerraTheme class responsible for mapping those keys to colours using a
purely private and internal mechanism.
Could even use enums for the keys for additional type safety.
Then it becomes relatively straightforward to define a new theme that
extends TerraTheme and overrides the key to colour mapping.
Of course, this leaves aside the fact that turning Terra LF classes
into some kind of Basic LF is going to require also moving the control
of various insets and sizes and icons into the BasicTheme class.
Regards, Noel Grandin
