The Next Wave of GUIs: Project Matisse and NetBeans IDE 5.0

Print-friendly Version

Articles Index

Developing graphical user interfaces (GUIs) used to be a tricky part of Java technology programming. Although Java Foundation Classes/Swing (JFC/Swing) technology has been around for quite a while, designing professional-looking, cross-platform GUIs can be tedious and prone to error. All this has changed with NetBeans IDE 5.0 and Project Matisse.

Project Matisse solves the core problem of GUI creation by making the layout design of visual forms much easier. The project extends the NetBeans IDE 4.1 Form Editor to support a free design paradigm that exposes simple layout rules that are easy to understand and to use quickly.

NetBeans IDE software engineer Roman Strobl interviews Project Matisse creators Scott Violet and Tomas Pavek.

What are your roles in Project Matisse, and how long have you been involved?

Pavek: I'm the lead developer of the GUI builder in NetBeans and now primarily work on Project Matisse. The new layout design support project started about a year ago.

Violet: I'm the architect for Swing and have been working on portions of the project that will make their way back into the Java Development Kit (JDK). I've been involved with Matisse almost since the beginning.

How did Project Matisse start? What are its goals?

Violet: We've lamented the layout process at nearly all of Swing's planning sessions. In particular, the majority of existing builders force you to know about layout managers. This is painful, to say the least. Developers shouldn't be forced to learn about all the quirks of GridBagLayout or the underlying LayoutManager to create visually pleasing forms. This was the goal for Matisse.

Pavek: The NetBeans GUI builder contains a GridBag customizer -- a popular visual tool for configuring GridBagLayout. It is very helpful to know and understand GridBagLayout. We constantly received enhancement requests to improve this customizer. The requests asked for richer design-time support, more capable visual manipulation, better preset values of the layout constraints, and so on.

I realized developers were actually requesting to design the layout in general. They wanted the GUI builder to abstract from GridBagLayout and its intricacies. At this time, I started to think about natural layout support that would not expose any specific layout manager. I must say that I used to consider it an insane idea and too ambitious to ever happen.

At the same time, we demo'd the NetBeans GUI builder at an internal workshop on GUIs, and we heard similar opinions. The GUI builder is nice, but why do you have to deal with all those paddings, insets, fills, weights, and other parameters? Couldn't we have something higher-level, more visual, and, of course, easier to use? We took the opportunity to meet with the engineers from the Swing team. They were also disappointed with the state of tools support for visual layout design.

Simply put, we agreed that the problem was not in the layout managers but in overexposing them. Layout managers are good for constructing the user interface (UI) for the resulting implementation but not as the presentation principle to be used in an interactive visual tool.

This fit well into my old idea of a natural layout. The way to do this was not to find another layout manager and create a new tool for it, but instead to determine what developers needed from a GUI layout design tool. That is, how could the visual tool be used to manipulate components, set up component relationships, align them, set resizability, and so on? All this had to be visual, easy, and intuitive. It also needed to be comparable to existing Apple or Microsoft tools. There had to be no need for the developer to want to take a look under the hood and see how the layout was constructed. Of course, a layout manager is necessary for the layout to work properly, but it wasn't what we needed to start with. The most important thing was the user model.

After we had finished our first prototype, everyone we showed it to was amazed. We began to believe our approach was right.

As I understand it, a new layout manager was not originally a goal of the project. Why did you decide to create a new layout manager rather than reuse one of the many existing ones?

Violet: One of the beauties of abstracting the process of layout to a layout manager is that it allows for an infinite set of possibilities. Unfortunately, we were unable to find one that suited our needs, and so we created a new one. The layout manager is called GroupLayout and is an open-source project. While it's necessary for Matisse to use GroupLayout, our hope is that developers using Matisse will never have to directly interact with GroupLayout. At least that is our goal.

At some point, we'd also like to pull GroupLayout into the JDK.

Pavek: As Scott already mentioned, you won't notice the layout manager at all when working with Matisse. However, this layout manager is quite handy for manual coding as well and can be used separately from Matisse. From the GroupLayout web site Scott mentioned, you can download the whole library that supports textual baseline alignment and preferred spacing based on guidelines specific to the look and feel.

We originally did not aim for a new layout manager or other extensions. But we also did not want to limit the tool capabilities significantly just because of a lack of features in the current JDK. At the minimum, we needed the baseline support and the preferred spacing. We also needed a layout manager that could use these new features and also cope with the layout structure from Matisse. GridBagLayout was not capable enough, and using SpringLayout was too painful.

