Here are some Swing links that you might have missed during the last week:
- Roman Kennke posts an update on the Java2D stack on VxWorks which is now functional enough to run SwingSet2. The followup post has more screenshots of SwingSet2 running under JamaicaVM and OpenJDK stack.
- Looks like JavaFX development is going to bring performance improvements back to Java2D and Swing applications. Bug 6766336 aims to use SSE / MMX CPU instructions to speed up the software pipeline – i have mentioned that while the new Direct3D-accelerated pipeline is great for the modern hardware, the “enterprise” desktops usually only have integrated cards. Bug 6766342 aims to improve the (closed-source) Ductus rasterizer on anti-aliased paths, while bugs 6767500, 6767506 and 6767516 aim to improve performance of various primitives on the hardware accelerated pipelines.
- An interesting bug (6740419) has been opened to provide better control over text grid fitting in Java2D. The subject of printing fidelity has been addressed at length last year by Jeff Atwood and Joel Spolsky, and it looks like the designer team behind JavaFX is pushing for Apple-style font rendering in JavaFX. I have already talked about why it is a bad idea, and the introduction of DirectWrite in Windows 7 (more on this in a later post) will obviate the need to invest the precious time in supporting this feature in JavaFX.
- Jean Francois Poilpret has announced release candidate for release 1.0 of DesignGridLayout.
- Adam Bien compares Eclipse RCP and NetBeans RCP and leans towards the later in his recommendations. I don’t have any experience with NetBeans RCP, but i’ve been doing heavy Eclipse / SWT work over the last three years at work. I have almost never considered SWT / Eclipse to be more limiting that Swing. In fact, once you understand that it’s better not to fight the platform and instead tweak your design to match the recommended UI guidelines of the platform (re vertical labels in tables), you will find SWT / JFace combination (especially with the Instantiations designer) a very productive and enjoyable environment. Not to mention that you can most certainly create non-Eclipse looking SWT applications, and this is going to be much easier in the near future.
- Ayman Al-Sairafi has announced release 0.9.3 of the JSyntaxPane component. New in this release – line numbering, reworked Find / Replace dialog and support for Python, C, C++ and Ruby syntax.
Finally, if you are interested in the responses to my posting on the state of core Swing, you’re welcome to read the following:
And Dale Beermann has an interesting series about moving a large Java project to Flash and ActionScript. The first post addresses the reasons why this port has been done, while part 2, part 3 and part 4 (ongoing series) address the specific technical issues in porting Java code to ActionScript.
Once a subject of heated discussions, the native vs. cross-platform skinning has not been mentioned for quite some time in Swing blogosphere. While this post by no means aims to revive the dead ghosts, i saw something quite interesting in the PDC session on the Windows 7 Explorer. It looks like (at least in the current builds) Microsoft has decided to enforce better consistency across the UI layer of its flagship desktop products, including Office and Media Player. This specific issue has been brought as one of the major arguments against using a native look-and-feel (because the lack of consistency effectively meant that there is no native look-and-feel).
The following three screenshots show (what i presume to be) the next version of Office running on Windows 7. These were taken from the video stream and the quality is not the best, but the overall trend is still quite noticeable. The landmark Office ribbon that was skinnable as silver / blue / black in Office 2007 is now consistent with the platform look-and-feel (read more about the scenic ribbon in the PowerPoint slides of this PDC session). I’m not sure whether the presenter meant to show the new look of Office, or even if this is the final look. However, the screenshots clearly show that the ribbon UI is now much more consistent with the the rest of OS, including the colors, gradients, the glass chrome on the title pane and other UI bits (click to see full size view):
The same goes for the Windows Media Player. The screenshot below (click for full size view) shows a somewhat partial UI in the top bar (no icons on the twin round buttons), but the heavy glossy black / dark blue chrome found in the current Media Player UI is (at least for now) gone:
Standardizing the UI look of different bundled and add-on programs in Windows 7 is an interesting trend that is worth following in the months to come.
This blog is about putting pixels on screen. If i need to choose between getting a bunch of finished images from a graphics designer and hand coding each and every pixels in the code, you know my choice. We must, however, acknowledge our limitations and strive to better our understanding of what a good design is. Only exceedingly few have equal talent and passion for both design and programming, but the rest of us can at least try and learn from the best minds on the other side of “the fence”.
Below you will find links to twenty design sites and blogs that i currently follow. Unfortunately, the lack of time has me use an RSS reader, and as such a site that does not publish full article feeds is simply not going to make it. This might weed out a few good sites, but that is an unfortunate consequence of the information deluge age that we are living in.
The sites are listed alphabetically – click on the banner to visit the site and to subscribe to its RSS feed.
1. 84 Bytes
2. Architectures of Control
3. Beeex
4. Boxes and Arrows
5. Designm.ag
6. Digital Artist Toolbox
7. Freelance Folder
8. Fuel Your Creativity
9. Functioning Form
10. Function Web Design
11. Graphics Design Blog
12. Hongkiat
13. Just Creative Design
14. Observin
15. Outlaw Design Blog
16. Positive Space
17. Smashing Magazine
18. Usability Counts
19. Usability Post
20. Vandelay Design
Core Swing is in the process of being retired as a legacy UI technology inside Sun, and last week has marked another sad (yet expected) milestone. According to Jeanette Winzenburg‘s post on the SwingLabs java.net forum, Sun has stopped funding of the SwingX project.
Announced at JavaOne 2004 under the JDNC brand, SwingLabs has been widely considered as a breeding ground for modern UI technologies (new components, markup language, binding etc) for later inclusion in the core JDK distribution. It has enjoyed significant attention from the Swing community, drawing dozens of outside developers to contribute code and discuss various approaches to provide modern, rich and customizable components. Perhaps the culmination of these discussions happened in 2006 around the painters. The community members (IMHO) have truly believed that SwingX is being officially regarded inside Sun as a gateway for those contributions to find their way into the core Swing, and the level of excitement was clearly visible throughout the well argumented and heated discussions about the painters.
In my view, the turning point has come in January 2007 when it was announced that Sun unilaterally has decided to remove the entire painter layer from SwingX. This has effectively destroyed the trust of external contributors, who never came back, even after Sun developers have retired themselves from being involved in the project. In this light, Amy’s comment on Jeanette’s thread is a little misguided:
SwingLabs isn’t being shut down and SwingX isn’t going anywhere — it’s a great extensions library that exists because the community drove the development in the direction they needed. I don’t see that ending.
In fact, that single internal decision that completely disregarded the whole year of discussions was the most unfortunate moment in the project’s history. Looking back, it is even more unfortunate since SwingX components are not going to be part of core Swing (more on this later). Up until that moment the community has believed that it had an equal say in the development direction. After that moment most of the community has left, and a few months later Sun has decided on the new direction – JavaFX.
I don’t know what the future holds for JavaFX. Sun is heavily betting on it, and nobody wants to have their Nomad moment forever archived on the Internet. All i know is that JavaFX has effectively halted all core Swing development. Over the last 18 months, we have seen significant architectural initiatives (JSR 295 and JSR 296) changing leads and frozen. All client-facing improvements in Java2D, AWT and Swing in Java 6 Update 10 are completely driven by the requirements of JavaFX. In Richard’s own words (the same thread on SwingX funding):
Swing is part of the JDK. It isn’t going away any time soon. For a great many large enterprise applications Swing is the best cross platform toolkit available. We’ll continue to support and work on fixing bugs in the JDK.
It can’t get any clearer – the only two active areas of Swing core work is support and bug fixing. You might say that things will change once JavaFX 1.0 is out the door, but this is quite unlikely. JavaFX has a lot of ground to cover if it is to compete with Adobe and Microsoft, and it has even more ambitious plans for mobile and set top environments. In Richard’s words:
Definitely no question that there is a lot of working going into JavaFX and will continue to happen.
What do i see happening? I think that the current core Swing feature set should be considered frozen, until shown otherwise (not in words, but in actions). Swing is an extremely well written and customizable UI toolkit, and it is a solid candidate when you consider writing your next UI application. However, the innovation must come from third-party developers, be it binding, application framework, components or markup language. As the Swing Links trail on this blog shows, there is a lot of external activity in this area.
I think that core Swing has become a victim to Sun’s outdatedly rigid policy on the backwards compatibility. I have written about this topic in the Substance users mailing list a few weeks ago:
The eternal fear of Java core libraries is to never break existing applications (by the way, the Swing forums are rife with examples of applications that break when migrated to a newer JDK versions; it doesn’t have to be EDT violations, something as simple as event firing condition due to a bug fix is enough). This fear has us stuck with Ocean as the default look-and-feel. This fear has us stuck with tons of deprecated APIs that unnecessarily complicate the learning curve for the novice users (how many ways to catch an Enter key on text field?) This fear has us stuck with obsolete layout managers (gridbag, spring). And by the way, this fear also prevents the core developers from adding new functionality out of the fear itself that they might get it wrong the first time and get stuck with it forever.
Like i said before, in the grand scheme of things, it all doesn’t matter. Technologies die, new technologies are born, people move to other companies, old prejudices refuse to die and some decisions are forced on technical people. The customers, of course, couldn’t care less about all this.
