Summary
The RADICAL systems presents an interesting possibility for designing a graphic user interface (GUI).

---

Advertisement

In my previous post ( One Cool IDE), I described the power and ease of use of the CodeGuide IDE (http://www.omnicore.com). Perhaps the single most important thing for me is their ability to stay abreast of changes in the Java platform, and to work with any version I need to use.)

Quite a few folks wrote in to share their high regard for IDEA -- another great IDE that stays up to date with platform changes.

But the one thing that neither of these IDE's have is the ability to design graphic interfaces. In this post, I'm going to talk about a potential solution for that problem -- RADICAL.

Note:
I hasten to add that I have not yet had occasion to actually use RADICAL. So this post is theoretical -- I'll be interested in hearing from others about their experiences with this or other equivalent technologies.

RADICAL, at http://radical.sourceforge.net/ provides a new layout manager that works like a grid with adjustable heights and widths. I suspect that's a good thing, because as clever as nested layout managers seemed in theory, they turn out to be a bear to work with in practice -- the complexity basically overwhelms your ability to predict what's going to happen to the layout when you resize the window, and you wind up having to do a lot of coding to handle that seemingly simple task.

In addition to the layout manager, RADICAL adds a graphic development environment that lets you insert components and arrange them. (The ability to do so is no doubt assisted by the simplicity of having a single layout manager, as opposed to trying to manage dozens of nested layouts.)

But it's the way in which these technologies are used that seems to me the most useful thing about RADICAL. The idea is that you use to the graphic tool to create the GUI class(es), and then subclass the GUI class to build your application. That way, you can change the layout to your heart's content without making any changes to the program logic.

Once the interface has been constructed, there are three interesting approaches to take in building the program logic:

• GUI classes poke the model, but never query it
• GUI interactions are managed in a separate layer
• GUI builders are passed to application objects

These concepts hold great promise for the design of GUI programs. I'll discuss them in my next post.

Talk Back!

Have an opinion? Readers have already posted 4 comments about this weblog entry. Why not add yours?

RSS Feed

If you'd like to be notified whenever Eric Armstrong adds a new entry to his weblog, subscribe to his RSS feed.

Digg | del.icio.us | Reddit

About the Blogger

Eric Armstrong has been programming and writing professionally since before there were personal computers. His production experience includes artificial intelligence (AI) programs, system libraries, real-time programs, and business applications in a variety of languages. He works as a writer and software consultant in the San Francisco Bay Area. He wrote The JBuilder2 Bible and authored the Java/XML programming tutorial available at http://java.sun.com. Eric is also involved in efforts to design knowledge-based collaboration systems.