Details

    • Type: Improvement
    • Status: Resolved
    • Priority: Major
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: 2.1, 2.0.5
    • Component/s: wtk-terra
    • Labels:
      None

      Description

      Finishing touches on Skin Colors, some info here (and more later here in JIRA): https://issues.apache.org/jira/browse/PIVOT-579
      See if even the final part of this (not implemented) could be useful: https://issues.apache.org/jira/browse/PIVOT-245

      And there was another discussion (I have to find where, in nabble) is change some color index usage to have better visual appearance (of course retrofitting existing behavior when/if possible).

      Note that probably after these little changes, custom color json files should be a little updated.

      And a little thing on this:
      now only Tooltips doesn't use a palette color (they use an hard-coded color) ... what do you think to make them use the yellow-ish color at
      palette index 19 (or one of is variants, the 18 or 20) ? And use a similar (yellow-ish but a different color index, if possible) color on warnings.

      I could adapt a little that color in all Pivot palettes to look similar to what should be ... tell me.
      For example, someone remember the background color in Swing Tooltips (ok not the best in graphic design and colors ), but with this little change we could also have this little feature, where in most palettes will be yellow-ish, but where needed could be different.

      Added some documentation in the Terra package JavaDoc file on color palette usage in the Terra Skin, to help anyone wants to write their custom colors, and then removed, probably the best place for this is in a Tutorial.

      Last, in ColorSchemeBuilder (and maybe even in the Kitchen Sink), add some Tooltips to see how they happen, but see where they makes sense.
      And maybe in ColorSchemeBuilder move some elements in the Tab2 or Tab3, grouping them by similar components (some componets should be added there).

      1. pivot_colorschemebuilder_dark_flat_screencapt.png
        72 kB
        Sandro Martini
      2. pivot_colorschemebuilder_dark_screencapt.png
        76 kB
        Sandro Martini
      3. pivot_colorschemebuilder_default_flat_screenshot.png
        70 kB
        Sandro Martini
      4. pivot_colorschemebuilder_default_screencapt.png
        76 kB
        Sandro Martini
      5. ComponentExplorer - dark.launch
        1 kB
        Sandro Martini
      6. KitchenSink - Dark.launch
        0.8 kB
        Sandro Martini
      7. ColorSchemeBuilder - dark.launch
        1 kB
        Sandro Martini
      8. pivot689.patch
        5 kB
        Sandro Martini

        Issue Links

          Activity

          Hide
          smartini Sandro Martini added a comment -

          Hi Roger, sorry for the delay.
          To me your proposal looks ok, only I'd put those changes in another issue, linked with this ...

          On others (secondary) scheme files, we can do some fix if/as needed.

          Show
          smartini Sandro Martini added a comment - Hi Roger, sorry for the delay. To me your proposal looks ok, only I'd put those changes in another issue, linked with this ... On others (secondary) scheme files, we can do some fix if/as needed.
          Hide
          rwhitcomb Roger Whitcomb added a comment -

          Actually you can do 'System.setProperty("org.apache.pivot.wtk.skin.terra.location", "TerraTheme_dark.json")' (for instance) even in code (i.e., not on the command line) before you create any Pivot components.

          So, having some others shipped in the pivot-wtk-terra.jar file would facilitate doing this (and thus setting up a dark theme).

          Another thing I thought of, if we had some color schemes that looked good, would be to setup a small enum for use in a new method in Theme that would set the "location" from a field in the enum. Then, potentially you could write code like this:
          Theme.setColorScheme(ColorScheme.DARK);
          which would set "location" to "TerraTheme_dark.json".
          For non-standard ones, then you could go back to using the System.setProperty method (as above) or using -D on the command line.

          What do you think? I can code up a patch for my enum scheme if you want to look at it.

          Show
          rwhitcomb Roger Whitcomb added a comment - Actually you can do 'System.setProperty("org.apache.pivot.wtk.skin.terra.location", "TerraTheme_dark.json")' (for instance) even in code (i.e., not on the command line) before you create any Pivot components. So, having some others shipped in the pivot-wtk-terra.jar file would facilitate doing this (and thus setting up a dark theme). Another thing I thought of, if we had some color schemes that looked good, would be to setup a small enum for use in a new method in Theme that would set the "location" from a field in the enum. Then, potentially you could write code like this: Theme.setColorScheme(ColorScheme.DARK); which would set "location" to "TerraTheme_dark.json". For non-standard ones, then you could go back to using the System.setProperty method (as above) or using -D on the command line. What do you think? I can code up a patch for my enum scheme if you want to look at it.
          Hide
          smartini Sandro Martini added a comment -

          Hi Roger,
          note that older json theme files have been moved only in trunk (so in 2.0.x they are in the same project/package as before), into the demos subproject, mainly because I didn't have enough time to test (and fix colors inside because of changes in trunk needed by this issue) them. If someone has enough time to make some check I'm not against moving in the original project/folder, I'll be happy to give some help but due to time constraints not too much.

          So your proposal now is only to add a way to set that property by code instead of pass it via command line argument ( -Dorg.apache.pivot.wtk.skin.terra.location=... ), or did I miss something other (sorry) ?

          Show
          smartini Sandro Martini added a comment - Hi Roger, note that older json theme files have been moved only in trunk (so in 2.0.x they are in the same project/package as before), into the demos subproject, mainly because I didn't have enough time to test (and fix colors inside because of changes in trunk needed by this issue) them. If someone has enough time to make some check I'm not against moving in the original project/folder, I'll be happy to give some help but due to time constraints not too much. So your proposal now is only to add a way to set that property by code instead of pass it via command line argument ( -Dorg.apache.pivot.wtk.skin.terra.location=... ), or did I miss something other (sorry) ?
          Hide
          rwhitcomb Roger Whitcomb added a comment -

          Had another thought. Could we / should we ship a number of the possible theme files (including possibly the old one from 2.0.4) so that you could simply choose one (non-default) by doing:
          System.setProperty("org.apache.pivot.wtk.skin.terra.location", "TerraTheme_dark.json");
          (for instance) before you instantiate the theme for the first time?

          That would make a simple way to select one of the styles we have predesigned.

          Show
          rwhitcomb Roger Whitcomb added a comment - Had another thought. Could we / should we ship a number of the possible theme files (including possibly the old one from 2.0.4) so that you could simply choose one (non-default) by doing: System.setProperty("org.apache.pivot.wtk.skin.terra.location", "TerraTheme_dark.json"); (for instance) before you instantiate the theme for the first time? That would make a simple way to select one of the styles we have predesigned.
          Hide
          smartini Sandro Martini added a comment -

          All should be good now.

          Show
          smartini Sandro Martini added a comment - All should be good now.
          Hide
          smartini Sandro Martini added a comment - - edited

          > TextArea now has a light gray background that also used to be white
          perhaps I forget some changes here (and even in TextPane), I agree that white background is better, and they must be consistent with TextInput
          => Committed the fix in revision 1624221.

          > Menu items now have a light gray background that used to be transparent or white
          this should be more consistent with other components (even on the transparency) ...
          => after some check I confirm that things are consistent (more than before) with other components, at least running ColorSchemeBuilder, ComponentExplorer, Kitchen Sink; the light gray background is the same used in other backgrounds (I think should be a good default, even because it makes a little visual difference from the white area at left in any menu item)
          => do you need/prefer white even for menu item elements ? or is no more possible to override this value (didn't tried, just guessing) ?

          Show
          smartini Sandro Martini added a comment - - edited > TextArea now has a light gray background that also used to be white perhaps I forget some changes here (and even in TextPane), I agree that white background is better, and they must be consistent with TextInput => Committed the fix in revision 1624221. > Menu items now have a light gray background that used to be transparent or white this should be more consistent with other components (even on the transparency) ... => after some check I confirm that things are consistent (more than before) with other components, at least running ColorSchemeBuilder, ComponentExplorer, Kitchen Sink; the light gray background is the same used in other backgrounds (I think should be a good default, even because it makes a little visual difference from the white area at left in any menu item) => do you need/prefer white even for menu item elements ? or is no more possible to override this value (didn't tried, just guessing) ?
          Hide
          rwhitcomb Roger Whitcomb added a comment -

          I'm seeing a few visual changes in our application with these changes:

          • Menu items now have a light gray background that used to be transparent or white.
          • TextArea now has a light gray background that also used to be white.

          Were these intentional or artifacts of other things?

          Show
          rwhitcomb Roger Whitcomb added a comment - I'm seeing a few visual changes in our application with these changes: Menu items now have a light gray background that used to be transparent or white. TextArea now has a light gray background that also used to be white. Were these intentional or artifacts of other things?
          Hide
          smartini Sandro Martini added a comment -

          Ciao Roger,
          ok on the font change, better i18n multiplatform is good for everyone.
          I'll post updated screenshot (default and dark) with that new font, but in that issue (if someone need compare screenshot between here and the other issue).

          Show
          smartini Sandro Martini added a comment - Ciao Roger, ok on the font change, better i18n multiplatform is good for everyone. I'll post updated screenshot (default and dark) with that new font, but in that issue (if someone need compare screenshot between here and the other issue).
          Hide
          smartini Sandro Martini added a comment -

          Link to new issue for only changing the font (to better track this change, small but important because very visible)

          Show
          smartini Sandro Martini added a comment - Link to new issue for only changing the font (to better track this change, small but important because very visible)
          Hide
          rwhitcomb Roger Whitcomb added a comment -

          Ciao Sandro,
          With regard to changing the default font: we found that the Java "logical" fonts (such as "MONOSPACED", "DIALOG", etc.) support more characters in the Unicode set since they are composite fonts. So, "Verdana" was not found to be a good choice for us. Changing to "DIALOG" worked well for us to be able to see Korean characters (for instance) correctly. None of the "Windows-only" fonts had the characters to display Korean (not "Arial", "Verdana", "Tahoma"...) but MONOSPACED, DIALOG, SERIF, and SANS_SERIF all did have these characters.

          So, my recommendation (and this is a big visual difference) would be to change the default Theme font to "DIALOG 12" instead of "Verdana 11".

          This also works better on non-Windows platforms, which don't typically have these Windows fonts available. OSX, for instance, has Helvetica, but not Arial or Verdana. Linux typically has Bitstream and DejaVu fonts, maybe Lucida, but none of the other "Windows" fonts.

          Show
          rwhitcomb Roger Whitcomb added a comment - Ciao Sandro, With regard to changing the default font: we found that the Java "logical" fonts (such as "MONOSPACED", "DIALOG", etc.) support more characters in the Unicode set since they are composite fonts. So, "Verdana" was not found to be a good choice for us. Changing to "DIALOG" worked well for us to be able to see Korean characters (for instance) correctly. None of the "Windows-only" fonts had the characters to display Korean (not "Arial", "Verdana", "Tahoma"...) but MONOSPACED, DIALOG, SERIF, and SANS_SERIF all did have these characters. So, my recommendation (and this is a big visual difference) would be to change the default Theme font to "DIALOG 12" instead of "Verdana 11". This also works better on non-Windows platforms, which don't typically have these Windows fonts available. OSX, for instance, has Helvetica, but not Arial or Verdana. Linux typically has Bitstream and DejaVu fonts, maybe Lucida, but none of the other "Windows" fonts.
          Hide
          smartini Sandro Martini added a comment -

          Resolved, but be free to reopen if needed.

          Show
          smartini Sandro Martini added a comment - Resolved, but be free to reopen if needed.
          Hide
          smartini Sandro Martini added a comment -

          Committed revision 1621757:
          cleanup: move (a little outdated now) skin config files from wtk-terra to demos (but keep the same package, at least for now).
          But keep (unchanged) default and dark config files, in the original place.

          Show
          smartini Sandro Martini added a comment - Committed revision 1621757: cleanup: move (a little outdated now) skin config files from wtk-terra to demos (but keep the same package, at least for now). But keep (unchanged) default and dark config files, in the original place.
          Hide
          smartini Sandro Martini added a comment - - edited

          Screenshot of Color Scheme Builder with updated version of code (only the size change of default font from 11 to 12 in the default has to be committed), running with latest Java 7 under Windows 7. Default colors and dark colors, both normal, and with the new flat variant (as a sample).

          I think colors are good (maybe background color in flat mode for buttons should have more contrast).

          Show
          smartini Sandro Martini added a comment - - edited Screenshot of Color Scheme Builder with updated version of code (only the size change of default font from 11 to 12 in the default has to be committed), running with latest Java 7 under Windows 7. Default colors and dark colors, both normal, and with the new flat variant (as a sample). I think colors are good (maybe background color in flat mode for buttons should have more contrast).
          Hide
          smartini Sandro Martini added a comment - - edited

          Another small change proposed: by default we use the font "Verdana 11", but with higher resolutions etc, what do you think on using "Verdana 12" instead ? I just tried on Windows 7 and the text seems (a little higher, ok ) better.
          But currently I'm not able to make some test in other platforms (even Windows XP), someone is able to do these check for me ?
          No objections so committed.

          Last, under Terra we have some examples of skin configuration files, but I guess if someone really used these files ... and now (with changes of this issue) they could not be so visually good; so I'm thinking to move them into our demos subproject, unless objections in a few days.
          No objections, so committed the change: they are now in the same package, but in the Demos subproject. In the original package and place now there are only default and dark.

          Then maybe add (under Demos, with others) even a new combination derived from Twitter Bootstrap default colors (used in many sites), could be for Pivot Applications/Applets to better visual integration with them.
          Reminder for the future: check what gray color use for different background here (default pure white), and maybe use green for list/table/tree/alement selection here; original colors here are: blu #428BCA (66,139,202), cyan #5BC0DE (91,192,222), orange #F0AD4E (240,173,78), red #D9534F (217,83,79), etc.

          Show
          smartini Sandro Martini added a comment - - edited Another small change proposed: by default we use the font "Verdana 11", but with higher resolutions etc, what do you think on using "Verdana 12" instead ? I just tried on Windows 7 and the text seems (a little higher, ok ) better. But currently I'm not able to make some test in other platforms (even Windows XP), someone is able to do these check for me ? No objections so committed. Last, under Terra we have some examples of skin configuration files, but I guess if someone really used these files ... and now (with changes of this issue) they could not be so visually good; so I'm thinking to move them into our demos subproject, unless objections in a few days. No objections, so committed the change: they are now in the same package, but in the Demos subproject. In the original package and place now there are only default and dark. Then maybe add (under Demos, with others) even a new combination derived from Twitter Bootstrap default colors (used in many sites), could be for Pivot Applications/Applets to better visual integration with them. Reminder for the future: check what gray color use for different background here (default pure white), and maybe use green for list/table/tree/alement selection here; original colors here are: blu #428BCA (66,139,202), cyan #5BC0DE (91,192,222), orange #F0AD4E (240,173,78), red #D9534F (217,83,79), etc.
          Hide
          smartini Sandro Martini added a comment - - edited

          Committed revision 1620944, with a rebalancing and updates to some colors of the default palette (of Terra Skin), so all is less whitening, but some colors have more saturation now.

          Now check the foreground color of labels: it uses the index 1 of palette colors, but now color 1 of default palette is very dark (10,10,10), but not pure black (0,0,0) like palette index 0, so the contrast with backgound is not as max as could be ... but things looks good the same, so unless objections could be safe to keep it as is.

          Tell me for problems or if you don't like these changes.

          Show
          smartini Sandro Martini added a comment - - edited Committed revision 1620944, with a rebalancing and updates to some colors of the default palette (of Terra Skin), so all is less whitening, but some colors have more saturation now. Now check the foreground color of labels: it uses the index 1 of palette colors, but now color 1 of default palette is very dark (10,10,10), but not pure black (0,0,0) like palette index 0, so the contrast with backgound is not as max as could be ... but things looks good the same, so unless objections could be safe to keep it as is. Tell me for problems or if you don't like these changes.
          Hide
          smartini Sandro Martini added a comment - - edited

          Just cleaned up a few (unnecessary) override in colors in sample_content.bxml (loaded by ColorSchemeBuilder), and note that if I change the styles of ScrollPane (of Tab 1) from backgroundColor:null, for example to something very visible like backgroundColor:'#ff0000', I see what is really causing a lot of whitening there ...
          Note that after changing palette colors, only contents inside Tabs is shown changed (because it's reloaded) so all other parts still use original colors ... and consistence in color usege even here is ok.

          Then, the second issue is related to the second color of default palette too much white (if I try to lowering it, i see things inside the tab, darkening as background, ok) ... now we could think to adjust a little that color (for example from 255,255,255 to 250,250,250 or similar, and the same for first color 0,0,0 to 5,5,5), or even increase the difference, like 245,245,245 and 10,10,10 for example.
          I can look at old (2.0.x) appearance and try to get a similar visual result.

          Last, after these changes I still see some areas white at top and bottom left, but it's the default skin backgound color, now configurable, ok.
          I think it would be good to add a default even for this in skin default config file like the previous ...

          What do you think ?

          Show
          smartini Sandro Martini added a comment - - edited Just cleaned up a few (unnecessary) override in colors in sample_content.bxml (loaded by ColorSchemeBuilder), and note that if I change the styles of ScrollPane (of Tab 1) from backgroundColor:null, for example to something very visible like backgroundColor:'#ff0000', I see what is really causing a lot of whitening there ... Note that after changing palette colors, only contents inside Tabs is shown changed (because it's reloaded) so all other parts still use original colors ... and consistence in color usege even here is ok. Then, the second issue is related to the second color of default palette too much white (if I try to lowering it, i see things inside the tab, darkening as background, ok) ... now we could think to adjust a little that color (for example from 255,255,255 to 250,250,250 or similar, and the same for first color 0,0,0 to 5,5,5), or even increase the difference, like 245,245,245 and 10,10,10 for example. I can look at old (2.0.x) appearance and try to get a similar visual result. Last, after these changes I still see some areas white at top and bottom left, but it's the default skin backgound color, now configurable, ok. I think it would be good to add a default even for this in skin default config file like the previous ... What do you think ?
          Hide
          smartini Sandro Martini added a comment -

          Committed revision 1619713 (and a small simplification if 1619715):
          add defaultBackgroundColor and defaultForegroundColor in Terra Theme json config file (to be able to set them) with a good fallback value. Note that even in general Theme there are (general) default values for them.
          As a sample, add some (very visible: red, and yellow) values for them.

          Now I guess if it would be useful to define these values even in TerraTheme_default.json (and maybe even in TerraTheme_dark.json) files, for two reasons:

          • have a sample of its usage (without having to look at code), for our users
          • check if change these values, at least in the TerraTheme_default.json file (to reduce the whitening effect just seen) ...

          Comments ?

          Show
          smartini Sandro Martini added a comment - Committed revision 1619713 (and a small simplification if 1619715): add defaultBackgroundColor and defaultForegroundColor in Terra Theme json config file (to be able to set them) with a good fallback value. Note that even in general Theme there are (general) default values for them. As a sample, add some (very visible: red, and yellow) values for them. Now I guess if it would be useful to define these values even in TerraTheme_default.json (and maybe even in TerraTheme_dark.json) files, for two reasons: have a sample of its usage (without having to look at code), for our users check if change these values, at least in the TerraTheme_default.json file (to reduce the whitening effect just seen) ... Comments ?
          Hide
          rwhitcomb Roger Whitcomb added a comment -

          Preliminary results are that since we define most/all our colors in BXML files, there seems to be no difference in our app between old and new. I'm also checking one other small Pivot app I have.

          Show
          rwhitcomb Roger Whitcomb added a comment - Preliminary results are that since we define most/all our colors in BXML files, there seems to be no difference in our app between old and new. I'm also checking one other small Pivot app I have.
          Hide
          smartini Sandro Martini added a comment -

          > Will try it in our app to see how it looks (about too much whiteness?).
          ok, thanks ... but note that in our examples in many places colors are redefined (for example in bxml files), so the comparison could not be so simple ... anyway I'll take a look too (I did only some small changes to color index used in a few components, for rationalizing them among different components).

          > I had one other suggestion, which is to add these default colors into the theme JSON files themselves, with defaults to BLACK / WHITE if not present. That way even these could be set /tweaked in a custom color scheme.
          yes, I agree ... I'll make the change.

          Show
          smartini Sandro Martini added a comment - > Will try it in our app to see how it looks (about too much whiteness?). ok, thanks ... but note that in our examples in many places colors are redefined (for example in bxml files), so the comparison could not be so simple ... anyway I'll take a look too (I did only some small changes to color index used in a few components, for rationalizing them among different components). > I had one other suggestion, which is to add these default colors into the theme JSON files themselves, with defaults to BLACK / WHITE if not present. That way even these could be set /tweaked in a custom color scheme. yes, I agree ... I'll make the change.
          Hide
          rwhitcomb Roger Whitcomb added a comment -

          Ciao Sandro,
          Just saw the commit. Code looks good. Will try it in our app to see how it looks (about too much whiteness?).

          I had one other suggestion, which is to add these default colors into the theme JSON files themselves, with defaults to BLACK / WHITE if not present. That way even these could be set /tweaked in a custom color scheme.

          What do you think?

          ~Roger

          Show
          rwhitcomb Roger Whitcomb added a comment - Ciao Sandro, Just saw the commit. Code looks good. Will try it in our app to see how it looks (about too much whiteness?). I had one other suggestion, which is to add these default colors into the theme JSON files themselves, with defaults to BLACK / WHITE if not present. That way even these could be set /tweaked in a custom color scheme. What do you think? ~Roger
          Hide
          smartini Sandro Martini added a comment -

          Hi Roger, just Committed revision 1619155 with changes like your proposal ... all should be ok now, otherwise tell me.

          Note that common methods currently are all in ComponentSkin, and no additional methods have been put in Theme (but they could be) ... if someone thinks methods like defaultBackgroundColor/defaultForegroundColor could be useful in Theme (maybe because someone could override them in a simpler way), I'll update/move them there, tell me if needed.

          Small note: running some examples in the usual (default) color scheme combination now It seems to me that the interface is a little too much whitening, tell me if some adjustment is needed.

          Show
          smartini Sandro Martini added a comment - Hi Roger, just Committed revision 1619155 with changes like your proposal ... all should be ok now, otherwise tell me. Note that common methods currently are all in ComponentSkin, and no additional methods have been put in Theme (but they could be) ... if someone thinks methods like defaultBackgroundColor/defaultForegroundColor could be useful in Theme (maybe because someone could override them in a simpler way), I'll update/move them there, tell me if needed. Small note: running some examples in the usual (default) color scheme combination now It seems to me that the interface is a little too much whitening, tell me if some adjustment is needed.
          Hide
          rwhitcomb Roger Whitcomb added a comment -

          Probably would need (at least) two methods:
          getBackgroundColor() and getContrastColor() which are opposites of each other.
          getBackgroundColor returns BLACK for theme is dark and WHITE if not
          getContrastColor returns WHITE for theme is dark and BLACK if not

          What do you think?

          Show
          rwhitcomb Roger Whitcomb added a comment - Probably would need (at least) two methods: getBackgroundColor() and getContrastColor() which are opposites of each other. getBackgroundColor returns BLACK for theme is dark and WHITE if not getContrastColor returns WHITE for theme is dark and BLACK if not What do you think?
          Hide
          smartini Sandro Martini added a comment -

          Hi Roger, yes I was thinking the same (and already add an utility method for this kind of color manipoulation) ... tomorrow I'll try to look at it. Thanks for now . Bye

          Show
          smartini Sandro Martini added a comment - Hi Roger, yes I was thinking the same (and already add an utility method for this kind of color manipoulation) ... tomorrow I'll try to look at it. Thanks for now . Bye
          Hide
          rwhitcomb Roger Whitcomb added a comment -

          Ciao Sandro,
          I see a lot of code in your latest submission that looks like:
          if (!themeIsDark()) {
          get BLACK
          } else {
          get WHITE
          }

          Could this be refactored into a utility method like Theme.getContrastColor()? Would reduce the duplicated code...

          ~Roger

          Show
          rwhitcomb Roger Whitcomb added a comment - Ciao Sandro, I see a lot of code in your latest submission that looks like: if (!themeIsDark()) { get BLACK } else { get WHITE } Could this be refactored into a utility method like Theme.getContrastColor()? Would reduce the duplicated code... ~Roger
          Hide
          smartini Sandro Martini added a comment - - edited

          Found other small improvements, like providing better default when the theme is dark (use white instead of black, and black instead of white):
          in WTK thare was some hard-coded colors, so a simple solution is to keep them hard-coded but in a more generic way.

          Note that in some classes this still has not been applied: ListButtonColorItemRenderer, ListViewColorItemRenderer, and even in some effects.

          Show
          smartini Sandro Martini added a comment - - edited Found other small improvements, like providing better default when the theme is dark (use white instead of black, and black instead of white): in WTK thare was some hard-coded colors, so a simple solution is to keep them hard-coded but in a more generic way. Note that in some classes this still has not been applied: ListButtonColorItemRenderer, ListViewColorItemRenderer, and even in some effects.
          Hide
          smartini Sandro Martini added a comment - - edited

          Just see that ActivityIndicators (skin component is TerraActivityIndicatorSkin) with the dark color scheme seems to have a white background (even if backgroundColor is by default set to null inside it), but the problem seems related to some settings inside Component Explorer, because when running Kitchen Sink with the same color combination, ActivityIndicators have a transparent backgound (ok); I'll try to take a look at it in some free time.

          No, the problem is that by default WindowSkin has a backgroundColor set to Color.WHITE and even other base generic components (and they are generic so this is Ok), while TerraFrameSkin and others Terra components set other colors defined in the theme (ok).

          This little thing with ActivityIndicators is visible even running the (just updated) test file activity_indicator_test.bxml ; try in that file to change Window with Frame and even background color under ActivityIndicators will change, to demonstrate that it's something related to the container.

          So, to solve this small thing, I have to try in ActivityIndicators to set to null the backgroundColor of the container (if any) ... no, see comments below.

          Show
          smartini Sandro Martini added a comment - - edited Just see that ActivityIndicators (skin component is TerraActivityIndicatorSkin) with the dark color scheme seems to have a white background (even if backgroundColor is by default set to null inside it), but the problem seems related to some settings inside Component Explorer, because when running Kitchen Sink with the same color combination, ActivityIndicators have a transparent backgound (ok); I'll try to take a look at it in some free time. No, the problem is that by default WindowSkin has a backgroundColor set to Color.WHITE and even other base generic components (and they are generic so this is Ok), while TerraFrameSkin and others Terra components set other colors defined in the theme (ok). This little thing with ActivityIndicators is visible even running the (just updated) test file activity_indicator_test.bxml ; try in that file to change Window with Frame and even background color under ActivityIndicators will change, to demonstrate that it's something related to the container. So, to solve this small thing, I have to try in ActivityIndicators to set to null the backgroundColor of the container (if any) ... no, see comments below.
          Hide
          smartini Sandro Martini added a comment -

          Attach eclipse launch file for running ComponentExplorer with the dark color combination, as a sample.

          Show
          smartini Sandro Martini added a comment - Attach eclipse launch file for running ComponentExplorer with the dark color combination, as a sample.
          Hide
          smartini Sandro Martini added a comment -

          Hi Roger, this is a feature that we have since many time, but there is not so much documentation on it (some discussions in our mailing lists) ... I'll try to write something and see where to put it in our docs/tutorials/demos (Color Scheme Creator Demo page could be a good candidate because during development of custom color schemes many times it's used, even to have a real-time preview); but note that it generates only the array containing colors, not a complete Terra Theme custom json file.

          Anyway, just for info, to use a custom theme colors you have to pass to Applications a startup argument like this:
          -Dorg.apache.pivot.wtk.skin.terra.location=/org/apache/pivot/tutorials/TerraTheme_dark.json
          or (depending on the location of json file sometimes you could use a relative path, like:
          -Dorg.apache.pivot.wtk.skin.terra.location=TerraTheme_swing.json
          Even Applets should be able to use this feature.

          Note that there is another feature, for using custom stylesheet but it's another story ...

          Eclipse launch files in attach in this issue are a sample of this, directly usable inside eclipse, just copy in a project (it's better in a new one) inside the workspace and run them .

          Show
          smartini Sandro Martini added a comment - Hi Roger, this is a feature that we have since many time, but there is not so much documentation on it (some discussions in our mailing lists) ... I'll try to write something and see where to put it in our docs/tutorials/demos (Color Scheme Creator Demo page could be a good candidate because during development of custom color schemes many times it's used, even to have a real-time preview); but note that it generates only the array containing colors, not a complete Terra Theme custom json file. Anyway, just for info, to use a custom theme colors you have to pass to Applications a startup argument like this: -Dorg.apache.pivot.wtk.skin.terra.location=/org/apache/pivot/tutorials/TerraTheme_dark.json or (depending on the location of json file sometimes you could use a relative path, like: -Dorg.apache.pivot.wtk.skin.terra.location=TerraTheme_swing.json Even Applets should be able to use this feature. Note that there is another feature, for using custom stylesheet but it's another story ... Eclipse launch files in attach in this issue are a sample of this, directly usable inside eclipse, just copy in a project (it's better in a new one) inside the workspace and run them .
          Hide
          rwhitcomb Roger Whitcomb added a comment -

          So, Sandro, pardon my ignorance here, but are there Tutorials or Examples of how you would style an application at runtime with a new set of Theme colors? How would an application attach a modified global style sheet to itself, and have Pivot respect it? Would that go in the "startup" method, or by setting properties or ??

          Show
          rwhitcomb Roger Whitcomb added a comment - So, Sandro, pardon my ignorance here, but are there Tutorials or Examples of how you would style an application at runtime with a new set of Theme colors? How would an application attach a modified global style sheet to itself, and have Pivot respect it? Would that go in the "startup" method, or by setting properties or ??
          Hide
          smartini Sandro Martini added a comment - - edited

          Committed revision 1615694: set the same transparency color already used in Sheets (and other popups) even in Alerts, Dialogs, Palette.

          Committed revision 1615877: the changes to default values in DropShadowDecorator to (3, 3, 3) because most usage inside Pivot already use that value.

          Committed revision 1615894: use a new utility method to set transparency on a given color.

          Later check if add a new style property to set backgroundTransparency.

          Show
          smartini Sandro Martini added a comment - - edited Committed revision 1615694: set the same transparency color already used in Sheets (and other popups) even in Alerts, Dialogs, Palette. Committed revision 1615877: the changes to default values in DropShadowDecorator to (3, 3, 3) because most usage inside Pivot already use that value. Committed revision 1615894: use a new utility method to set transparency on a given color. Later check if add a new style property to set backgroundTransparency.
          Hide
          smartini Sandro Martini added a comment - - edited

          Commited the fix on the background color (previously if was fixed to white) of TerraScrollPaneSkin in trunk.
          In Revision 1615882 committed a backport of this to 2.0.x .

          Then, just found that all (except two) creation of DropShadowDecorator uses (3, 3, 3) as arguments but the default constructor uses (5, 5, 5) ... so a better default could be (3, 3, 3) ... objections in change the default (and use default constructor) but only for trunk ?

          Show
          smartini Sandro Martini added a comment - - edited Commited the fix on the background color (previously if was fixed to white) of TerraScrollPaneSkin in trunk. In Revision 1615882 committed a backport of this to 2.0.x . Then, just found that all (except two) creation of DropShadowDecorator uses (3, 3, 3) as arguments but the default constructor uses (5, 5, 5) ... so a better default could be (3, 3, 3) ... objections in change the default (and use default constructor) but only for trunk ?
          Hide
          smartini Sandro Martini added a comment - - edited

          Merge the small change (on border color for tooltips) even in 2.0.x.
          Now all visual inconsistencies are fixed, so mark this as Resolved.

          Be free to reopen if you find other (minor) visual inconsistency to fix in trunk.

          Show
          smartini Sandro Martini added a comment - - edited Merge the small change (on border color for tooltips) even in 2.0.x. Now all visual inconsistencies are fixed, so mark this as Resolved. Be free to reopen if you find other (minor) visual inconsistency to fix in trunk.
          Hide
          rwhitcomb Roger Whitcomb added a comment -

          I would merge into 2.0.x.... Seems like this would be worth it. Thanks.

          Show
          rwhitcomb Roger Whitcomb added a comment - I would merge into 2.0.x.... Seems like this would be worth it. Thanks.
          Hide
          smartini Sandro Martini added a comment - - edited

          Just committed (but only in trunk) in rev. 1613063 a small fix that make Tooltips use the same palette color for the border (like in all other components), before it was using always Black.
          Note that if for tooltips otherwise I suggest the usage of another palette color, that used for Labels.

          Tell me if this small part of the fix is needed even in 2.0.x .

          > corner isn't part of the header - it is drawn by the ScrollPane
          So could be too much complex to fix (in a generic way, because ScrollPanes are used in many components), so this won't be fixed, sorry.

          Unless objections I'll mark this as resolved in a few days.

          Show
          smartini Sandro Martini added a comment - - edited Just committed (but only in trunk) in rev. 1613063 a small fix that make Tooltips use the same palette color for the border (like in all other components), before it was using always Black. Note that if for tooltips otherwise I suggest the usage of another palette color, that used for Labels. Tell me if this small part of the fix is needed even in 2.0.x . > corner isn't part of the header - it is drawn by the ScrollPane So could be too much complex to fix (in a generic way, because ScrollPanes are used in many components), so this won't be fixed, sorry. Unless objections I'll mark this as resolved in a few days.
          Hide
          smartini Sandro Martini added a comment -

          Add some eclipse launch files, to simplify test run.

          Show
          smartini Sandro Martini added a comment - Add some eclipse launch files, to simplify test run.
          Hide
          smartini Sandro Martini added a comment - - edited

          Made some minor changes to a color in TerraTheme_dark.json, to better contrast with Text color, so Text in tooltips is readable now.

          Note that for example running ColorSchemeBuilder with that color scheme definition ( org.apache.pivot.demos.styles.ColorSchemeBuilder -Dorg.apache.pivot.wtk.skin.terra.location=TerraTheme_dark.json )
          I see some minor visual inconsistencies:

          • mouse over some component doesn't brighten the row/element (when themeIsDark is true sould be used the negative effect on colors, and usually this is darkening the element when themeIsDark is false)
          • mouse over Menu Button hilite elements but with a different color (and probably even Menu, I have to check this in other test applications) ... but this could be right because on a Menu when I select something the menu disappears
          • the tree have a white background which is not consistent with color scheme used ... but could be a problem in the scroll area instead, I have to check
          • maybe others, please tell me if someone finds something

          Note that if possible things fixed here will be backported to 2.0.x, but of course only compatible changes .

          In attach I put a sample eclipse launch config file, to simplify tests.

          Last, an interesting feature could be to give a Theme the ability to return a list of Components (and related class names) registered in it ... if useful I could add to the Theme, please tell me if useful/needed.

          Comments ?

          Show
          smartini Sandro Martini added a comment - - edited Made some minor changes to a color in TerraTheme_dark.json, to better contrast with Text color, so Text in tooltips is readable now. Note that for example running ColorSchemeBuilder with that color scheme definition ( org.apache.pivot.demos.styles.ColorSchemeBuilder -Dorg.apache.pivot.wtk.skin.terra.location=TerraTheme_dark.json ) I see some minor visual inconsistencies: mouse over some component doesn't brighten the row/element (when themeIsDark is true sould be used the negative effect on colors, and usually this is darkening the element when themeIsDark is false) mouse over Menu Button hilite elements but with a different color (and probably even Menu, I have to check this in other test applications) ... but this could be right because on a Menu when I select something the menu disappears the tree have a white background which is not consistent with color scheme used ... but could be a problem in the scroll area instead, I have to check maybe others, please tell me if someone finds something Note that if possible things fixed here will be backported to 2.0.x, but of course only compatible changes . In attach I put a sample eclipse launch config file, to simplify tests. Last, an interesting feature could be to give a Theme the ability to return a list of Components (and related class names) registered in it ... if useful I could add to the Theme, please tell me if useful/needed. Comments ?
          Hide
          rwhitcomb Roger Whitcomb added a comment -

          Committed a fix to protect against NPE if themes without the "themeIsDark" property are encountered:
          Sending wtk-terra\src\org\apache\pivot\wtk\skin\terra\TerraTheme.java
          Transmitting file data .
          Committed revision 1536913.

          Show
          rwhitcomb Roger Whitcomb added a comment - Committed a fix to protect against NPE if themes without the "themeIsDark" property are encountered: Sending wtk-terra\src\org\apache\pivot\wtk\skin\terra\TerraTheme.java Transmitting file data . Committed revision 1536913.
          Hide
          rwhitcomb Roger Whitcomb added a comment - - edited

          Just wanted to suggest that we could add a few more color-related (abstract) methods to Theme.java so that "setBaseColor" and some other things that currently exist only in TerraTheme.java could be called via a generic "Theme" object (so that the example code can be generic).

          Reopening the issue for this.

          Show
          rwhitcomb Roger Whitcomb added a comment - - edited Just wanted to suggest that we could add a few more color-related (abstract) methods to Theme.java so that "setBaseColor" and some other things that currently exist only in TerraTheme.java could be called via a generic "Theme" object (so that the example code can be generic). Reopening the issue for this.
          Hide
          smartini Sandro Martini added a comment -

          Resolved.

          Some small differences in color (index) usage probably are still in TerraTheme. Be free to reopen the issue so we can fix it (if needed).

          Show
          smartini Sandro Martini added a comment - Resolved. Some small differences in color (index) usage probably are still in TerraTheme. Be free to reopen the issue so we can fix it (if needed).
          Hide
          smartini Sandro Martini added a comment - - edited

          Committed (at revision: 1536363) new methods for Theme and TerraTheme, and add a sample usage in ColorSchemeBuilder Demo, and retrofitted even ColorPaletteTest.

          Note that all work on adding a boolean isThemeDark() and related work in json theme configuration file still it's missing. If wanted please write here (and reopen/open a new open linked to this issue).

          Note that in TerraTheme there could be many things to retrofit too, but not now (probably a dedicated jira issue). Anyway this could be useful for other Themes.

          Show
          smartini Sandro Martini added a comment - - edited Committed (at revision: 1536363) new methods for Theme and TerraTheme, and add a sample usage in ColorSchemeBuilder Demo, and retrofitted even ColorPaletteTest. Note that all work on adding a boolean isThemeDark() and related work in json theme configuration file still it's missing. If wanted please write here (and reopen/open a new open linked to this issue). Note that in TerraTheme there could be many things to retrofit too, but not now (probably a dedicated jira issue). Anyway this could be useful for other Themes.
          Hide
          smartini Sandro Martini added a comment -

          updated patch (and simplified a little)

          Show
          smartini Sandro Martini added a comment - updated patch (and simplified a little)
          Hide
          smartini Sandro Martini added a comment -

          patch (to implement in theme, and show a sample of) of a small enhancements on theme colors

          Show
          smartini Sandro Martini added a comment - patch (to implement in theme, and show a sample of) of a small enhancements on theme colors
          Hide
          smartini Sandro Martini added a comment - - edited

          In Theme and TerraTheme, add the ability to load (from json files) even a dark boolean attribute (and a public method isThemeDark), so skin implementors can see what to do in case the skin is dark (maybe for the color choosen in the json file, default false = light skin): for example if the skin in not dark, use white, otherwise use black, as useful defaults.

          Note that in wtk (and even in wtk-terra), there are many defaults where the color is fixed by code to Color.BLACK or something other ... but with the dark concept we could at least create a method to get the right color, depending on it ... and to generalize this concept (maybe in future) we could even calculate the contrast between two colors, and return one that has enough contrast, just as useful defaults.

          Show
          smartini Sandro Martini added a comment - - edited In Theme and TerraTheme, add the ability to load (from json files) even a dark boolean attribute (and a public method isThemeDark), so skin implementors can see what to do in case the skin is dark (maybe for the color choosen in the json file, default false = light skin): for example if the skin in not dark, use white, otherwise use black, as useful defaults. Note that in wtk (and even in wtk-terra), there are many defaults where the color is fixed by code to Color.BLACK or something other ... but with the dark concept we could at least create a method to get the right color, depending on it ... and to generalize this concept (maybe in future) we could even calculate the contrast between two colors, and return one that has enough contrast, just as useful defaults.
          Hide
          smartini Sandro Martini added a comment -

          generalization of (how to get the) number of available colors in Theme, TerraTheme, and applying it in ComponentExplorer, as a sample usage (instead of hard-coding Terra-dependent constants).

          Show
          smartini Sandro Martini added a comment - generalization of (how to get the) number of available colors in Theme, TerraTheme, and applying it in ComponentExplorer, as a sample usage (instead of hard-coding Terra-dependent constants).
          Hide
          gbrown Greg Brown added a comment -

          FYI, the corner isn't part of the header - it is drawn by the ScrollPane.

          Show
          gbrown Greg Brown added a comment - FYI, the corner isn't part of the header - it is drawn by the ScrollPane.
          Hide
          smartini Sandro Martini added a comment -

          Probably even the upper right corner of tables could be drawn in the same way of other header columns, to look it like other headers ...

          Show
          smartini Sandro Martini added a comment - Probably even the upper right corner of tables could be drawn in the same way of other header columns, to look it like other headers ...
          Hide
          smartini Sandro Martini added a comment -

          Some (old, in part obsolete now) discussion here: "little change on theme color usage for some elements"
          http://apache-pivot-developers.417237.n3.nabble.com/little-change-on-theme-color-usage-for-some-elements-td1645828.html#a1648963

          Show
          smartini Sandro Martini added a comment - Some (old, in part obsolete now) discussion here: "little change on theme color usage for some elements" http://apache-pivot-developers.417237.n3.nabble.com/little-change-on-theme-color-usage-for-some-elements-td1645828.html#a1648963

            People

            • Assignee:
              smartini Sandro Martini
              Reporter:
              smartini Sandro Martini
            • Votes:
              0 Vote for this issue
              Watchers:
              2 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development