You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@pivot.apache.org by Sandro Martini <sa...@gmail.com> on 2009/08/26 13:21:08 UTC
Some Tests on using another color set in Terra Skin
Hi to all,
in these days I'm doing (a long work, that requires many tests ...)
some tests on using another color set in Terra Skin.
As Greg said to me, i have to use the following instruction at the
beginning of startup method (for example I'm trying with KitchenSink,
to see the effect on all components):
Theme.setTheme(new
TerraTheme("org/apache/pivot/wtk/skin/terra/TerraTheme_test.json"));
Point 1:
I'd like to have a sample like this in a source, so what do you think
on put this instruction at least in the real Kitchen Sink class, put
put it commented ?
Or derive a class, like KitchenSinkDarkColors and put there (but many
things in the original KitchenSink should be moved to protected).
Or use another, new class (but in this case it's diffucult to see the
effect on all components) ...
Ah, to see the real color that labels have, could be interesting in
the kitchen_sink.wtkx to not override the color of some rollup labels,
for example first 1, 2 and 3 ...
Point 2:
I changed the existing TerraTheme_test.json, to have a dark color
scheme to see in this case if all is good (prom a visual point of
view) ... and maybe my colors are not the best, but some little things
have revealed, like pressed buttons aren't different from normal, etc
...
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) ?
In any case, i think a useful reference for anyone needs a work like
this is to identify where standard colors are used inside the Terra
skin.
I searched inside many sources, and I identified most of them (i hope
:-) ), so what do you think on add a comment on this inside this json
file ? Like:
{ font: "Verdana 11",
colors: [
"#f2f2f2", // 1: foreground for label etc // verify if use
e5e5e5, but not bababa (less contrast)
"#2b2b2b", // 4: background for groups // verify if use
3d3d3d instead, or 303030
"#998e8a", // 7: borders, and some disabled elements
"#0a0a0a", // 10: background in input elements, tabs, etc //
this + 10% for background (= #242424) // verify if use 4d4d4d (or
better, 454545), or if invert 3d3d3d with 525252
"#f0751c", // 13: selection, link, expanders text, and labels
(overridden) // verify is keep cc6600
"#ff7300", // 16: background in option buttons, title bars, etc
"#851506", // 19: selection background
"#c13719" // 22: errors, invalid elements, etc
]
}
ok, removing my verify text ... it's still a work-in-progress, but I'd
like to have for the 1.3 release.
And maybe the same info could be written elsewhere in a document ...
could really help in these cases, and without addiding additional text
in the standard Terra json file.
Later I'll try with some of the Tango (Icon) Standard palette colors
... we use these icons, so could be e right effect for color
consistencies ...
Point 3:
for better consistency with similar elements, I've changed the default
color used for Rollups, this is the patch, should I apply ?
Index: src/org/apache/pivot/wtk/skin/terra/TerraRollupSkin.java
===================================================================
--- src/org/apache/pivot/wtk/skin/terra/TerraRollupSkin.java (revision 807916)
+++ src/org/apache/pivot/wtk/skin/terra/TerraRollupSkin.java (working copy)
@@ -188,7 +188,7 @@
public TerraRollupSkin() {
TerraTheme theme = (TerraTheme)Theme.getTheme();
- buttonColor = theme.getColor(9);
+ buttonColor = theme.getColor(1);
spacing = 4;
buffer = 4;
fill = false;
Point 4:
for better consistency, a general rule is / should to use as main
colors only Standard Palette Colors (one of the 8 base Terra colors,
given in the json file), but for some elements we should fix, like in
the TerraTextInputSkin (used colors 11 and 10 insteaf of 10 and 9) ...
but in this case re-running my kitchen sink i see no changes (is it
overridden in some place ? I've not seen where ... can you help me,
please).
AlertSkin uses 9 instead of 10 (or 4).
Sheet uses background 11 (with custom alpha) instead of 10.
And probably others ... suggestions ?
Starting (finally) to look better at all these sources, I see the
great (and long and complex) work made by Greg and Todd in last years
... very impressive !!
Bye,
Sandro
Re: Some Tests on using another color set in Terra Skin
Posted by Sandro Martini <sa...@gmail.com>.
> I don't think we should change the Groovy version for 1.3. We can address this as part of PIVOT-140, which is currently targeted for 1.3.1:
Ok.
> I'm all for changing it and improving it, but only with the help of someone
> with a trained eye, and I'm first to admin that eye is not mine :). I
> wouldn't want a graphic designer changing code without the help of a
> developer either :)
I understand your point of view, but i disagree ... I'm not a Graphic
Designer, but I've worked for many years in the Computer Graphics
field (coming only after, approx. 1999, to the web, and doing many
times simple designer tasks), and i think my "eye" are still not so
bad on these things ... but i can live without these little fixes.
I repeat (for the last time, then I'll discard this if others aren't
interested :-( ), only from a consistency point of view in respect to
other components, but i agree color differences in these cases are
only little.
Bye
Re: Some Tests on using another color set in Terra Skin
Posted by Greg Brown <gk...@mac.com>.
>> 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 :)
>I'd like to update to the current Groovy version, so we'll have our
>1.3 aligned to the best version of related tool. For the 1.7 I'd wait
>the final release.
I don't think we should change the Groovy version for 1.3. We can address this as part of PIVOT-140, which is currently targeted for 1.3.1:
https://issues.apache.org/jira/browse/PIVOT-140
Re: Some Tests on using another color set in Terra Skin
Posted by Todd Volkert <tv...@gmail.com>.
> > I'd create a new file just to preserve the original's attempt (albeit
> > amateur - I made it) at another color scheme.
> Ok, so at this point I'll put my json colors in a new file, shipped
> with my DarkColorsTest, I hope in the 1.3.1 .
>
> Idea: I'll send a mail to pivot users to ask them if they have done
> something like this, posting my sample, and see what happen, ok ?
Sure
>
> > 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
> Ok, i don't like this "all these colors were chosen by a graphic
> designer" (so we can't think to change/improve it ?), but i can live
> with it ...
I'm all for changing it and improving it, but only with the help of someone
with a trained eye, and I'm first to admin that eye is not mine :). I
wouldn't want a graphic designer changing code without the help of a
developer either :)
Re: Some Tests on using another color set in Terra Skin
Posted by Sandro Martini <sa...@gmail.com>.
Hi Todd,
> I'd create a new file just to preserve the original's attempt (albeit
> amateur - I made it) at another color scheme.
Ok, so at this point I'll put my json colors in a new file, shipped
with my DarkColorsTest, I hope in the 1.3.1 .
Idea: I'll send a mail to pivot users to ask them if they have done
something like this, posting my sample, and see what happen, ok ?
> 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.
I've taken my point of view, and i agree with this.
> 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.
Great, I'll add a ticket, maybe for the 1.3.x .
> 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.
Ok, i don't like this choice (i thing it has poor contrast /
visibility with default backgrounds), but i can live with it ...
> 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
Ok, i don't like this "all these colors were chosen by a graphic
designer" (so we can't think to change/improve it ?), but i can live
with it ...
> design a new theme that replaces terra (see
> http://issues.apache.org/jira/browse/PIVOT-29).
Ok, but the 2.0 in far ...
But my complaints was to fix some (mistakes ?) in color choosing in
some components, like this:
> the TerraTextInputSkin (used colors 11 and 10 instead of the base color 10 and its variant 9) ...
> but in this case re-running my kitchen sink i see no changes (is it
> overridden in some place ? I've not seen where ... can you help me, please).
> AlertSkin uses 9 instead of the base color 10 used in other components for background (or 4).
> Sheet uses background 11 (with custom alpha) instead of 10.
> And probably others ... suggestions ?
In this case, it's not from a graphic point of view (color changes
here are little), but for better consistency with other components.
> 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 :)
I'd like to update to the current Groovy version, so we'll have our
1.3 aligned to the best version of related tool. For the 1.7 I'd wait
the final release.
> 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.
Ok, I understand.
Bye
Re: Some Tests on using another color set in Terra Skin
Posted by Todd Volkert <tv...@gmail.com>.
> > 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.
Re: Some Tests on using another color set in Terra Skin
Posted by Sandro Martini <sa...@gmail.com>.
Hi, sorry but I need some answers, I'd like to complete this work for
this end of the week (for the 1.3 release), at least for have a dark
color scheme. See previous mails ...
Update:
> If possible, I'd commit this line but commented (with a comment on
> what it means), to simplify tests and to show others how to do this
> ... until I'll have time (for 1.3.x) to create such demo, ok ?
I have an idea of a simple Demo (or better, a test), for the 1.3.1 ,
like DarkColorsTest:
using my customized json file, and with a rollup with:
1 panel (rollup here expanded but disabled, to do some visual tests)
with some header info,
1 panel (rollup here expanded) with inside a form like search fields,
1 panel with a table inside
> 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.
>>> Point 2:
>> Todd is probably best suited to comment here.
> Ok, I'll wait Todd answers ...
What do you say ?
>>> 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 ?
>>> 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 ?
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 ?
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 ?
Thanks a lot,
Sandro
Re: Some Tests on using another color set in Terra Skin
Posted by Sandro Martini <sa...@gmail.com>.
Hi Greg,
>> Theme.setTheme(new
>> TerraTheme("org/apache/pivot/wtk/skin/terra/TerraTheme_test.json"));
>>
>> Point 1:
>> I'd like to have a sample like this in a source, so what do you think
>> on put this instruction at least in the real Kitchen Sink class, put
>> put it commented ?
If possible, I'd commit this line but commented (with a comment on
what it means), to simplify tests and to show others how to do this
... until I'll have time (for 1.3.x) to create such demo, ok ?
Ah, I'm satisfied of my dark test json file, can I commit (overwriting
the original) ?
>> Point 2:
> Todd is probably best suited to comment here.
Ok, I'll wait Todd answers ...
>> In any case, i think a useful reference for anyone needs a work like
>> this is to identify where standard colors are used inside the Terra
>> skin.
>
> I think it might be better to reference the scheme ID from each skin that
> uses it, rather than the other way around. In other words, document (in
> Javadoc) that TerraPushButtonSkin uses color 10 by default for the
> background color. Otherwise, we'll be maintaining this information in two
> places, and the JSON file could get messy.
Ok, but having a summary of how colors are used inside a test json
file like this could help color customizers, to have it as a sample,
without having to read JavaDoc for many classes ... and writing in the
json file that it's only a reference that could not reflect the
current status in Terra skin, ok ?
>> 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.
>> Point 4:
>> for better consistency, a general rule is / should to use as main
>> colors only Standard Palette Colors (one of the 8 base Terra colors,
>> given in the json file)
>
> The 8 base colors exist primarily to provide a simple way to define the
> other colors. All of the colors in the scheme are available for use (though
> they may not all be used at any given time).
Ok, but i think that a better graphic design rule is to work with only
base palette colors, except when i need a variation, like
hiliteBackground or disableBackground that should use directly the
variant of the base color.
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 ?
Sandro
Re: Some Tests on using another color set in Terra Skin
Posted by Greg Brown <gk...@mac.com>.
> Theme.setTheme(new
> TerraTheme("org/apache/pivot/wtk/skin/terra/TerraTheme_test.json"));
>
> Point 1:
> I'd like to have a sample like this in a source, so what do you think
> on put this instruction at least in the real Kitchen Sink class, put
> put it commented ?
It might be better to create a simple demo (or tutorial) app that
shows how to do this. It could just be a few widgets (buttons, lists,
etc.) - just enough to demonstrate the effect. Maybe you could create
one! :-)
> Point 2:
> I changed the existing TerraTheme_test.json, to have a dark color
> scheme to see in this case if all is good (prom a visual point of
> view) ... and maybe my colors are not the best, but some little things
> have revealed, like pressed buttons aren't different from normal, etc
This may just be a factor of how the scheme colors are determined. In
other words, maybe the Terra theme just isn't suited to dark base
colors. On the other hand, this may be something we can (fairly)
easily accommodate. Todd is probably best suited to comment here.
> In any case, i think a useful reference for anyone needs a work like
> this is to identify where standard colors are used inside the Terra
> skin.
> I searched inside many sources, and I identified most of them (i hope
> :-) ), so what do you think on add a comment on this inside this json
> file ? Like:
>
> { font: "Verdana 11",
> colors: [
> "#f2f2f2", // 1: foreground for label etc // verify if use
...
I think it might be better to reference the scheme ID from each skin
that uses it, rather than the other way around. In other words,
document (in Javadoc) that TerraPushButtonSkin uses color 10 by
default for the background color. Otherwise, we'll be maintaining this
information in two places, and the JSON file could get messy.
> 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.
> Point 4:
> for better consistency, a general rule is / should to use as main
> colors only Standard Palette Colors (one of the 8 base Terra colors,
> given in the json file)
The 8 base colors exist primarily to provide a simple way to define
the other colors. All of the colors in the scheme are available for
use (though they may not all be used at any given time).
Thanks,
Greg