> > Ah, I'm satisfied of my dark test json file, can I commit (overwriting > > the original) ? > The original file is not referenced anywhere, so i think it's safe for > me to overwrite.
I'd create a new file just to preserve the original's attempt (albeit amateur - I made it) at another color scheme. >>> Point 2: > >> Todd is probably best suited to comment here. > > Ok, I'll wait Todd answers ... > What do you say ? TerraPushButtonSkin defines the bevel color as as TerraTheme.brighten(backgroundColor) and the pressed bevel color as TerraTheme.darken(backgroundColor). So if your background color is, say, black, then the darker version of black is still black, so the button will look the same when it's pressed. #0a0a0a is close enough to black that my guess is that this is what is happening in your case. And for this, if i could have in the json file also an optional > multiplier (coefficient: 0.0 .. 1.0) for telling how much darken and > how much brighten ... wdyt (what do you think) ? > Not a bad idea - can you create a JIRA ticket for it, probably marked against 1.4. > > > >>> Point 3: > >>> for better consistency with similar elements, I've changed the default > >>> color used for Rollups, this is the patch, should I apply ? > >> > >> I think that looks too dark. The current color was actually chosen by a > >> graphic designer - I think we should leave it as-is. > > For consistency, I used the same default as Labels and other components. > > In the current implementation (color) I think there is only little > > contrast with default background of panels, so for me it hasn't much > > visibility, and in the case of disabled rollup, the disabled color > > could be too similar. > I've just seen that for example in Vista and OS X, trees have an > element like this, and the default color is like my proposal ... so > commit ? TreeView uses a darker color for its expand/collapse control. I agree that since the existing color in Rollup was chosen a graphic designer, we should leave it. > > > > >>> Point 4: > > But in any case, what do you think on changing default colors for > > these components (described in my previous mail), to align on colors > > already used with other components ? > > > Comments ? Again, all these colors were chosen by a graphic designer that designed the terra theme - I think we had better not muck with them without the aid of a graphic designer. In general, that'll be part of a larger exercise to design a new theme that replaces terra (see http://issues.apache.org/jira/browse/PIVOT-29). > Ah, for the release, I've seen there is a new version of Groovy, can i > update the jar (inside demos if i remember well), if the related demo > works, or there are other tests to do on this ? Might as well give it a shot. We'd have to update PIVOT-139<https://issues.apache.org/jira/browse/PIVOT-139>to say Groovy 1.7 :) A little thing, that could go in 1.3.1: > for the Skin, I've seen that in TerraTheme, are defined > > private Font font = null; > private Color[] colors = null; > > but what do you think on moving them to the base class ? > And also for other checks, like that the color index will be in the > right range, I'm thinking to add a method like > getNumberOfPaletteColors() , and also this could go in the base class. > What do you think ? I disagree - a different theme might not even use a palette, or use a palette that's conceived of differently (not indexed for instance). And it might have a set of fonts or a font family... let's not put any artificial restrictions on what a theme must have.
