themeing idea

[Noel Grandin <no...@gmail.com>]

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

Re: themeing idea

[Noel Grandin <no...@gmail.com>]

You're right, the various platform LF's have some quite distinct
differences, but if (like me) you've spent considerable time
scratching around in Swing's LF classes, it quickly becomes evident
that quite a large chunk of the differences beween platform LFs
__are__ simply minor color/font/inset differences

Put simply, I think this is one part of the Swing architecture that
they got right. It makes a large chunk of the work of creating a
custom LF a matter of editing a central configuration file.

It also makes it easier for user-level widgets to "tune" themselves to
the current LF because it's easier to query various style properties
of the current LF.

For example, I have a Swing frequency editing widget that is
completely custom, but manages to blend in by getting various styles
from Swing's UIManager (which is the Swing LF key-value store for
styles).
Which has made quite a difference in getting my widget to blend in
across the various versions of Windows we support.


On Sun, Mar 29, 2009 at 02:17, Greg Brown <gk...@mac.com> wrote:
> 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
>
>

Re: themeing idea

[Greg Brown <gk...@mac.com>]

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