The Java desktop team at Sun has not been very active in the blogosphere as of late, providing only a few hints of what will be added to the 6.0 update N. The biggest pieces available so far in the (not so) weekly drops were the Nimbus look-and-feel and Direct3D-accelerated pipeline for Windows. Not much else has been officially confirmed, with hints being dropped on media support and importing artwork from Adobe tools.
Sun has put a significant amount of effort into open-sourcing the JDK (OpenJDK project) and proclaiming that anybody can chip in and contribute to the project. Sadly, the current state of affairs is not quite so close to what the marketing / evangelizing would lead you to believe. One of the biggest obstacles for the community is the planning / scoping process for both 6.0 update N (which is not part of OpenJDK if i understand correctly) and 7.0. Sure, one can always pick the low-hanging fruit from the bug parade, but what about people who want to work on new features (in JDK in general and in desktop in particular)? Why would anyone want to start working on adding a new feature in his private Mercurial forest (or whatever it’s called) when he can’t be sure that the same feature is not being worked on by the core team?
This brings me to pretty much the only “peephole” into what is going on during the development cycle – the much-maligned bug parade. Thanks to the comments on Ben’s blog entry, i’ve found two quite interesting entries:
6656651 – The Java 2D LCD glyph rasterisation is not the same as that of the customer Cleartype rasteriser. Some of the resulting differences are observable on Vista and XP in applications which utilise the Windows L&F. [Evaluation] This can be fixed by asking GDI to perform the rasterisation of glyphs, then caching these glyphs in the same way as now. This avoids disruption to the various 2D rendering pipelines, particularly its hardware acceleration architecture. This has been verified with software and D3D and OpenGL pipelines, and with SwingSet and Font2DTest. […]
6655001 -When window translucency is enabled for windows with accelerated surfaces the tranlucency doesn’t work well on Windows systems prior to Windows Vista: there are artifacts when a window is dragged away, and it doesn’t appear transparent. Shaped windows work fine. […]
Am i dreaming? Is the first one talking about native font rasterization? Is the second one talking about shaped and translucent top-level windows? Now if only 6633275 hasn’t been marked as private (transparency, transparency, transparency)…
Here are some Swing links that you might have missed during this week:
- Alexander Potochkin continues his work on the advanced overlay functionality. His latest entry describes a solution for disabling Swing containers, including blocking mouse events, focus transitions and keyboard actions. While the proposed solution uses a clever trick (calling JComponent.print() instead of JComponent.paint() to address the double-buffer quirks on some containers), you’ll find some interesting discussion in the comments section. Some applications will result in incorrect painting on components that provide custom implementation of print() and the specific print methods like printComponent().
- Ben Galbraith kicks off an interesting discussion on the quality of AWT font rasterizer. I don’t agree with his recommendation of choosing the UI font based on the rendering quality (especially since the quality is very subjective). If anything, the font family, size, style and rasterization is what makes Swing applications stand apart (and not in a good way) from the native applications, even more than colors and skins do. This is why the native text rasterizer is so important, especially coupled with platform-specific font policy lookup.
- Jeff Friesen writes an overview of the Balloons Tip project at java.net.
- Patrick Gotthardt announces the first beta drop of version 1.1 of Pagosoft look-and-feel.
- Vincent Cobra announces his new project that aims to provide a file chooser component based on the Apache Commons VFS library.
I had only two things on my Java desktop wishlist for 2008 – cross-platform support for H.264 / FLV formats and converters / viewers for competing markup formats. To quote myself on the second wish
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).
Is it possible that this is becoming a reality? Here is what James Gosling said to Register Developer during the Mobile & Embedded developer day:
We are putting a lot of effort into interoperability with the Adobe tools – a lot of the Adobe tools are wired into the neurons of the artists of the world, […] We are not trying to be a completely isolated island that has all the tools for everybody.
Obviously, this is completely open to interpretation and speculation, and we’ll have to wait for the grand announcement(s) at this year’s JavaOne. My read on this is that Sun will provide a set of plugins to Adobe tools that will allow exporting art as JavaFX and SceneGraph code. And instead of focusing on creating visual tools for the designers, Sun will put the effort in the programmer’s half of the tool chain.
Only time will tell…
The release candidate for version 4.2 of Substance look-and-feel (code-named Memphis) is available. The list of new features includes:
Target date for release is February 4. Only defects will be fixed until this date.
In addition to the core release candidate, the following Substance plugins and modules have been updated as well:
