Better visuals for the JRibbon component, part II

October 23rd, 2007 | 5 Comments »

In the first part, i showed a few screenshots of the new look of the JRibbon component under Substance look-and-feel. Continuing the series, today i’m going to show an additional new feature that allows creating less intrusive UIs with the JRibbon.

Substance already has a client property that you can install on a specific component or globally on the UIManager. When the USE_THEMED_DEFAULT_ICONS property is set to Boolean.TRUE, the button icons of buttons in default state (not rolled over, not selected, not pressed) are colorized with the colors of the current theme. This works especially well under low-contrast skins such as Raven Graphite or Autumn, and now it is also supported on the JRibbon button components.

Here is a screenshot of the JRibbon component under the Raven Graphite skin when the USE_THEMED_DEFAULT_ICONS client property is not specified. As you can see, the icons are fully colored, which results in a slightly intrusive UI:

Here is the same UI when this property is set:

And here is the same UI when the mouse is hovering over the “Paste” button:

Here is the original full-color UI under the Autumn skin:

And the same UI with the property set:

And the same UI with the mouse hovering over the “Computer” icon:

Here is the original full-color UI under the Creme skin:

And the same UI with the property set:

And the same UI with the mouse hovering over the “Computer” icon:

Want to take it for a spin? You’ll need the latest binaries of Substance, Flamingo and Substance Flamingo plugin.

Related posts:

  1. Better visuals for the JRibbon component, part I It’s been more than two years since i first started working on all-Java version of...
  2. Better visuals for the JRibbon component, part III This is the third part of the series on new visuals for the JRibbon component...
  3. Polishing the visuals of Flamingo command buttons As the name of this very blog implies, perhaps the most enjoyable part of my...
  4. From Photoshop to code – step 5, polishing the visuals In this entry i’m going to talk about the fifth step in the process of...

5 Comments on “Better visuals for the JRibbon component, part II”

  1. 1 Aloys Oberthuer said at 11:36 pm on October 23rd, 2007:

    Looks fantastic – gave it a try rightaway. Wouldn’t it make sense to apply this also to menus and menuitems? The menus kind of look intrusive now compared with the rest of the UI.

    Many regards, keep up the brilliant work!

  2. 2 Kirill Grouchnikov said at 11:40 pm on October 23rd, 2007:

    Aloys – it’s on the to-do list for the next Substance version.

    Thanks
    Kirill

  3. 3 Aloys Oberthuer said at 11:44 pm on October 23rd, 2007:

    That is good to hear. Btw., I still owe you a few screenshots for your Substance sightings, it is just that I am still busy tweaking the UI ;-)

    Thanks!

  4. 4 Greg Tangey said at 11:54 pm on October 24th, 2007:

    While this seems great and also, looks alot better than using the icons in their full colour state. the problem with it is the icons are so washed out, the buttons now seems as if they’re in a disabled state in your screenshot.

    This may not seem like a big deal, but it is, it makes the interface confusing. I definately like where you’re heading with this kirill, but i can’t say it’s the best solution, it definately needs a bit more work ;)

  5. 5 Kirill Grouchnikov said at 12:07 am on October 25th, 2007:

    Greg – it all depends on the brightness spectrum of the specific skin. Some skins (such as Autumn, for example), has colors that differ in the brightness more than other skins (such as Creme, for example). Under the former, themed icons look crisper and not so much “disabled” as under the later.

    If this feature is adopted by Substance users, i can think about providing an API to plug a custom icon colorizer. This way, the application that targets a specific skin will be able to control how the icons are colorized. The current core implementation is generic for all the skins – perhaps it should be internally tweaked on per-skin basis to better account for the brightness differences.

    Thanks
    Kirill