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.
A03 is a third-party Swing look-and-feel developed by Davide Raccagni and available under BSD license. Today Davide has announced release 4.0 of A03, with the main emphasis on performance. One of the tools he used during the development cycle is the LightBeam testbed that aims to assist in performance analysis of look-and-feels, as well as rendering pipelines.
Here are the results for the different core and third-party look-and-feels, as measured on my machine (without hardware acceleration that makes some of the scenarios run by up to 40% faster) – lower numbers mean faster performance:
- 3039 Metal
- 3721 Windows
- 4004 Looks PlasticXP
- 4332 Nimbus
- 4665 Substance 5.1
- 4902 A03
- 4908 Synthetica Base
In addition to performance improvements, Davide has also worked with me over the last few weeks to provide support for Flamingo components. Not only does the A03 Flamingo plugin provide fine-tuned visuals to some of Flamingo’s components, it also allows A03-powered JRibbonFrames to host the application menu button, taskbar panel and contextual task groups on the title pane under decorated mode. In doing so, A03 has joined Substance in providing streamlined visuals for the interested applications.
Below you can find a few screenshots of JRibbon and JRibbonFrame under A03 – click to see the full-sized versions.
The first screenshot shows the default content of the test ribbon shipped with Flamingo:
The next screenshot shows the activated application menu button:
The next screenshot shows the rich popup panel associated with a command button:
The next screenshot shows the extended tooltip associated with a command button in the taskbar panel:
The last screenshot shows the contextual task group headers:
Davide – congratulations on the release, and thanks for providing feedback on the extensibility points of the core Flamingo UI delegates.
