+1 

It would be a nice plugin :)


> -----Original Message-----
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]]On Behalf Of J�rgen Zeller
> Sent: Tuesday, January 15, 2002 8:49 PM
> To: [EMAIL PROTECTED]
> Subject: [Eap-features] GUI editor: what's really needed?
> 
> 
> 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
> 

_______________________________________________
Eap-features mailing list
[EMAIL PROTECTED]
http://www.intellij.com/mailman/listinfo/eap-features

Reply via email to