Here are some Swing links that you might have missed during the last week:
Finally, Mikael Grev has announced release 3.6.2 of MigLayout manager for Swing and SWT. Mikael has been vigorously pushing for inclusion of this project in the core JDK distribution, amassing an impressive number of 289 votes in the bug parade. I am not quite convinced that it will be a good match. Looking at the available release notes history (since June 08), i see quite a few bugs being fixed (even this very announcement was made on version 3.6.1, with a bug creeping in requiring another minor release), as well as improving support for IDE integration. This is a perfectly normal situation for any project, even when the APIs are frozen as far as the project developers are concerned. Would you want to forego quick bug fixing cycle for a larger audience? Would you want to risk the restrictions of JDK (never breaking the APIs) even you are positively sure right now that this is the final state? These and other related questions don’t have a definitive answer (to witness quite a few API disasters in the core JDK), and tomorrow’s interview (not related to MigLayout) will provide an interesting take.
I’ve talked about LimeWire in the latest installment of Swing Links of the Week, and now it’s time to meet its lead developer, Sam Berlin.
Tell us a little bit about yourself
My name is Sam Berlin. I’ve been working with computers since I was a little kid. The first “program” I wrote was a collection of .bat scripts in DOS for my parents, to let them choose what program to open. I went to college for theater, but after one semester decided I didn’t want to be an actor and switched to computer science and music, then switched again to computer science and philosophy.
I’ve been involved with LimeWire since around 2001, originally contributing patches as an open-source developer. Nowadays I’m the lead developer for the LimeWire client and focus on all aspects of Java delopment (NIO, Swing, concurrency, etc…). LimeWire’s open-source community has fallen off a bit, due to mailing lists not being maintained & the code becoming more complex and difficult to maneuver. I’m making an effort to simplify the code and make it easier for newcomers to comprehend — fortunately that process helps LimeWire’s internal daily development too.
What is LimeWire?
LimeWire is a file-sharing program. It’s open-source (see limewire.org) and written in Java. The company is Lime Wire, LLC and also contains the LimeWire Music Store and a variety of other projects. LimeWire has been around for about a decade. Originally it was compatible with Java 1.1.8 and even ran on Mac OS 8. Today, the project has over a half million lines of code and requires Java 1.6. The most difficult aspect of managing it is that it’s a client application and runs on all sorts of desktops — we can’t target a specific VM or architecture and ignore bugs on other ones.
Why did you decide to go with Swing? If you were to start from the scratch, would you still go with Swing today?
I wasn’t around for the decision to go with Swing in LimeWire 1 (that held through till LimeWire 4), so I can’t comment on that. With LimeWire 5, we effectively did start from scratch. We threw away the entire old branch of GUI code and started fresh. The conception of LimeWire 5’s UI began by evaluating a range of toolkits (QT, SWT, Swing, AIR, and probably a few others I can’t remember). Each one presented its own problems. In the end, we ended up going with Swing after finding the mozswing browser. A browser that worked on all platforms was the last remaining hurdle to using Swing. Of course, as things turned out, it wasn’t all perfect. We decided to require Java 1.6 (for many other reasons), and Apple only decided to release Java for OS X in 64 bit architecture. Because MozSwing uses XULRunner internally, it needs native code bindings — but the native code for XULRunner doesn’t work in 64bit mode because it links to 32bit code in OS X. So we can’t use the browser on OS X.
Still, I’m happy with the choice of Swing.
What are Swing’s weak points in your opinion?
The worst thing about Swing is that it’s too easy to use wrong. This is why, in my opinion, Swing has such a bad reputation. It’s so easy to use, and so easy to use wrong, that millions of amateur hackers have written awful Swing programs and given it a bad smell. (Of course, the fact that the default look and feel felt like you were using a computer in 1990 didn’t help.) Swing is great because it’s so flexible, but the flexibility is really it’s downfall. It’s the classic tradeoff in API development — if you create something confined and limited, the internal code has the flexibility to change and grow without causing errors. On the other hand, if you create with extensions in mind, you allow for hooks and have to be concerned that additions will break the hooks. Swing chose the latter route and it handcuffed internal Swing development.
What functionality is missing from core Swing, and would you want to see third-party libraries folded into the core distribution?
The #1 thing I would like to see, and fortunately it is happening, is JWebPane — a lightweight browser. The fact that it’s not included today is almost absurd. It’s like releasing a new programming language that can’t connect to the internet. As far as third party libraries are concerned, I don’t really care either way if they’re included in core swing or as a standalone enhancement. So long as third-party development continues, it’s effectively in core Swing. The only argument I can make for wanting to have them included is that Sun would be forced to keep them up-to-date and working, but I’d rather that the components remain flexible and changeable as time goes on. Third-party libraries can break API compatibility with major releases (and doing so is often a good thing if the old API had intractable problems), but Sun can’t do that with new Java releases.
Tell us about your experiences with embedding a browser into a Swing application.
It’s been pretty easy. Finding mozswing was the hard part — it’s not advertised anywhere. We learned about it through a blog post about NetBeans. The only catch is the browser is heavyweight, so we have to do some fancy footwork to let things show on top of it. (Apparently in Update 12 Sun has enabled limited heavyweight / lightweight mixing, though I haven’t tried it.) In LimeWire 4.x we embedded the SWT browser on Windows. That worked well enough, but the SWT browser is very limited in how you can configure it. You can’t change the User-Agent, can’t run Javascript, can’t listen for downloads… you pretty much can’t do anything. What’s great about mozswing is it exposes the entirety of XULRunner. We intercept DOM events and open links in native browser when the target is _blank, listen for the progress of the page and show loading animations, etc… The ability to do anything XUL can do is limitless. We even listen for new downloads and show them within LimeWire’s UI, complete with the progress of the download.
What do you think about Sun’s new direction of client Java towards RIA space with JavaFX (called Swing 2.0 by Richard Bair)?
To be honest, I haven’t really looked too deeply into it. It came about just a little too late for LimeWire 5. I think it’s an interesting direction, but I’ll reserve my judgement until people start using it and creating more than simple applets with it. The real important change, I think, is the new Java Plugin — it’s actually good. You can run a Java applet without stalling the browser, and can drag the applet off the browser… that’s pretty cool (and useful).
Have you considered moving to JavaFX at some point in the future?
Not really, but I won’t rule it out.
Is there anything else you would like to add?
Swing isn’t dead, it just isn’t targeted to today’s designers. A designer today doesn’t want to mess with complex application logic, he (or she) just wants to paint something pretty. Swing was unfortunately written before today’s designer existed. Sun’s trying to make up for this with JavaFX (which may very well work), but that doesn’t mean Swing is left in the dust. You can still write an amazing application, but you need to be well disciplined. The approach we took with LimeWire 5 worked very well. We focused on implementing ugly wireframes that performed the functionality, and afterwards went back and painted the UI. It requires some patience to not be turned off by the ugly, and some patience to wait to ship until the pretty is finished… but it pays off. In the end, you’ll end up with a program that is very focused in what it does and how it does it, and has a consistent look & feel.
Here are some Swing links that you might have missed during the last week:
- Chris Adamson provides his own take on my interview with Richard Bair, particularly highlighting Richard’s statement that JavaFX is effectively Swing 2.0. This has also been picked up by Josh Fruhlinger at Javaworld.
- Devoxx has brought some news about the future of SwingX and Swing in JDK 7. As reported by Jan Haderka, Alexander Potochkin will be replacing Richard as the official SwingLabs project lead. In addition, some of the SwingLabs sub-projects will be part of JDK 7. This includes App Framework, JXLayer, Painters API and DatePicker. A gigantic missing piece is the BeansBinding, and this is already being queried by the community – update: see what Richard had to say about this. Another interesting piece is concerning the inclusion of painters, and how they will play with Nimbus’ own painters, as well as the level of possible customization of core Swing components.
- Christopher Deckers has announced release 0.9.7 of DJ Sweet project that aims to bring sophisticated components for SWT. The main focus in this release is the improvement of the Web Browser control, and the addition of a Flash Player with a simple API.
- Alexey Ushakov is the technical lead for JWebPane component, and he has finally revealed tentative availability schedule for this project. Contrary to my prediction, it looks that this component will be lightweight, providing Java2D-based implementation of WebKit painting hooks. Alexey’s comment on licensing issue is questionable at best, and has been discussed briefly by Remy Rakic.
- Alex Ruiz is writing about an interesting usage of FEST Swing library – to analyze the UI hierarchy of JavaFX applications.
- A few months ago there was significant blogosphere activity around using Swing as a foundation to build UIs in JVM-powered languages, such as JRuby, Scala, Jython and Groovy. Unfortunately only one camp has remained steadily active throughout the time – congratulations to Groovyheads for persisting in analyzing the deficiencies of pure Swing development and pushing the envelope. Danno Ferrin has announced release 0.1 beta of Griffon, and Andres Almiray writes about plugin support in Griffon. Andres is also busy experimenting with the builder support for both core Swing and third-party Swing components, and this weeks he has announced two new sub-projects, SwingPad and FlamingoBuilder.
- After last week’s entry on skinning the JScrollBar component, Ken Orr laments the lack of visual tools for assisting the creation of Swing look-and-feels and hopes to see the Nimbus designer released soon. In the comments, Remy Rakic speculates that it will be soon morphed into JavaFX designer.
- Jeremy Wood delves into Java2D, presenting an extensible implementation of charcoal stroke.
And now for the spotlight of the week. Java IDEs such as NetBeans and IDEA has frequently been quoted as examples of large Swing based applications. In the consumer-facing market, perhaps the most widely used application is LimeWire. This week the developers of LimeWire have announced the first alpha drop of the next release. The first two blog entries are out, and hopefully will be followed by more details on the technical implementation and integration of such libraries as SwingX components and painters, Glazed Lists, MigLayout and XULRunner. Click on the thumbnail to see a larger screenshot of LimeWire 5.0alpha.
The latest addition in the Flamingo component suite is support for key tips. This has been one of the items 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.
Key tips is one of the four supported ways to operate the Office 2007 ribbon with keyboard. Unlike the traditional menus-and-toolbars system, every command and control in ribbon can have associated key tip. This allows efficient access and activation of application menu items, task toggle buttons, task bar buttons, task expand buttons and other ribbon sub-components. As specified in the keyboard documentation, the key tip mode is initiated with either Alt or F10 key. Subsequent interaction will be illustrated in the screenshots below taken under the latest 4.0dev drop of Flamingo core and Synthetica Mauve Metallic skin.
Key tips are shown in groups (internally called chains). A key tip group is associated with the specific ribbon entity. When the key tip mode is initiated, the key tip group for the entire ribbon is displayed. It contains key tips for the application menu button, taskbar components and task toggle buttons:
Pressing the letter for taksbar button activates that button. Key tips for disabled buttons are painted with partial translucency. Pressing the letter for task toggle button selects the matching ribbon task. Pressing the letter for the application menu button shows the application menu:
Once the next key tip group is shown, the previously shown key tip group is hidden (no key tips on the application menu button and taskbar buttons in this screenshot). Pressing Esc dismisses the currently shown key tip group and shows the previous key tip group. When the initial key tip group is dismissed, the key tip mode is exited.
This screenshot also shows that the menu buttons can have two key tips associated with them – one for the action, and one for the popup. Pressing ‘D‘ (associated with the popup “Send” button) shows the second level menu, switching off the key tips for the first level and showing them for the second level:
Pressing keys ‘E‘, ‘H‘ or ‘W‘ will activate the relevant second level menu buttons. Pressing key ‘X‘ activates the popup menu associated with the “Wireless” menu button:
Going back to the first screenshot (that shows the top level key tip group). Pressing key ‘P‘ shows the key tip group for the first (and currently selected) ribbon task:
The key tips are shown for ribbon buttons, task expand buttons (look for ‘FO‘ and ‘FN‘), ribbon gallery expand buttons (look for ‘L‘) and buttons in button strips (in the “Font” ribbon band). As you can see, some key tips have two letters. This can be useful not only when there are not enough letters for the contents of the current task. It can also help in grouping key tips of related functionality (such as alignment and indentation command buttons in the “Font” ribbon band that start with A). In the present situation, when letter ‘F‘ is pressed, only key tips that start with that letter are shown:
As before, pressing Esc will show the previous key tip group – in this case, it would be key tips for the entire “Page Layout” ribbon task.
Key tips are also shown in popup menus. Pressing ‘V‘ when the key tips for the entire first ribbon task are shown activates the popup menu of the “Paste” button:
Pressing one of the relevant keys will activate the matching menu button, dismissing the key tip mode as well. Key tips are also shown for the menu buttons in rich popup panels:
Here, in order to activate the “Save Selection”, you would have to press the following sequence of keys:
- Alt or F10 to activate the key tip mode
- P to select the first ribbon task
- F, P to show the popup of the “Format” button in the “Clipboard” ribbon task
- S, S to activate the “Save Selection” menu button
As you can see, the sequence to activate a specific command can be quite long. As such, commands that are used often need to be identified and associated with shorter (and perhaps more memorable) sequences.
The APIs to associate key tips with different ribbon components are:
- AbstractCommandButton.setActionKeyTip
- JCommandButton.setPopupKeyTip
- JRibbonBand.setExpandKeyTip
- JRibbonBand.setRibbonGalleryExpandKeyTip
- RibbonApplicationMenuEntry.setActionKeyTip
- RibbonApplicationMenuEntry.setPopupKeyTip
- JRibbon.setApplicationMenuKeyTip
- RibbonTask.setKeyTip
If you want to see the scrolling in action under the core look-and-feels, run the following WebStart demo:
If you want to see this functionality under Substance, 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.
