I'll start the GUI builder discussion from a scratch by explaining some of
the issues we have behind it and with the hope to answer most of the
questions arisen here.
First, let me say about the purpose of the project itself. We are doing it
not to help reverse-engineer bunches of hand-written Swing code nor follow
the current dubious (feel free to convince me it's not) approach to working
with UI aspects of applications. The goal here is to dramatically simplify
the UI construction as a task. So this will not be just "one more" Swing
wizard. It will not even be a Swing or AWT builder in that usual
understanding, e.g. it will not work with all the layouts out there.
If you still want to hand-write the code yourself, we have one of the best
code editors out there. If you want a prototype wizard that generates a lot
of code that you need to refactor afterwards, we won't do it.
We want a solution that will dramatically improve the way we program UIs, so
this discussion is about that.
Of course, you should realize that to build a great visual tool, you need to
operate on frameworks. And what's very important, frameworks designed "for
tools", not vice-versa. There is a set of rules we will follow to keep it
an acceptable solution for usage by other people on the team not using IDEA,
by providing a documentation, freely available command-line tools, etc. It
should be possible to use it outside the IDE for no charge and licensing
restrictions, however missing the visual tool.
Of course the GUI builder is based on consuming JavaBean-based controls as
in its first generation. However, we have far-going ideas on the subject
that are not going to be covered right away.
Most of them are hard to explain without showing samples, so we'll leave it
for the future times.
One important notion here, the GUI builder we are talking about is well
suited for statically created layouts, which make the majority of cases. We
may advance the framework and tools to the dynamic case, but not right away.
The form designed in the GUI builder is described in an XML file. It has a
clean but proprietary syntax.
For each form, two pieces are generated:
- code that handles actual assembly of the form at runtime. So mainly it
contains code creating helper panels, adding controls to them, etc. This
code never has to be seen, so we'll skip the source code generation phase
here and will provide resulting class files. The instantiation logic for
JavaBean-based controls is obvios, but in case of factory made controls we
might add support as well but later.
- code that opens access to the controls on the form that you need to
program against. Simply a class with fields for every component you specify
or plan on using.
There are different thoughts here on how to bind events to handlers. One of
them fully relies upon the developer, so you add listeners to components
yourself. Another one is to implement a binding like in Delphi or VB. We
are not really fixed on whether we provide the latter, but the former will
be there anyway. Other ideas we have had is to not only be able to have
fields for controls themselves but also for some of their properties.
Also, we are working on data binding. Something like to have a JavaBean to
get and set properties to various components to/from. This is also not yet
quite decided how to deal with, so we'll need your input and our own
experience when the time comes.
One more idea about working with forms: you should be able to specify
containers on the form that you will want to insert other components later.
At runtime you will be able to add any components you want to a ready to use
layout. This is very important when you want let's say have a fixed layout
for a lot of dialogs where only a certain part varies. Also, when you have
a statically created form that still needs to derive other parts from a
prototype, the GUI builder will be able to handle that. Also, these
"prototype" forms might enforce styles on child components. Let's say I
want to assure that every label that is added to this type of a dialog
becomes bold and of certain color. But this is in a very early stage of
discussion right now.
And again, our goal here is to help easily create outstanding forms, instead
of tediously programs ugly ones.
Eugene Belyaev, CTO
"Develop with pleasure"