Some people consider the layout Matisse is using -- GroupLayout -- as proprietary. For example, one Eclipse developer said: "We can make Visual Editor work nearly exactly how Matisse works, but without having to resort to a proprietary layout manager." Is GroupLayout proprietary?

Violet: GroupLayout and the related functionality is no more proprietary than GTK is. GroupLayout is open sourced (LGPL).

An application created using Matisse seems harder to deploy if you need to bundle the new layout manager with it. When do you plan to add it to standard JDK distribution?

Violet: We had planned to add it to the JDK, but GroupLayout was too late in the cycle to make Java Platform, Standard Edition (Java SE, formerly known as J2SE) version 6. Additionally, we did not want developers to have to wait for version 6 before being able to use Matisse. Our goal is to support J2SE 1.4.2! Given this requirement, an external library is necessary. If all goes well, we will add GroupLayout to the JDK for version 7.

Pavek: We were not keen on having an additional library, but hopefully this is not such a big problem. Using external libraries is quite common today: You can hardly base any bigger project on standard JDK classes only. This library is quite small, open source, and you get it with NetBeans automatically. As Scott said, this is just a temporary solution until GroupLayout finds its way into the JDK.

I'd also like to stress that Matisse is not replacing the previous NetBeans GUI builder -- it extends it. And it is still possible to develop forms the same way as before, by using the standard layout managers.

Some say that Matisse is just a Java technology version of the Macintosh operating system's Interface Builder (IB). How much inspiration did you get from this tool?

Violet: It's no surprise that Matisse shares similarities with Interface Builder. IB is one of the best builders out there. It allows developers to drag and drop components as if it were a drawing program. But IB and the AppKit differ quite a bit from Swing. In particular, Swing runs on a multitude of operating systems and supports varying look and feels. As a result of this, the layout must adapt to changes in component sizes between look and feels, locales, and operating systems without requiring a form per look and feel, platform, and locale. Just imagine trying to write an application in which each locale, operating system, and look-and-feel combination required a new form. Ugh!

Matisse addresses all of these issues. Any form designed in Matisse will adapt to changes in differing component sizes that result from localization, different look and feels, or operating systems.

Pavek: The main difference is that with Matisse you get a fully cross-platform layout definition. This means that positions and sizes of components are not defined in absolute numbers at the moment you put them on the design canvas but computed dynamically when running in the target environment. Matisse creates a layout model to remember the relations between components, and GroupLayout maintains them dynamically. This means that when you follow the snap feature and place a component at a certain place, the component does not just receive a position coordinate but remembers why it snapped. For example, if it snaps to align with another component along the left edge, then the components keep left-aligned even if their absolute positions change.

Many developers would like to see two-way editing in NetBeans -- using both a visual designer and an editor. Some visual designers already allow this approach, but the NetBeans IDE uses guarded blocks that prevent users from editing code. Why did you choose this approach?

Pavek: NetBeans has a long history. This decision was made years ago and was probably resource-motivated. Creating a working two-way tool for a Java technology GUI is not trivial. Theoretically, it can never work perfectly, though in practice it is doable to have one that is good enough. Still, you can face problems with robustness in situations in which the tool can't understand part of the code and is unable to construct the whole UI for visual manipulation. The NetBeans GUI builder is 100 percent reliable in this aspect.

The guarded code actually does not prevent you from doing anything. NetBeans provides hooks so that you can alter the generated code and insert your own. Moreover, you can freely add additional modifications anywhere out of the guarded block -- that is, in the class constructor. You may initially feel less comfortable with this approach, but I think it eventually becomes a very natural habit.

Nevertheless, two-way editing is really popular and requested, so we can't just ignore it. I can't say now whether we'll do full two- way editing or not. But definitely we would like to address the primary use case we don't cover, which is importing the UI from existing code. This is one of the features we are receiving many requests for.

Violet: This is a hotly debated topic, but I think code generation is the wrong way to go. Having code generation encourages developers to tinker with it. Additionally, generating code encourages developers to end up with big gnarly classes that have layout, component creation, event wiring, and functionality. In the long term, I would like to see builders start using beans persistence or some other format for persistence. That way, developers won't feel the need to tinker with the code, and hopefully it will also result in more readable UI-related classes.

