Dmitry Jemerov's Weblog

So what is "Support for JGoodies Forms"?

One more very common request for the UI Designer is the request to support JGoodies Forms. This request shares a common trait with many other requests to support something that we receive for other areas of IntelliJ IDEA: it lacks any details. For example, what does “Spring support” mean? Is the Spring-specific resolve and completion available since version 5.0.2 sufficient, or does the requester need something more, and if so, what exactly?

As for JGoodies Forms, there is one kind of support that we can provide with very little effort. We can make it possible to generate source code and bytecode which uses the JGoodies Forms layout manager without making any additions to the design-time experience. (We already support GridBagLayout in a similar way – if you’re curious, look at GridBagLayoutCodeGenerator and GridBagConverter classes in redist\src\src_javac2.zip.) The only issue is that I don’t quite understand what problem it would solve.

Now, of course, JGoodies Forms has a number of features which are not supported by our designer (for example, row/column groups). And if what you really need are these additional features, it will probably make the most sense to support them in our own layout manager, in addition to providing JGoodies Forms support.

So, my request is: if you’re interested in JGoodies Forms support, could you please leave a comment here and describe what exactly you need from such a support?

And in the meantime, here’s a small preview of a different new feature that I’ve been working on today:

IntelliJ IDEA 6.0 "Demetra" UI Designer: Custom component creation

One of the problems which made it impossible for people to use previous versions of the IntelliJ IDEA UI Designer in their projects was the lack of support for custom component creation code. The designer could only work with components which had no-argument public constructors, and could not handle components created by constructors with arguments, component factories and so on.

We continued to receive feedback on this issue during our work on the version 6.0, and finally we’ve come to a solution for this issue that doesn’t break any of our design principles. The solution works equally well for source code generation and bytecode instrumentation, and does not involve storing source code in the form files.

The solution is in fact very simple. Every component now has a property called “Custom Create”:

If the property is set for a component, the UI Designer does not generate the constructor call for this component. Instead, if at least one component has the “Custom Create” flag set, IntelliJ IDEA creates a special method called createUIComponents(), and inserts a call to this method in the beginning of the generated UI initialization method. The code of createUIComponents() is written by the user, and the user needs to assign values to fields bound to all custom-created components. (A component with the “Custom Create” flag must be bound to a field.)

In design time, components which do not have a public default constructor are represented by instances of superclasses which do have such a constructor, or by JPanel instances if there is no such superclass. The property list shown in the inspector is still taken from the exact class of the component, so you’ll be able to set the values for all properties (although the values of properties that don’t exist in the superclass will not affect the design-time appearance of the component).

A related change that also makes the UI Designer more flexible is a small modification to the source code generation algorithm. Now, if any of the user-written constructors of a class bound to a form calls the UI initialization method explicitly, IntelliJ IDEA no longer generate a class initializer block with a call to the UI initialization method. This allows to initialize the UI at a somewhat later time (for example, after values of the parameters passed to the bound class constructor have been processed).

This solution will become available in the next EAP build of Demetra. In the meantime, feel free to leave feedback here, particularly if the solution does not cover some of the scenarios found in your projects.