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):
The latest addition in the Flamingo component suite is support for core Swing components. This has been the last unaddressed item on the roadmap for version 4.0 (code named Fainnear), and is now available in the latest 4.0dev drop of Flamingo core and 5.1dev drop of Substance Flamingo plugin.
First, there is a new notion of groups in ribbon bands. This allows fine-tuning the layout of larger ribbon bands, grouping associated controls while still not breaking the groups across multiple ribbon bands. Ribbon band groups are separated with vertical separators and are started with the new JRibbonBand.startGroup() API. Here is a screenshot of a ribbon band with two groups:
Here is a screenshot of another ribbon band, with two groups as well:
And here is a screenshot of a ribbon band with three groups:
As you can see, you can vary the priority of command buttons across the different ribbon band groups.
The new JFlowRibbonBand class allows placing flowing content in a ribbon band. Unlike the JRibbonBand, it can host any core or third-party Swing component. It is highly recommended to use components that do not take too much vertical space (good examples are buttons, combo boxes, radio buttons, checkboxes, spinners). The new CoreRibbonResizePolicies.getCoreFlowPoliciesRestrictive API can be used to install a resize policy that first tries to place the controls in two rows, and then, if there is not enough horizontal space, will place the controls in three rows.
Here is a screenshot of a flow ribbon band with enough horizontal space to host all the controls in two rows:
When the ribbon is resized, the content of this band will be placed in three rows as necessary:
Support for placing keytips on the flow ribbon band content is aligned with placing the keytips of the command buttons on regular ribbon bands. Here is a screenshot of flow ribbon band keytips with two rows:
As you can see, the keytips for both the top row and the bottom row are aligned, resulting in a consistent UI appearance. As a side note, to associate a keytip with a core Swing component, wrap it with JRibbonComponent (more on this below).
And here is a screenshot of the same flow ribbon band with three rows:
It is now possible to add core Swing components into regular JRibbonBands. To do so, you need to wrap such a component with the new JRibbonComponent class. In the simple case, use the constructor that takes a JComponent to create a ribbon band like this:
You can also associate an icon and a caption with the core Swing component that you want to add to the ribbon band. For this, use the JRibbonComponent constructor that takes three parameters to create ribbon bands like these:
In this screenshot, the first ribbon band hosts three JRibbonComponents, each one wrapping a JComboBox with a custom icon and caption text. The second ribbon band has two groups, first hosting two JSpinners with associated icons and captions, and the second hosting two JSpinners. The second ribbon band also shows that ribbon band groups can have titles – use the JRibbonBand.startGroup(String) API.
Why do you need to wrap a core Swing component with JRibbonComponent to place it in the JRibbonBand? The answer is – support for keytips and rich tooltips.
The JRibbonComponent.setKeyTip allows associating a keytip with the wrapped component. For simple wrappers, the keytip is shown on the left hand side of the component, vertically aligned with the other keytips shown on the ribbon:
For wrappers that show icons and captions, the keytips are shown between the icon and the caption, vertically aligned with the other keytips shown on the ribbon:
Pressing the key sequence that leads to the specific core component will activate the relevant action. Buttons will be activated (including toggling the selection on toggle buttons, radio buttons and check boxes), comboboxes will show the popup, and other controls will acquire focus.
Finally, the JRibbonComponent.setRichTooltip allows associating a rich tooltip with the icon / caption area of the wrapped component. As with command buttons placed in the ribbon bands, the rich tooltip will be shown below the ribbon so as not to interfere with navigating the UI:
Here, the mouse is hovering over the Right: caption of the left-bottom spinner in the Paragraph ribbon band.
If you want to see the support for core Swing components, flow ribbon bands and ribbon band groups in action under the core look-and-feels, run the following WebStart demo:
If you want to see this functionality under Substance (all the screenshots in this entry were taken under the Nebula skin), run the following WebStart demo:
If you want to test the new functionality in your applications, you would need the following (the last two only for applications running under Substance look-and-feel):
Your feedback is, as always, greatly appreciated.