Pavek: I agree. This has just not happened yet because of the lack of a suitable and standard persistence format. I'm afraid the bean persistence seems not to be capable enough at this moment. Historically, the Swing UI is also best expressed through code: Everyone learns it this way and wants to see the code if anything goes wrong. That's also why two-way editing tools are so popular. If only Swing had included declarative persistence from the beginning! But this is really a topic for a separate debate.

What are Matisse's strengths? Where do you consider the project to be ahead of other visual editors?

Pavek: Matisse brings together the ease of design that Apple's or Microsoft's tools offer, while producing cross-platform UIs, such as when using layout managers. This is quite a unique combination, I think.

Violet: The strength of Matisse is that it allows developers who are new to Java technology to generate a form that will honor visual guidelines of the look and feel, align components along their baseline, and resize appropriately with any look and feel, locale, and operating-system combination. And they can do all of this without knowing the details of the LayoutManager. This is something not many of the other builders allow you to do.

What were some of the most challenging issues in your work on Matisse?

Pavek: In the beginning, we struggled with finding a layout concept usable for the user-friendly design interaction and also capable enough to create typical layouts. First, we tried a SpringLayout-like concept of arbitrarily related component edges, which was too open ended, and a table layout-like concept of component grid, which made it difficult to achieve proper cross-platform layout. Both were abandoned quickly. We then developed something in between: a layout system of nested groups that combines strengths from both approaches.

In the interaction part, we had to fight with the ambiguity of the user gestures. There is often more than one way to arrange the underlying model when the user drops a component. But we can't read the user's mind. The tool can do something differently than the user expected, but it should always be in a way that the user can understand, without the user feeling that something strange and complicated is happening behind the scenes -- which in fact it does.

Another challenging area was the layout structure visualization -- that is, showing components' relations, alignment, resizing, and so on. The tool needs to be easy to use, so we can't present the internal structure completely in all details. But some level of information is necessary in order to see what the layout will do and why. Cross-platform layout is not a trivial thing, after all.

Violet: Far and away the most challenging aspect has been how user gestures map to the resulting layout manager. By that, I mean what should happen to the LayoutManager when you drop a text field before a button, when you move a button, and so on. It sounds trivial, but when you think about the need to maintain relationships between components so that size changes can be accommodated, you'll realize this is no simple matter!

What are your future plans? Do you think that the most interesting features have come out with NetBeans IDE 5.0, or is there still a lot of space for innovation after 5.0 goes final?

Violet: We are by no means done. Matisse itself will continue to see improvements, both in terms of usability and stability in the near term. After the 5.0 release, you'll likely see several interesting things being added to Matisse. In the long term, we also have no shortage of ideas. Here are some things we've considered:

• Provide the ability to use a template as the starting point for a form. Many forms are very similar, with the exception of a couple of areas. It would be nice if there was a way to start from a similar form and customize from there. This could be similar to choosing different templates in StarOffice or PowerPoint.
• Make it easier for developers to write the tremendous amount of code needed to bind components to data. Work is actively being done on this in SwingLabs.
• Offer the ability to write to a standard persistence file rather than code generation.
• Make writing and maintaining medium to large applications easier. I'm not quite sure what form this will take, but undoubtedly this will involve changes in NetBeans and Swing.

Pavek: Just to supplement Scott's list:

• Tune and improve Matisse based on the feedback we receive. There are still lots of useful features in the layout-design area that we could add. We simply could not do everything we wanted to in one release. Also, some things needed time to settle down and find their optimal shape.
• Revamp the rest of the GUI builder, similarly to what we did with layout design -- that is, to make it much more focused on designing the UI without the need to know much about Swing details.
• Import UI from source code or limited two-way editing.
• Provide better support for using and developing custom components (with rich design support from JSR 273), reuse of forms (visual inheritance), and layout (templates and component snippets).

And there are tons of ideas for various usability and other improvements. These are basically the ideas we have. I don't know yet how they will fit into concrete plans and concrete releases.

Project Matisse
Matisse Demo
NetBeans IDE 5.0 Beta 2
NetBeans 5.0 Beta Tutorials, Guides, and Articles
JSR 273: Design-Time API for JavaBeans JBDT

Roman Strobl, a software engineer working on the NetBeans IDE, is based in Prague. His blog is regularly highlighted on blogs.sun.com and technorati.com.