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.
