GUI Builder and stuff 关注
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"
It would be great to have real MVc (do not care for C that much) framework
for Jetbrain. Couple of questions:
- Could you use JavaBean persistence framework rather than your own XML
- Have you seen Scope project http://scope.sf.net ? It's an MVC
implementation which have some nice ideas in model/view area. We used (and
extended) it succesfuly (be glad to discuss it if you find it interesting).
- Binding a form to an arbitrary bean (which is in many cases does not offer
property change or such notification). Are you planning to provide any
solution? One is to provide wrap-around-bean models to provide notification
(might be very tricky with complex graphs of objects and collections).
- One of very important areas is how collections are handled. Are you
planning to provide bindings between collections and controls like JTable?
"Eugene Belyaev" <firstname.lastname@example.org> wrote in message
i have a very simple question(s):
What are you thinking about webapps development?
More and better support of this is maybe more important!?
(GUI for Webapps - exemplary keyword "JavaServer Faces").
Or is that all for you uninteresting?
Eugene Belyaev schrieb:
Inno Consult GmbH
Telefon: +49 351 25796-13
Fax: +49 351 25796-24
This tends to remind me of the way interfaces are developed with cocoa
(os x), using interface builder. This also provides a clear seperation
between the gui setup code and the controller of the gui which imho is a
great way of working. Is this the direction you are going in?
Pepijn Van Eeckhoudt
"Eugene Belyaev" <email@example.com> wrote in message
I really like the idea of having such support for composition in the GUI
builder. As far as I'm aware, there is no other GUI builder currently
available which does this (please someone point one out to me if I'm wrong).
I also like this idea of having styles specified on prototype forms:
anything that makes it easier to centralise control of the visual style of
an application is a good thing IMHO.
Will the forms be treated like classes by the IDE? Will it be possible, for
example, to write code which uses a form and still have the benefit of IDEAs
refactoring support? Will it be possible to write a class which extends a
Vilya Harvey, Consultant
firstname.lastname@example.org / digital steps /
(W) +44 (0)1483 469 480
(M) +44 (0)7816 678 457 http://www.digitalsteps.com/
This e-mail and any attachments may be confidential and/or legally
privileged. If you have received this email and you are not a named
addressee, please inform the sender at Digital Steps Ltd by phone on
+44 (0)1483 469 480 or by reply email and then delete the email from
your system. If you are not a named addressee you must not use,
disclose, distribute, copy, print or rely on this email. Although
Digital Steps Ltd routinely screens for viruses, addressees should
check this email and any attachments for viruses. Digital Steps Ltd
makes no representation or warranty as to the absence of viruses in this
email or any attachments.
Eugene Belyaev wrote:
Well, I am happy of investing my time in writing java code that depends
on widely knwon an open source library to compile (eg code that depends
on say log4j, struts ...) and build files that depend on ant, test code
that depend on junit.
And so far IDEA has helped me a lot.
The decision to depend on a proprietary/not-mainstream product is
instead much more complex.
So I'd not be very happy to create files that require a proprietary,
even if free at the moment (free today is not enough, open source is
better), tool or component to be built.
So I'd like IDEA not to produce any files that require IDEA (or one of
its components), to be built.
Well, it may produce proprietary deliverables - as this can be much much
more efficient - but one should also have the alternative of keeping
'standard', derived ones (eg lain java source files), even if these, as
derived products are of much less value. They still give me an escape
route from the product that generated the proprietary files.
For instance, if I throw away netbeans, the source code for its form is
still usable and modifiable in IDEA - I lost the visual editing, but
that's part op the trade-off I accept.
As I said, I strongly prefer the option of keeping that code.
I'm confident you'll get where no-one else has been before !!
I believe that sometimes it is useful to be able to view and look at the code that gets generated for the form (primarily for the debugging purpose). So, it would be nice if the GUI builder provided a way of generating the code up front, so that the debugger can step thru it.
Also, if the code is going to get generated on the fly, is it going to hurt the run time performance? I also agree with the comment about being able to use the code without having to have the "code generator" (I like the NetBeans concept of being able to use the code even if I do not have the NetBeans).
I do not care for the code which draws the form if it works as designed and
documented. But it would be nice to have all kinds of hooks to all possible
actions. Like in Delphi one can drop a button on a form and use predefined
actions as hooks for callbacks. If the button does not have some specific
action, one can always derive own button from standard one, get a window
handle and go nuts. This is very understated beauty of Delphi: one can work
on very high level -- with classes and actions, or on very low level -- with
Windows handles and Windows API.
So, to be "cool" IDEA GUI designer must support inheritance of visual
elements and all possible levels of controlling the behaviour of the
controls with reasonable defaults, so the need for proprietary hooks would
I am sure that you guys used Delphi before, so you know what I am looking
As for proprietary "form files" or "resource files" -- I am OK with that. I
hate when some static visual stuff is defined with zillion of code lines.
But, if one build a semi-dynamic form and store its definition in
resource -- that would be nice. For example, I define for a control it
possible views, and I define these views in the same form or in common
repository. So, I want to be able to change the view programmaticaly, or to
link the view with another control or state (like radio button). If I would
be able to feed proper data to my control for all possible views, then I
would not have even to change the code, MVC rules.
I do not agree. I believe there could be no GUI without framework. If you
make tool to generated 100% of code for you it will be a maintenance
nightmare and huge and ineficient and not expandable... I would be glad to
PURCHASE framework from IntelliJ as a comertial product if it is good. One
of the reasons client side java is not widely accepted is lack of good high
level MVC frameworks (like Delphi)
"Edoardo Comar" <email@example.com> wrote in message
What kind of support can we expect on the framework aspects? This is no logger just a developer tool and need in some cases fast turn-around of bug fixes.
This is why I agree with others on the fact that the framework should be open-source or at least have the sources available and the generator/compiler should allow source code generation.
On Fri, 21 Mar 2003 08:54:32 -0800, Michael Jouravlev wrote:
Whilst I don't care for the code which draws the form, for day-to-day
coding, it would still be nice to be able to see it, and see how its being
used. For when we want/need to generate dynamic forms - it'd be nice to
keep them the same as how all the other forms as built.
On Fri, 21 Mar 2003 08:54:32 -0800, Michael Jouravlev wrote:
I think the problem JBuilder had was that it -wasn't- like Delphi. They
kinda made it rather yecky to work with :p
Sounds very exciting ... :)
But I wonder if I may raise a few points:
The proprietary XML. I don't have a problem with this. Keeping the layout description separate from the code is a good idea.
Packaging. I would like to see it as a separate add-on module for IDEA, rather than being included in the core.
Generating class files directly. That's a tricky one. I'm thinking about version control here. Which files would we save under CVS for example? Would there be a way to regenerate the required files outside of IDEA (as a separate ANT task for example)?
On Sat, 22 Mar 2003 08:01:55 +0000, Rayz wrote:
Store the XML file in CVS of course. And an Ant task has been mentioned...
"Eugene Belyaev" <firstname.lastname@example.org> wrote in
Having recently completed a moderately complicated GUI this is a subject
that's of great interest to me.
I don't see not working with all the layouts as a real issue. A lot of
them are not worth the trouble anyway.
+1 on no wizards. I like that idea only has a single wizard.
It's extremely important that other people not using Idea be able to use
this stuff (minus the GUI tool) so thats good.
I would go further than making it free. I'd make it open source. That
would give me a level of comfort that the solution will always be available
and will survive any problems that IntelliJ may suffer in the future (not
that I'm expecting any:).
If it's open source at least I have control over fixing any problems that I
may run into down the track - although IntelliJ should still be the ones
looking after the official blessed version of course.
I strongly believe that XML is the right way to store this data. One of
the major problems with tools that generate Java source code is that it
becomes pretty much unreadable afterwards. This is because GUI's are very
hierarchical in nature and Java code isn't. XML is.
It would be nice to simplify the binding. It's not too hard to do them
manually with Idea but newbies love this because the learning curve is
It's not clear what you mean here.
It would be nice to have something that lets you:
Easily bind to a db field.
Undo changes (to the row not just one field).
Restrict import based on field type and size.
Commit or rollback changes.
Okay... this ones extremely important. It should be possible to set a
style against a particular control and then change the style and have all
controls updated. For example I might have a heading style that applies to
JLabels. The heading style would define a large font with bold and
underline. Later I might change the colour and it would change all
controls with that style across the application. It should still be
possible for individual controls to override the styles properties however.
The "style" should go as far as automatically attaching certain event
handlers and defaulting the models.
Adding new controls should be really easy too.
Currently there are NO good GUI builders for Java. Some of this is to do
with how poorly swing was designed to work with GUI's. A lot of it also
comes down to poor implementations. Hopefully you guys can fix this
>> Other ideas we have had
>> is to not only be able to have fields for controls themselves but also
>> for some of their properties.
>It's not clear what you mean here.
I hope Eugene means that you will be able to traverse the bean graph. I would be really interested to be able to define a bean at the panel level that might contains other subpanels that are bound to properties of the bean.
I will illustrate with an example:
Let's say that we have an StreetAddress like that (getters/setters omitted):
I could have 2 objects ResidentialAddress and CommercialAddress that contains a StreetAddress.
I could have defined a panel StreetAddressPanel that binds to a StreetAddress bean.
In building the ResidentialAddressPanel I can use a StreetAddressPanel that will bind automatically to the property address. Same thing for CommercialAddressPanel.
We have an environment where we want to enforce a common L&F. Having a set of default UI for standard business object/types would be great. I would also speed up the development of panels since we would build hierarchical panels from the get go. Maybe the refactoring function that some other posters mentioned would be also great at extracting beans and panels at the same time.
Okay, thanks. I managed to miss the part about command line tools.
So the entire GUI description will be contained in the XML file, from which the GUI classes can be regenerated from scratch during an Ant build? Sounds good.
Still not convinced about generating .class files directly though. If source files are generated, then wouldn't this give folk more options? Native Java compilers for example. And it would also make the process immune to changes in the class file structure (unlikely, but possible).
On Sun, 23 Mar 2003 06:21:22 +0000, Rayz wrote:
I was thinking on this, and was wondering if there was a way that AspectJ
could be used in relation to making GUI development in Java new and
Possibly something along the lines of making use of pointcuts
One thing I really hate with the way alot of existing GUI design tools do
things is there insistence of using ActionListeners, and putting
'modifyable' code inside. With the complete XML abstraction, I could see
all that code sitting in another class, either a subclass of the generated
code, or a child class, along with the "model/data" class.
Yes I agree. Also I believe Bean per Panel should not be the only way (not
flexible enough having to make your visual object containment to mimick your
bean containment) Nested bean properties should be supported too
"Jacques Morel" <email@example.com> wrote in message
would be really interested to be able to define a bean at the panel level
that might contains other subpanels that are bound to properties of the
contains a StreetAddress.
that will bind automatically to the property address. Same thing for
of default UI for standard business object/types would be great. I would
also speed up the development of panels since we would build hierarchical
panels from the get go. Maybe the refactoring function that some other
posters mentioned would be also great at extracting beans and panels at the
Hi Eugene,File F Datei D Press me! output will be shown on the console. P Dr?ck mich! Ausgabe erfolgt auf der Konsole. k ]]>
Eugene Belyaev wrote:
> 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.
I nearly misted the post, but i'm really hungry for a good
visual UI Editor ;)
> First, let me say about the purpose of the project itself.
> not to help reverse-engineer
> nor follow the current dubious (feel free to convince
> me it's not) approach to working with UI aspects of
I don't get that point: which approach are you referring to?
> e.g. it will not work with all the layouts out there.
I think the reason that no visual UI editor for Swing exists is
directly related to the varios LayoutManagers, but writing I18N
applications without LayoutManagers is very tough.
> We want a solution that will dramatically improve the way we
> program UIs, so this discussion is about that.
I have problems with revolutions aka silver bullets aka
"dramatically improve" ;)
I would love to see a more evolutionary approach, that supports
different styles of development (see below).
> 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.
+1: I would prefer support for the following development styles:
- On the lowest support level, i get a sweet UI Editor that generates
a XML file that can be easily converted to another XML file that
my current frameworks operates on.
Support for this level includes I18N issues, and is mainly focues
on the (static) "look" of the application, it doesn't require
changes to any of my code outside the initial UI setup phase.
- On the next support level, i get the UI Editor, the XML file and
a Framework that provides higher-level features.
Support on this level will change my code, because it will provide
processes, places and structure beyond the Swing Framework.
- On the next support level, i get data binding.
It might perhaps support data binding via Smalltalk like
ValueModel's or a two tier data binding the VB/Delphi way.
> The form designed in the GUI builder is described in an XML file.
> It has a clean but proprietary syntax.
The most importent point for me is that this XML file is already I18N
enabled, and easy to parse/process e.g. via XSLT or a small Perl
> 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.
Why do you generate special code? You could provide a Builder that
generates the panels etc. from the XML input as a generic class,
InputStream input = ...
SwingXMLBuilder builder= SwingXMLBuilder.create(input);
> - 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.
Again, i don't understand why this should be special code.
Of course, i see the need for data binding to generate special code,
but on the lowest level, it would be perfectly o.k. to have an
access via the builder, like
JTextField textField= (JTextField)
> 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.
I like the NeXTSTEP/Qt style:
connect(widget, callbackobject, methodname)
or in XML
> Also, we are working on data binding. +1, data binding is very importent, but again, this should be an (purely optional) add on. > 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. I currently prefer a ValueModel like approach (for more details see http://c2.com/ppr/vmodels.html). All VB/Delphi developers should get of course their two tier direct data binding stuff, but this is not very useful in a three tier environment. I also made a lot of progress lately by spliting my data binding framework in two halfs: o binding the data of a use case to display/edit widgets via a ValueModel's (see below for an example) o binding the state of a use case to command widgets (buttons, menus, ..) via a State/StateAdapter approach (see below for an example) I prefer the State/StateAdapter style to a more formal finite state machine approach (e.g. like Struts does it), because it fits IMO better to the dynamic nature of a Swing GUI. In any case, the data binding should reduce the "callback handling" code written by a developer as much as possible. > 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.
I'm not so sure if this approach is generic enough. I like the "non
visual builder approach" from Karsten Lentzsch (jgoodies.org), but i
currently can't imagine how this can be integrated with a visual
> And again, our goal here is to help easily create outstanding
> forms, instead of tediously programs ugly ones.
To summarize, my major points regarding the IDEA UI Editor are:
o The UI Editor provides an I18N XML file, suitable for processing
outside of Intellij
o The UI Editor provides integration with a general UI Framework
classes (simular to the Skeleton stuff from Karsten Lentzsch)
o The UI Editor provides data binding, both for a ValueModel like
style as well as for a Delphi like style.
Example for ValueModel like data binding
/* ValueModel setup and data binding */
ListHolder tableData = new ListHolder();
// tableData holds a java.util.List of UserData objects
IndexedAdapter currentRow= new IndexedAdapter(tableData);
ValueModel trigger = new ValueHolder();
new BufferedValueHolder(currentRow, trigger, true);
AspectAdapter firstNameAspect =
/* ValueModel UI binding */
// ValueModel binding
Example for State/StateAdapter like data binding
// bind the enabling/disabling of the file name textfield and
// the search button to the file radiobutton via a State/StateAdapter
JRadioButton fileButton =
State fileState = new SwingSelectedState(fileButton.getModel());
StateAdapter fileAdapter= new SwingEnabledAdapter(fileState);
Example for a XML file
This is an XML file i use as input for my SwingXMLBuilder class.
The XML file of the UI builder should at least contain the
non-visual and visual part, of course in a different format.
Quit Close application. Q Beenden Anwendung verlassen. B Q
Thomas-Dehler-Str. 27, D-81737 M?nchen
Tel: +49 89 63812 709 Fax: +49 89 63812 490
Certainly, an adequate support for I18N in GUI applications is extremely important, but I'd really like it to be done with the help of old good property files, not by encoding localised strings into the XML file.
On Mon, 31 Mar 2003 09:12:59 +0000, Sergei S. Ivanov wrote:
When looking into I18N stuff for work I came accross the ICU4J stuff from
IBM, and RB Manager:
Havn't really used it yet, but a plugin wrapper could be kinda neat.
nteresting stuff about the GUI builder.
I'd like to point your attention to a layout manager called DialogLayout that we developed for form-based GUIs. It creates layouts that are precisely correct to platform standards (our Java layouts under Windows look exactly like Windows applications) and it is very predictable and easy to use. Perhaps you would like to take a look at the layout manager and see if any of the ideas we used would be of use. It's open-sourced under a permissive license.
The code and documentation is available at http://www.sourceforge.net/projects/dialoglayout.