Popular @
Forum Controls
Spotlight Features
The Rich Engineering Heritage Behind Dependency Injection
Andrew McVeigh takes us on a tour of the rich heritage behind dependency injection, what it represents, and tells us why its here to stay.
NetBeans 6: Matisse Updates
NetBeans 6 delivers great updates to the Matisse GUI builder. Spend a few minutes with Roman Strobl and get an expert briefing on what's new and what has changed. (sponsored)
Introduction to Groovy Part 3
In this, the third and final installation of Andres' Introduction to Groovy series, you learn about how Groovy handles variable numbers of arguments, named parameters, currying, and more about Groovy operators. Including, some new operators.
Easier Custom Components with Swing Fuse
Swing Fuse (actually just Fuse), is a framework designed to make it easier to create your own custom desktop components. In this article, Daniel Spiewak shows you how to get started and provides sample source code you can download.
Benchmark Analysis: Guice vs Spring
Willam Louth shows how he uses JXInsight Probes to investigate probable performance issues with code bases that he is not familiar with. He also highlights possible pitfalls in creating a benchmark, as well as in the analysis of results.
GUI builders - Bad form?
At 2:41 PM on Mar 23, 2005, Joe Attardi wrote:
Fresh Jobs for Developers Post a job opportunity
56 replies so far (
Post your own)
Re: GUI builders - Bad form?
Form editors do have their place. Often it's useful to generate lots of layout/component initialisation code quickly using the form editor, but then move it into a "normal" class to tidy it up. Ideally leave it in the GUI editor though, unless you really can't stand the code it generates.It's generally quicker to prototype a new form using a GUI editor, than it would be to do it in code; e.g. quickly create the layout then move buttons & editor components around visually. If you're working with something like GridBagLayout, using a decent GUI editor is just plain faster than editing the code directly.
One of the things I dislike about GUI editors is that they tend to make it difficult to work with custom components, and impossible to work with custom layout managers.
Agile Development with the ICONIX Process: A core subset of agile UML techniques.
Extreme Programming Refactored: The other side.
Re: GUI builders - Bad form?
OK. So it is not considered a bad practice to use them? I'm just thinking of using it for some open-source stuff anyway.Re: GUI builders - Bad form?
It's not that it's "bad form"; rather that it tends to create bad forms... (yep, I DID intend that pun...) I have to agree with the previous poster: no custom layouts, and a hard time to work with custom components. To that, I'd have to add the tendency to create "super-forms" instead of factoring out common functions into components. It can quickly lead to a VB-like UI (yeeeeeech!).Re: GUI builders - Bad form?
I don't use GUI builders for four reasons:1. I have more control over my code without them.
2. Often I don't like the code that they generate, but I can't change it without breaking things.
3. I know exactly what my code is doing without them.
3. This ties into point number two. I have had too many experiences with "DO NOT TOUCH THIS CODE", because the GUI builder made it and if you change it by hand, things break the next time you use the GUI builder.
Re: GUI builders - Bad form?
Actually I just started using the Abeille Forms Designer from https://abeille.dev.java.net/ which creates layouts based on the jgoodies forms package and I honestly think its extraordinarily good. It can both generate code, and make panels based on the saved .form files. I made a fairly complex gui consisting of some 12 windows in just a couple of hours.I would seriously suggest you check it out.
Re: GUI builders - Bad form?
Joe,I have been in this position before and would offer this bit of insight:
If your app is NOT UI-centric, in that the UI portion of it is a secondary function, then definately use the GUI builder. Creating and maintaining UIs with the NetBeans GUI builder is infinitly easier than maintaining hand-written-code.
If your app IS UI-centric (Email client, Browser, Groupware, etc.) then I would say stick to hand-written code from start to finish. Maybe use the GUI builder to draft up some stuff, but if your UI is complex and heavy, you will benefit from doing some smart hand coding.
If you aren't sure, you CAN of course use both, although I have never used both and been happy with the readability and comprehensible nature of the code... not that the GUI builder is bad, it does it's job and it does it damn well, but if you want to do a lot of custom stuff you just need to play hand-in-hand with the UI builder a lot either using the post-initialization code block features or adding secondary initialization methods ontop of what NetBeans adds or other type of collaboration between you and the UI builder.
Another huge factor to consider is if you are GOOD with UIs, if you are not good at making UIs then definately use the builder, it will let you visually tweak your UIs on the fly in a really nice way (NOTE: Becomes best friends with Right Click > Customize Layout, when designing containers that use GridBagLayout). If you are awesome at layouts and are comforatable with JGoodies FormLayout and might event want to try the Abeille FormLayout designer (https://abeille.dev.java.net/) that might be another way to go... FormLayout is a pretty sexy layout and because it seems to be extremely flexible and well defined, the GUI builders for it seem to be pretty flexible and provide layouts for almost any situation (any normal-app situation I would say).
If you want to stay "pure JDK" then go with NB's GUI Builder, I've always liked it. I coworker of mine that leads a team of devs uses it for every project from start to finish and loves it, so it is definately possible.
The only complaint I would make is that you need to make sure your other developers leave alone the protected code blocks, especially if they are using a different IDE like Eclipse or IntelliJ... that will cause the designer to get kind of pissy if it's form file (xml representation of form data) is totally out of sync with the actual code. Although I've never tested the limits of it
Re: GUI builders - Bad form?
In the past I have always designed my Java GUI's by hand. I can write some very nifty and efficient GUI's by hand, and using a non-visual builder like the JGoodies FormBuilder makes for some very clean code.Note, however, that the reasons people give for coding by hand are similar to the reasons we used to give for writing inline assembly in our C code:
1) Control of what is being written (aka "I can do a better job than the tool")
2) I know what is going on (aka "who knows what this compiler is creating?")
3) Cleaner code (aka "My assembly is better than the compiler's assembly")
4) Better performance/smaller file size (related to #1-3)
Note also that the reason we no longer recommend inline assembly is the same reason why we should be using GUI builders: efficiency, efficiency, efficiency. Sure, the code might be a little more bloated and run a little slower, but the DEVELOPER will be running much better. Or, better yet, lower grade developers can slap together the GUI allowing the hard-core hackers among us to worry about the hard problems instead of the mundane (like writing the next fancy widget).
As time goes on, the GUI builders get better. I remember early versions of NetBeans (known as Forte for Java back then) which produced some...hairy...code. The latest stuff I've seen produced by netbeans was good stuff.
Richard
Re: GUI builders - Bad form?
Excellent post Richard, good points all around.Re: GUI builders - Bad form?
1) Control of what is being written (aka "I can do a better job than the tool")2) I know what is going on (aka "who knows what this compiler is creating?")
3) Cleaner code (aka "My assembly is better than the compiler's assembly")
4) Better performance/smaller file size (related to #1-3)
Point 1 & 3 lead to better code and maintainability. This is very different reason than choosing assembly vs C which will give you the opposite effect.
Re: GUI builders - Bad form?
That, IMO, is a completely subjective assessment... #1 and #3 depend completely on the developer doing the work... I bet you anything I could write you some assembly code that would make you want to vomit as opposed to a toolRe: GUI builders - Bad form?
> I don't use GUI builders for four reasons:>
> 1. I have more control over my code without them.
See response to #2.
> 2. Often I don't like the code that they generate,
> but I can't change it without breaking things.
In my early experience with JBuilder (version 3.5!), its GUI builder understood your code even after you modified it! Yes, it coul dgenerate code for you, and yes, it sucked. But I often went back and cleaned up thegenerated code, and was still able to manipulate it in the GUI editor.
> 3. I know exactly what my code is doing without
> them.
I do too, but its nice to be able to have something to help you -- not take control from you.
> 3. This ties into point number two. I have had too
> many experiences with "DO NOT TOUCH THIS CODE",
> because the GUI builder made it and if you change it
> by hand, things break the next time you use the GUI
> builder.
See #2 again. I don't know how they did it, but they did it.
Re: GUI builders - Bad form?
> If your app IS UI-centric (Email client, Browser,> Groupware, etc.) then I would say stick to
> hand-written code from start to finish.
I don't argree. The more forms/dialogs a app has, the more time (and money) you can save by using a good GUI designer. And you have more time to concentrate on other details of the app or do some polishing
> Maybe use the
> GUI builder to draft up some stuff, but if your UI is
> complex and heavy, you will benefit from doing some
> smart hand coding.
If "complex and heavy" means that there are a lot of controls on a form, then I would use a GUI designer.
If "complex and heavy" means that the UI is dynamic, I agree with you. With "dynamic" I mean e.g. that the UI should change its appearance (show/hide/move controls) depending on some conditions at runtime.
Karl
JFormDesigner - Java/Swing GUI designer
Re: GUI builders - Bad form?
+1> Note also that the reason we no longer recommend
> inline assembly is the same reason why we should be
> using GUI builders: efficiency, efficiency,
> efficiency.
I fully agree with you.
Some other examples:
Why are we using IDEs for Java programing? It's much more efficient than a text editor and javac.
Why are we using a word processor instead of TeX. It's much easier to use and therefore more erricient. TeX is great and gives you full control over everything, but it takes much more time to learn and use it.
Why are we writing emails on the computer and not writing letters on a typewriter. Efficiency
Karl
JFormDesigner - Java/Swing GUI designer
Re: GUI builders - Bad form?
Karl,You need to fix the URL in your sig, I think you need to prepend http:// to it so it doesn't think it's a subpage of JavaLobby, also your prices for JFormDesigner are extremely reasonable, bravo for you not going crazy and charging rediculous prices.