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.
A prolific blogger, a frequent presenter at conferences and a champion of automated Swing UI testing. Meet Alex Ruiz as the interview series on Swing, JavaFX and related topics that started with Amy Fowler, Mikael Grev, David Qiao, Chet Haase, Andres Almiray and Richard Bair continues.
Tell us a little bit about yourself
My name is Alex Ruiz. I’m a programmer. I love programming and I love Java. In a previous job, as a consultant for ThoughtWorks, I developed a healthy enthusiasm for automated testing.
I work on open source projects on my spare time. My first “serious” open source project was a library, part of Spring Modules, that performed transparent caching using Aspect-Oriented Programming techniques. I “retired” from the project a couple of years ago and as far as I know, the project is still active and under development! I’m also the creator of an open source project for functional testing of Swing UIs called FEST (Fixtures for Easy Software Testing.)
I also enjoy writing technical articles and presenting at various conferences.
I currently work at Oracle as a Software Engineer for the tools organization. I’m part of the team that develops the framework used as the foundation for JDeveloper, SQLDeveloper and many other middleware tools and products.
The readers of this blog have seen your name in connection with FEST Swing project. What is your “elevator pitch” for this project?
This is the shortest overview I could come up with :)
Testing user interfaces has been traditionally a challenging activity. In my opinion, writing tests is just the beginning. Maintaining them and troubleshooting test failures is difficult as well, if not more. FEST-Swing aims at changing that by providing the following features:
- A compact, fluent and easy-to-use API that makes creation of tests enjoyable
- Such API is also quite readable, making maintenance of tests pretty easy too
- Many features (like desktop screenshots) that can help us troubleshoot any unexpected test failure in a quick manner
- Support for verification that our user interfaces are not violating any EDT access rule
Why did you decide to focus on testing Swing-powered UIs?
I always thought that Swing was (and still is) the best UI toolkit in the market. It is cross-platform, powerful and flexible. I liked the ability to change the look and feel of applications to make them look the same regardless of the underlying platform. And on top of that, I could code UIs using my favorite language, Java.
I started by creating some very small Swing apps just for fun. Following my curiosity for testing, I found that testing UIs was a very fascinating challenge for many reasons. I realized that, to test UIs, unit testing was not as helpful as I wanted. Sure, I could test that my ActionListener performs some logic correctly, but I thought that it was not good enough. Unit testing of UI classes was as fragile as using mock objects: developers need too much knowledge of the internals of the UI. And, if the internals change without changing the actual UI behavior, tests can fail miserably. I also understood that testing UI-related classes in isolation could not give us confidence that the UI, as a whole, behaved as expected in front of the user. In order to be effective, tests needed to verify the behavior of a UI as if a user was actually using it.
I started looking into open source tools for functional tests of Swing UIs. Although all of them could simulate user input successfully by using the AWT Robot, they were not as usable as I desired. My first impression was that their APIs were too verbose, making creation and maintenance of UI tests quite tedious.
Then my wife, Yvonne, and I started doing some experiments with fluent interfaces, which ended up as FEST. From that point on, the project has grown thanks to the feedback and contribution of its users.
Should UI testing layer be part of core distribution of UI toolkits, or should this be left to interested third parties?
That’s a tough question. I have mixed feelings about this…and a long answer!
It would be ideal to have both the UI toolkit and the testing layer distributed together, to expose more developers to the benefits of UI testing. We might assume that if the UI testing layer was built in within the toolkit, more people would embrace automated testing. Unfortunately, that is unrealistic and impractical.
I think that having both the toolkit and testing layer as a single distribution actually complicates the distribution process enormously. The first reason is how these two depend on each other. The testing layer obviously depends on the UI toolkit. New features or bugs in the toolkit are very likely to affect the features to add to the testing layer. The opposite is not true though. By having the toolkit and testing layer together, it would be hard to decide when to release a new version of the product. For example, would it be fair to delay the release of the toolkit because of some unfinished features or bug fixes in the testing layer? Probably not.
It is also essential to know the needs of the toolkit consumers. I bet many of them don’t care about automated UI testing, can live without feature A or B in the testing layer, or need a critical bug fix in the UI toolkit to release their own products. Although UI testing is necessary, it is still not a popular practice. Automated testing in general is not as popular as it should be. I think the best way to serve users is by satisfying their most important needs. In this case, that would be the UI toolkit.
The opposite is true too. There are (a smaller number of) users that care about the testing layer as much (or almost as much) as the toolkit itself. They would also be negatively affected if a feature or bug fix they need in the testing layer is delayed due to the development of the toolkit. A good example is Swing. It is distributed with a bigger product, the JDK. We would have to wait for a new release of the JDK to get updates, new features and bug fixes to the UI testing layer.
I think what Sun has done with Swing is pretty good job already. The inclusion of the AWT Robot facilitates the creation of true cross-platform UI testing tools and Swing itself can be testable, with a few OS-dependent hacks.
In short, I think UI toolkits should not be distributed with a UI testing layer. These are two complex products that solve two difficult problems. It is better to focus on them separately but always having testability in mind.
Sure, third parties interested in UI testing can create the UI testing layer. Competition is a good thing. But this shouldn’t exclude the creator of the UI toolkit, as long as the creator has enough interest, knowledge and manpower to work on the testing layer.
What, in your opinion, are Swing’s pain points and what can be done to address them?
As I mentioned before, I think Swing is very powerful and flexible. That is a problem too. It is too easy to mess things up, and get away with it. The lack of documentation is, in my opinion, the major pain point. Sure, we have documentation on how to use Swing components and threading. But, in my opinion, we are lacking a guide or blueprints for different types of applications. From simple details as how to organize UI code in packages to how to divide responsibilities among all the UI-related classes. It would nice if somebody wrote a book about this topic!
Additionally, Gregg Bolinger had a fantastic idea: create a project to show developers how to use Swing correctly and effectively. I can’t wait to see the outcome!
Given full control, would you change anything in Swing core layer going forward?
- Add support for checking violation of Swing threading rules
- Retrofit generics to Swing. I cannot believe we still have to code like this: MyWindow w = (MyWindow) SwingUtilities.getAncestorOfClass(MyWindow.class, textField)
- Replace Vector with concurrent collections
- Add MigLayout and DesignGridLayout to the JDK
- Remove the Metal L&F once and for all
- Better DnD support: minimize the code that users have to write
- More UI components! Include Flamingo and JIDE in the JDK
Do you agree with Richard Bair’s assessment that JavaFX is “Swing 2.0”?
That is difficult to answer since Richard’s statement is too general. My interpretation is JavaFX can be considered Swing2 in the sense that Sun doesn’t have to worry about backwards compatibility. Other than that, I don’t think that JavaFX is really Swing2. My understanding is that JavaFX’s scope is to create and deploy “rich applications” in different platforms (desktop, web and mobile.) That’s way beyond Swing’s scope.
Given the small amount of information given by Sun, it is difficult to predict the direction of JavaFX and Swing.
Are you interested in extending the concepts of FEST Swing to other Java-based UI toolkits, such as SWT and JavaFX?
I’ve been thinking a lot about this lately. I thought about porting the ideas of FEST-Swing to SWT a few months ago, but I’m not sure if there is a need for it. There is already a project using fluent interfaces for SWT, SWTBot, which is in incubation as an Eclipse project. If this project satisfies the needs of SWT users, I think there is no reason for us to support SWT.
We are seriously considering supporting JavaFX. I tried to use FEST-Swing to test a JavaFX, without success. I think the problem is that the component hierarchy is different in JavaFX and new testing layer (or at least a new component hierarchy strategy) needs to be created. Michael Hüttermann (good friend and FEST teammate) and I will be doing research about testing JavaFX UIs starting in January 09.
Would you like to share the future plans for FEST Swing beyond the impending 1.0 release?
There is really not too much too say, since we have been focused on releasing 1.0 first :)
After FEST-Swing 1.0 (due in mid-January 09,) we will be implementing many enhancement requests from our users. We will be adding support for 3rd party UI components (Flamingo and JIDE.) Finally, we will provide a simpler API built with Groovy.
We need to sit down to prioritize all the pending tasks we currently have.
Anything else that you would like to add?
Swing is, in my opinion, the most powerful and flexible cross-platform toolkit out there. I don’t think it is going away anytime soon. There is too much investment, both from Sun and Swing users, to let it die. I agree, Sun needs to take care of Swing: fix bugs, and add new features and UI components. The APIs need to be “modernized” too. We need to get involved and help out too. We can create missing UI components, new look and feels, and write tutorials describing how to do things right with Swing! Just like you, Alex Potochkin and David Qiao, to name a few.
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.
