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 <[email protected]> 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 > >
