March 17, 2006
IntelliJ IDEA 6.0 "Demetra", Designing the UI Designer, part 2
Yesterday I described the main goals with which we approached the UI Designer in IntelliJ IDEA 6.0. Now I’ll describe some of the key decisions we’ve made – part of them are new for version 6.0, and others haven’t changed since the previous versions of UI Designer available in IntelliJ IDEA 4.x and 5.x. As usual, any feedback on the decisions is very much welcome.
Runtime Requirement. In previous versions of IntelliJ IDEA, the code generated by the UI Designer always required the use of a runtime library (forms_rt.jar), which contains a custom layout manager and a number of additional utility functions. This became a major obstacle for many users who didn’t want to introduce extra dependencies in their applications – some of them rejected the UI Designer completely when they learned of the runtime requirement. The problem was made worse by the fact that, until version 5.0, the license for the source code of forms_rt.jar was not clearly defined, which made it hard to use in open-source projects. Now it’s clearly licensed under the Apache license, but other problems with the runtime remained.
In the new version, we’ve made it possible to generate code which uses only the standard Swing layout managers and does not require any additional runtime. We’ve kept the runtime for those who need full compatibility with forms created in earlier versions of IntelliJ IDEA, and we even added a few new features to our layout manager, but you can easily opt out of its use if you don’t need that.
Bytecode Instrumentation. A related issue is the way code is generated by the UI Designer. We decided to keep both of the options available in version 5.0: source code generation and bytecode instrumentation. We consider bytecode instrumentation the best option for projects which are developed using only IntelliJ IDEA, as it’s cleaner (the generated code is never visible to users) and provides better build performance. For other projects, where multiple IDEs are used or when the entire source code of the application needs to be provided to the customer, source code generation can be used.
In version 6.0, we’ve rewritten the bytecode generator to use ASM instead of BCEL, as it provides better performance and better support for new versions of the .class file format. Also, we plan to improve the source code generator so that it produces cleaner and more readable code.
Form Migration. Using forms created in IDEA with other IDEs is one side of the problem – another is importing into IDEA forms created in other IDEs. Before version 6.0, we didn’t provide any solution to this problem – you always had to draw forms from scratch.
There are a number of possibilities to solving this. It’s possible to import the XML form definition files created by specific designers (for example, JFormDesigner .jfd or NetBeans .form). Another option is to reverse-engineer the Java source code used to create the form (either generated or hand-written) and to extract the information about the component layout and properties (this is the approach used by Eclipse Visual Editor).
However, we decided that importing only specific XML form file formats would be too restricted, and creating a general reverse engineering engine that works in a sufficiently broad number of cases (including hand-written code) is too risky and resource-consuming. Instead, we have implemented the possibility to import form files from the most simple and universal structure of the form data: the run-time tree of Swing components. We inject our component, called Swing Inspector, in the Java virtual machine where the user application runs. When the user presses a button or a keyboard shortcut, a window showing the entire hierarchy of Swing components is displayed. The user can choose any part of that tree (the contents of an entire frame or dialog, a panel containing some of the components, and so on), and that part is saved as a .form file. The entire component layout structure and most of the component properties are saved. Later, the user can open the .form file in UI Designer and modify it as required.
The initial version of the Swing Inspector will be included in the next EAP build of IntelliJ IDEA. Here’s a screenshot showing how it works:
Well, that’s enough for today – stay tuned for more design decisions next week. And don’t forget to send feedback! :-)
Posted by Dmitry Jemerov at March 17, 2006 01:59 PMRuntime Requirement:
- good that it's not a "must". Runtimes are never a problem as long as they're not "obligatory".
- should support other layout managers (mentioned yesterday - e.g. Forms is the best so far)
- 1. could add support for the Netbeans layout manager (afaik it will be part of the next JDK), but till than is free for use
Bytecode Instrumentation:
- IMHO: no, no, no period. Explained this yesterday.
Form Migration:
- The Swing Inspector looks like a nice thing, however for most of the users, IMHO would be important to:
2. simply be able to reverse enginner JBuilder forms (so the jbInit() method)
3. simply reverse engineer the Eclipse VE generated code - this should not be so complicated since VE it's doing itself this job.
Maybe this part(for 2 and 3) could be done with external tools like JFormDesginer does:
see: http://jformdesigner.com/download/ - section "Tools".
IMHO it would not be a problem that the tool would be external since one would not do this job all the time.
Regarding the Eclipse VE code source code conversion, IMHO you should "reuse" it's own code :), and maybe distribute it as an OS tool so that there are no license problems.
The idea is to cover as much as possible from the generated code, and let the "Swing Inspector" for manual generated code - but I suppose, most users will be happy with #2 and #3.
Ahmed.
Posted by: Ahmed Mohombe at March 17, 2006 02:45 PMSomething that would be a Very Good Thing(tm) to have in UIDesigner, would be a good integration with the Swing Actions framework (http://java.sun.com/docs/books/tutorial/uiswing/misc/action.html), rather than being exclusively event-listener oriented. For example having a pallete of actions can be easily associated with components.
Posted by: Yannick Menager at March 17, 2006 04:00 PMHow about grouplayout support?
Taking in accout that finally it's in the Mustang...
Ar maybe there will be a mattise plugin for IDEA, who knows...
Posted by: Dim at March 17, 2006 04:30 PMForms inspector looks really cool!
Posted by: Wow! at March 17, 2006 04:57 PMPlease add support for JGoodies Forms:
http://www.jgoodies.com/freeware/forms/index.html
The license is BSD so hopefully you can include it with IntelliJ IDEA 6.0.
We use it on our GUI here and it would be nice to have some nice IDE support for the FormLayout. I see it as IDE-assisted use of FormLayout. Just a little hand-holding, not necessarily pure WYSIWYG.
Posted by: Dan Lewis at March 20, 2006 06:49 PMLack of support for round trip code generation/parsing is very significant drawback. If you work on code with people that use different IDEs, only reliable way to work on GUI is to either write them by hand or use tools can parse source code and accept modifications made by hand. I agree that parsing arbitrarily structured code can be difficult. A compromise is to support code structured within certain limits. A starting point could be to support parsing of code structured similar to auto-generated code. Even that limited support could be something to encourage ones who like to tweak their code to give a chance to new UI Designer.
I use IDEA as my primary environment. I tried IU Designer when it was introduced, but lack of support for round trip editing was a no-go. Borland used to have nice GUI bilder, but now it is a history. Currently I use Instantiation’s Swing Builder plugin for Eclipse, only because is has a very good support round trip code generation/parsing, I wish they would provide one for IDEA:)
Did you see that you can get NetBeans' Matisse on the Eclipse platform now? It's the first Swing UI to integrate NetBeans for Eclipse! Full support included with MyEclipse's free trial!
www.myeclipseide.com for details.
Posted by: Jens E. - genuitec.com at May 3, 2006 10:18 PMHi,
We have several drawbacks from the way IDEA's designer is currently implemented:
1. The worse limitation (still present in demetra) is IDEA's inability to use custom *containers* - e.g. if I created my own class, "MyPanel extends JPanel" - I can't use it as a panel in the designer (can't place other components on it). This poses a very big limitation on large organizations (such as the one I'm at) which have existing components and frameworks which simply can't be used. Yes, I know all about the "you should *use* components, NOT extend them" argument - but it does not always hold water. There are cases when you simply have to do it - both tech-wise and organizational-wise.
2. We are used to working with standard Swing layouts (GridBagLayout mostly). But using IDEA's designer, all our developers suddenly need to learn new concepts such as "want grow", "can grow", etc - and their inter-relationships with the layout manager. If I'm designing using a GridBagLayout (instead of IDEA's GridLayout) - why not allow to use the "standard" constraints as we all know and used to?? (insets, padding, etc). I've read the forms_rt's GridBagConverter and the "margins" is not exactly the "insets" constraint, and could not find a way to set a specific component's insets. Same for padding and there are a few other differences as well (not to mention that the form preview's result of GridBagLayout looks different than how it looks in design time (different spacing, etc).
3. Not all Swing properties are shown in the property inspector for all components.
4. IDEA doesn't recognize/use custom components' BeanInfo (not even the icon!)
I've listed the points sorted by importance - 1 is the most important and 4 is the least important. If the first two are solved in Demetra - IDEA's designer would be top-notch and ready for wide-spread adoption IMHO.
Cheers!
Arik Kfir, arikkfir at gmail.com
There needs to be a web page specifically for downloads such as forms_rt.jar where it is explicitly stated that forms_rt.jar is covered by the Apache License and where recent versions of this jar (and other such downloads) can be downloaded.
I can't find such a page.
I am aware that forms_rt.jar can be extracted from an IDEA download, but that isn't clean and simple for my configuration management people to work with.
Thanks
Posted by: Dave Yost at November 26, 2006 10:37 AMI do not understand, how the XML code generated by IDEA in the process of creating an UI form is then translated in Java Code, when we need to run the application. Is this possible to run that code without IDEA ?! is there any article where I can read about this ?! Thank you !!!
Posted by: vanea at January 29, 2007 10:58 PM