The latest 6.1dev drop of Substance look-and-feel library (code named Trinidad) completes the collection of skins that can be used on the Flamingo ribbon component by adding Office Black 2007 skin to the existing Office Silver 2007 and Office Blue 2007 skins. Here is how the ribbon looks under Office Black 2007 skin:
This skin lives (as all others) in the org.pushingpixels.substance.api.skin and can be used with the following:
- SubstanceLookAndFeel.setSkin(new OfficeBlack2007Skin())
- SubstanceLookAndFeel.setSkin(“org.pushingpixels.substance.api.
skin.OfficeBlack2007Skin”)
- -Dswing.defaultlaf=org.pushingpixels.substance.api.
skin.SubstanceOfficeBlack2007LookAndFeel
- UIManager.setLookAndFeel(new SubstanceOfficeBlack2007LookAndFeel())
- UIManager.setLookAndFeel(“org.pushingpixels.substance.api.
skin.SubstanceOfficeBlack2007LookAndFeel”);
As with the existing Office skins, the new skin is exclusively targeting the ribbon component. Its usage on the core Swing components is not recommended. The next major Substance release will move all three Office skins to the Substance Flamingo plugin.
If you want to test the new Office Black 2007 skin in your ribbon, you will need the following:
When two products are developed by the same company / team / a lonely guy in his mom’s basement, you expect them to work well together. In my case, i develop Flamingo component suite and Substance look-and-feel – both targeting modern Swing-based UI applications. To achieve better integration between the two products, i provide three main features:
- Hosting some of the ribbon content (application menu button, taskbar panel and contextual ribbon task group headers) in the title pane of a decorated ribbon frame
- Office Blue 2007 and Office Silver 2007 skins that specifically target Flamingo ribbon component. When you use these skins in your ribbon-based applications, the visuals should be pretty close to the look of the matching MS Office 2007 skins.
- Substance Flamingo plugin that provides consistent appearance and animation effects found in the base Substance library.
While the main focus of Substance Flamingo plugin was on hosting content in the title pane, the two Office skins and consistent animation effects, the latest development drops of all three libraries provide much better visuals for the ribbon component under other core Substance skins, especially those that mix dark and light color schemes in different areas of your UI.
Here is the ribbon under Business Black Steel skin:
And the same ribbon under Dust skin:
And the same ribbon under Dust Coffee skin:
And the same ribbon under Gemini skin:
And the same ribbon under Twilight skin:
The ribbon also looks much better under other Substance skins such as Autumn:
and Business:
I plan to release Substance 6.1 and Flamingo 5.0 at the same time around end of July / beginning of August. You should expect even closer integration between these two projects to be provided by the Substance Flamingo plugin as the projects get nearer the code freeze state.
If you want to test the improved visuals in ribbon-based applications, you will need the following:
Bear with me for a moment. There’s this guy sitting in a bar. He doesn’t have any money to pay for the drinks, and nobody wants to invite him to join their table. Thinking about what he can do, he sees a bunch of guys from Mongolia sitting around a table full of food and alcohol. Strolling over, he asks them: “Do you want to hear a story about a fight between a russian warrior and a mongol warrior”? Half ignoring him, they say “whatever, go ahead”.
“And so the story goes that a russian warrior and a mongol warrior met for a fight. The mongol struck the russian, and the russian sunk into the ground up to his ankles”. The mongols are starting to pay some interest, and give the guy a small drink. After finishing the drink the guy continues. “The mongol strikes the russian one more time, and the russian sinks into the ground up to his knees”. The mongols give him some food and more to drink. “He strikes him the third time, and the russian sinks into the ground up to his chest”.
Now the mongols are really happy, giving him some steak to eat and more to drink. The guy starts getting drunk and relaxed, and continues the story. “Now it’s time for the russian. He strikes him once, but the mongol stands. Immovable, unshaken”. The mongols keep on giving him more food and alcohol. “The russian strikes once more, but the mongol stands. Immovable, unshaken”. They give him all their food, captivated by the story. The guy keeps on drinking. “The russian strikes the third time, but the mongol stands. Immovable, unshaken”. The mongols are ecstatic, unable to contain their joy. The guy is done with eating and drinking, and leans back to rest. The mongols are urging him to continue the story and keep on asking him what’s next. The guy says: “What’s next? The mongol stands. Immovable, unshaken. With only his ears above the ground”. (*)
Which brings me to Swing. The last 18 months have seen little change in the direction of the core Swing library – maintenance and bug fixing. With every passing milestone of JDK 7, more and more Swing features have been removed from the feature list. Swing application framework, SwingX painters and new components all fell to the side. And while there have been a number of bug fixes in the last few months, the only public API enhancements in core Swing are shaped / translucent windows (an API that has been promoted from 6u10+ to be public) and JLayer (an almost direct port of JXLayer).
In the meantime, we’re not going to see any of:
- Components such as date picker, month view, task panes, split buttons.
- A modern (HTML 5 / CSS 3) browser component.
- Form / grid oriented layout managers.
- Binding.
- Video playback / recording.
- Docking / windowing.
- API enhancements to the table component.
Given how much is going on with JavaFX, this is not really surprising. This just confirms what i said before. Core Swing is in feature freeze, immovable, unshaken. It is a solid foundation, and lends itself quite easily to external third-party enhancements. But as far as the core feature set – it’s not going anywhere. A couple of random observations.
Since Oracle acquisition, the bug fixing pace has definitely picked up. There’s a bunch of bugs being fixed in both Swing and Java2D. On the other hand, JavaFX has Prism, a new rendering pipeline for mobile, desktop and TV stacks. While Swing / Java2D has been the foundation of JavaFX desktop profile before, and we enjoyed incidental performance improvements and bug fixes as the result, it’s not going to last for very long. New composites, hardware acceleration, new graphic primitives are unlikely to be ported and maintained in two different pipelines. And i would imagine that internally Prism also has quite a few different backends, each one optimized for the specific graphics hardware – meaning more work in the foreseeable future outside the existing Java2D backends.
NetBeans is an interesting beast. A solid foundation for writing modular boring business applications, it has not seen any of its features ported to core Swing. We’re talking about docking, windowing, sliding palettes, layouts, application framework and more. If the crossover has not happened until now, how likely is it that it will happen in the future? Speculating widely, recently rumored cuts in european / asian offices may jeopardize the future of NetBeans – which, to the best of my knowledge, is mainly developed in Prague. And don’t forget that Oracle has its own JDeveloper IDE. The only hope for NetBeans would be if they position themselves as the platform for JavaFX development. Given Eclipse’s dominance presence outside the internal bubble, how long will it be before the internal investment in NetBeans is reconsidered in this profit-oriented environment?
And what’s up with an embeddable browser component? Seriously, everybody is doing it. WebKit must be exposed in a gazillion other UI toolkits by now. Big companies are doing it. Small companies are doing it. It’s been what? Two, three years? If this is still going on internally, and you’re thinking to somehow monetize your investment, you can forget about it. Open source it now, and let people help you. You’re not really thinking that this port is going to be so unique that companies will be lining up to pay top dollar to license it.
(*) Russian readers not familiar with the joke can find the original here (number 48). This is not really politically correct, but i’m sure that every folklore has its own version.
Trident aims to be a general-purpose animation library for Java applications. However, most of the time people talk and refer to animations in the context of pixels on the screen, be it for transitions between different states, rollover effects, smooth scrolling of large content and what not. Trident comes with built-in support for Java based UI toolkits. The three UI specific requirements are addressed by the core Trident library:
- Automatically respecting the threading rules of the UI toolkits
- Providing property interpolators for classes that represent graphical objects of the UI toolkits
- Repainting application windows that have continuous animations
Today i’m going to talk about the last point – repainting application windows. Trident has two special timelines – org.pushingpixels.trident.swing.SwingRepaintTimeline and org.pushingpixels.trident.swt.SWTRepaintTimeline. These are simple utility timelines that can be used to continuously repaint the contents of the specific window / component on every timeline pulse. For example, if you have a continuous emulation of fireworks, you can have “worker” timelines updating the model objects that represent the firework volleys, and one repaint timeline that updates the entire screen based on the current state of all firework volley model objects. This allows you to separate the model updates from the view updates.
However, as Rob Eden pointed out to me this week, these two classes repaint the window / component on every timeline pulse. This can result in unnecessary repaints if the model updates are not done on every timeline pulse as well. In the “snake” example, the model is updated only when the mouse is moving. Once the mouse has stopped moving and all rollover timelines are done, there are no changes to the model, and continuously repainting the screen consumes unnecessary CPU resources.
To address this, both SwingRepaintTimeline and SWTRepaintTimeline now have three new APIs:
- setAutoRepaintMode(boolean) – by default the auto repaint mode is true. Application that wishes to control the repaint will call this method with false.
- forceRepaintAtNextPulse() – will make the repaint() / redraw() call when the next pulse is fired. This will throw an exception if the timeline is in auto-repaint mode.
- setRepaintRectangle(Rectangle) – allows to dynamically change the rectangle to be repainted. Can be used if the bounds of the view that represents the specific model can change dynamically (e.g. when the user resizes the application window).
The snake examples for both Swing and SWT have been updated to show the recommended usage of the first two APIs. Click the button below to run the WebStart version of the Swing demo:
If you’re interested in testing this functionality in your application, take the latest 1.3dev drop (code named Diamond In The Sky) for a spin.
