Here are some Swing links that you might have missed during the last week:
- The discontent about timely and transparent disclosure of long-term plans for Swing is growing, and this week Geertjan Wielenga vents his frustration about the uncertain future of Swing in light of the Sun’s push for JavaFX as the apparent future of Java on desktop.
- Andres Almiray has been hard at work with the Groovy builders for various third-party Swing components. He released version 2.1 of jideBuilder, has started work on the MacWidgetsBuilder, and showcases a few screenshots of the SwingPad 0.2.
- Alex Ruiz kicks off a new series about testing JavaFX UIs by extending his FEST Swing library.
- Jean Francois Poilpret is wondering whether it’s time to fork the SwingLayout project and start fixing its bugs. I can only speak for my own open-source projects (Substance and Flamingo), but i have found a surprisingly insignificant resistance to Java 6 as the minimum runtime requirement. This may be due to a relatively low usage of these two libraries, or this may be due to greater flexibility of runtime environments on the client side Java.
- And finally, Yves Zoundi has announced two new releases of his projects. XPontus XML editor has reached release 1.0.0.2, and VFSJFileChooser remote file chooser component has reached release 0.0.4.
If you’re following my Twitter stream, you know that over the last few days i have been working to bring the Office Blue skin of Substance look-and-feel closer to the original visuals. The original visuals for Office 2007 built-in skins are comprised of hundreds of hand-crafted images and around 1500 colors, and are quite a challenge to reproduce even with the rich skinning APIs of Substance.
Here is a screenshot of the old Office Blue skin:
While the overall direction is right (washed blues + a combination of yellow / orange colors for active states), it was quite off in both hue and saturation.
Here is how it looks in the latest 5.1dev drop of Substance (code-named Panama):
Office Blue skin is by far the most complicated Substance skin, and uncovered deficiencies in the core library as far as the skinning flexibility goes. The most visible change is breaking the API of highlight painters to add two new parameters (for passing the border color schemes). All the other changes are additive, bringing more control over the definition of color scheme bundles.
You can now associate the following three new types of color schemes with each component state (see the SubstanceColorSchemeBundle and OfficeBlue2007Skin for more details):
- Color schemes for marks (check marks, arrow icons, …)
- Color schemes for tabs (see the white fill of the selected tab)
- Border color schemes for tabs (run the WebStart demo below and move the mouse over the selected tab to see the orange glow)
At the present moment, the Office Blue skin is defined by fifteen different color schemes that cover thirty six different component state configurations. Additional color schemes may be added later to further tweak the visuals.
As with Substance 5.0, performance is the major factor. Adding the new color scheme kinds and component state combinations introduces about 0.8% performance degradation to the skins that do not use them, and about 2.1% to the skins that do. I do believe that the new fine tuned control over defining the visual aspects of your custom skins is worth it, and i will try to bring the numbers down until the final 5.1 release (set to coincide with the final 4.0 release of Flamingo).
The final piece is a new visual tool to assist in defining Substance color schemes based on the existing designs. It is called Jitterbug and will be properly introduced next week. You can create a new color scheme with Jitterbug in under a minute, and all fifteen color schemes of the new Office Blue skin were created with it.
To see the new Office Blue skin in action on the Flamingo ribbon component, run the following WebStart demo:
If you want to test new visuals and APIs, you will need to take the latest 5.1dev drop of Substance (code-named Panama).
The original “Java desktop wishlist for 2008” was posted a little more than a year ago, and today i am reposting it in its entirety. You can see the reasons why at the end.
While the Java blogosphere is raging with debates on closures, properties and other negligible language-level features, the client-side battle is still fought between Microsoft, Adobe and Apple. And while finally Sun decided to step in with JavaFX and improved applet handling, this will change little without the tools for content handling.
As i already said, the customers don’t care about the technology. In “The Agnostic Geek“, Brandon Carson writes:
when you look at a web page, do you think, “Gee, I wonder if they coded this in BBEdit or Dreamweaver?” I don’t know about you, but I don’t give a flip what software product is used to create a web page. Use TextEdit for all I care.
And so, who cares that the applets will load instantly when there are so few good applets? Just look at the amazing breadth of Flash content created by professional designers. Content that has rich multimedia capabilities. Capabilities that come built in with the platform. Platform that is oriented towards content.
So, what are my top two wishes for Java desktop for 2008?
Number one: Cross-platform support for H.264 and FLV formats.
Showing is good, but it also must support creating the content and editing the content (just look at the Sliverlight demoes). And don’t tell me that 99.9% of the market doesn’t need editing. If you want to lead the market, you have to cover everything that the competition has and then some.
I don’t know about the licensing issues, but the reference implementation for H.264 is not that big. And Onavia already has pure-Java player. So it can’t be that hard once you decide to put as many resources on that as you do on JavaFX. And even better, accelerate it with OpenGL and Direct3D, while at the same time gracefully degrading to software loops on older cards.
Number two: Converters and viewers for competing markup formats.
You know what i’m talking about – those pesky competitors that have 99.9% percent of the consumer-facing rich desktop market. Flash / SWF, Flex / MXML and WPF / XAML. Each has its own set of designer tools for creating rich content. Each has armies of professional designers versatile in using those tools, in addition to Photoshop, Maya and others. Do you really expect them to master yet another (unproven) designer tool?
If JavaFX wants to have a fighting chance, it needs to provide a simple migration path. A path that allows taking an existing Flex / Silverlight application and importing it to JavaFX (at least the visuals). XAML has at least three – converter from Maya, converter from Photoshop and converter from SWF. The importing is not enough. You have to have exporting as well. If you’re not convinced, read what Joel Spolsky says about how Excel managed to overpower Lotus:
And this reminded me of Excel’s tipping point, which happened around the time of Excel 4.0. And the biggest reason was that Excel 4.0 was the first version of Excel that could write Lotus spreadsheets transparently.
Yep, you heard me. Write. Not read. It turns out that what was stopping people from switching to Excel was that everybody else they worked with was still using Lotus 123. They didn’t want a product that would create spreadsheets that nobody else could read: a classic Chicken and Egg problem. When you’re the lone Excel fan in a company where everyone else is using 123, even if you love Excel, you can’t switch until you can participate in the 123 ecology.
If you want to have professional designers to switch to JavaFX, provide a clear path back. Not that they’ll take it (of course, if the tools and the runtime are bad, they will), but it will give them a nice sense of security.
An extra step would be to allow using the same exact content at runtime without converting it to JavaFX. Soyatec does it partially for XAML, so it can be done. But if you do it, support the complete feature set (including 3D and, guess what, rich multimedia). A bonus part would be to include a bitmap to SVG converter – see VectorMagic for inspiration.
That’s it. I have only two wishes. Granted, these are two big hefty wishes. Will they come true? The first one might partially be, and the second one is highly unlikely.
So, why the repost? The reasons are quite simple – these two wishes have not been addressed in 2008.
Yesterday’s entry has marked the completion of all planned core features for the version 4.0 of Flamingo component suite (code named Fainnear). Here is a short list of all the features that have been added to Flamingo ribbon component – click on each feature to see the screenshots and the relevant APIs.
The ribbon component is ready for application testing and feedback. Release candidate is scheduled for January 26 and the final release is scheduled for February 9.
To see the Flamingo ribbon component in action under core look-and-feels, run the following WebStart demo:
To see the Flamingo ribbon component in action under Substance look-and-feel, run the following WebStart demo:
If you want to test the ribbon in your applications, you would need the following (the last two only for applications running under Substance look-and-feel):
