Hi,
i would like to add my view to the recent discussions regarding more
features for Ariadna that make Swing/AWT development easier.
Most people that voted against such support wrote that that would add
"bload" to the IDE and would generate bad code, anyway.
Knowing all major IDE's (VAge, JBuilder, Netbeans) and their GUI
editors, i would definitively vote agains any simular approach to GUI
editors ... but their are also success stories, sadly not in the Java
world.
Before describing my "ideal" GUI editor, i would like to clearly
define from my point of view the major four aspects of GUI editing
and GUI coding:
o creating a visual look for a window/dialog by aggregating
atomar UI elements like buttons, labels, etc
o connecting the "callbacks" of the atomar UI elements to
code written by the user
o provide a method to access the UI tree to change attributes (e.g.
whether a button is enabled, I18N, ...), or to get attributes (what
text was entered in a text field)
o change the UI tree (a "advanced options" button will add a panel to
a dialog)
Most (Java) IDE's didn't make UI development as easy as VB/Visual C++
development, because there is (for the better or worse) no "simple"
way to get the basic work done without being a genius. (I definetly
hate Microsoft as anybody else, but the get a lot of things right
when it comes to support for "joe developer".)
I started working with UI's about 10 years ago, and nothing ever
since was more pleasant then the NeXTSTEP (aka Mac OS X)
InterfaceBuilder.app, and i wish that there would be GUI Editor like
that for Swing/AWT.
InterfaceBuilder.app addressed most of the above aspects of GUI editing
right by
o a full visual drag'n'drop of atomar UI components, with a powerful
struts/springs layoutmanagement (that now re-appears in .NET)
o _not_ generating code, but a (binary) representation of the UI,
that was loaded at run time
o a powerful, visual callback editor that let you connect the events
of any UI element to a method of an object of any class during
design time
=> a Java/Swing GUI "accelerator" should provide
o a visual editor supporting all JDK 1.4 layout managers (mostly
the SpringLayout & GridBagLayout) and all UI elements (standard
ones + JavaBean's) that generates an XML descripton.
o a generator to generate customizable code from that description
and/or some API to load such an description at runtime
o some small helper classes that provide NeXTSTEP/.NET like
callback handling without inner classes or simular bloat
o some small helper classes that provide access to a UI tree by
name (think XPATH), without getter/setter method bloat
Somebody noted that all "senior" developers have some classes that
make Swing live easier, and i fully agree with that view. In the same
post, however, he said that therefore no GUI editors are needed, and
i strongly disagree with that.
My typical UI work goes like this:
1) paint the UI with a pencil on squared paper
2) go to the client, discuss the look and to some degree the feel;
if further work is needed, goto 1)
3) find the right layout manager (mostly GridBagLayout), and try
with the paper to figure out if it will work
4) write a class for each major panel, a small decorator helper class
helps to keep some stuff like I18N, tooltips, ... in a property
file
5) compile, run, and resize the panel(s)
6) find out whether the resizing works, if not, goto 4)
7) write the controller classes (MVC on a dialog level, not a Swing one)
and connect the callbacks with a small helper class to the various
methods of that classes
8) start real work
9) discover that the client had not really the same ideas about the
feel, and has now new ideas about the look, therefore got 1)
Both for my clients (that have to pay for that) and for myself
(getting bored during the 2->1 and 6->4 loops) the above approach is
not optimal, and any help from IDEA 2.x, x>5 would be really cool!
Bye,
J�rgen
_______________________________________________
Eap-features mailing list
[EMAIL PROTECTED]
http://www.intellij.com/mailman/listinfo/eap-features
