The Artima Developer Community
Sponsored Link

Weblogs Forum
Designing Graphic Interfaces

4 replies on 1 page. Most recent reply: Apr 5, 2004 9:17 PM by Eric Armstrong

Welcome Guest
  Sign In

Go back to the topic listing  Back to Topic List Click to reply to this topic  Reply to this Topic Click to search messages in this forum  Search Forum Click for a threaded view of the topic  Threaded View   
Previous Topic   Next Topic
Flat View: This topic has 4 replies on 1 page
Eric Armstrong

Posts: 207
Nickname: cooltools
Registered: Apr, 2003

Designing Graphic Interfaces (View in Weblogs)
Posted: Dec 18, 2003 7:50 PM
Reply to this message Reply
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.


Gregg Wonderly

Posts: 317
Nickname: greggwon
Registered: Apr, 2003

Re: Designing Graphic Interfaces Posted: Dec 25, 2003 8:42 PM
Reply to this message Reply
> RADICAL, at <a href="http://radical.sourceforge.net/">
> http://radical.sourceforge.net/</a>
> 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.

The first complicated GUI development that I did was building user interfaces for TCL/TK applications. The TK packer is a simple command that has powerful capabilities for rectangular/grid type layouts.

The Java GridBagLayout has the same capabilities, but it has an absolutely horrible programming API. The gridbag contraints data object makes the whole API feel like a windows programming exercise.

I created a new wrapper class, called Packer, that provides a TCL/TK like interface. In TCL/TK, one would encode a layout using

pack .top.frame.label1 -gridx 0 -gridy 0 -west
pack .top.frame.field1 -gridx 1 -gridy 0 -fillx

that would create a labeled text field that expanded horizontally when the outer frame size changed.

Using my Packer class, you would do something like

JPanel p = new JPanel();
Packer pk = new Packer(p);

to associate the container with the Packer instance. Then, you'd use that Packer instance as

pk.pack( new JLabel("Field") ).gridx(0).gridy(0).west();
pk.pack( new JTextField() ).gridx(1).gridy(0).fillx();

This is the only layout that I have used since 1996 when I put it together. When you have multiple horizontal components stacked, or multiple vertical components displayed horizontally, you should always put an empty JPanel() at the end of the list and use filly() or fillx(), respectively, if you want the objects to be pressed against the opposite "wall".

Packer is out on java.net for those that might be interested in it. All the GUI layout and building tools that I've used have been worthless because of their code generation model. I've seen a wide range of code models from inline coding with tags delimiting user added code, to stub methods for event processing, to subclassing as well as listeners everywhere.

I've always resorted back to hand coded GUI layout because it really does allow me to do exactly what I need, with certain optimizations in code to handle things like building tables of controls or otherwise generating many instances of a similar control with minor differences. With most GUI tools, I'd have to edit 10s of property sets to change something simple like borders, whether there is a ':' at the end of all labels etc.

I'll have to look at Radical to see what's up...

Matt Gerrans

Posts: 1153
Nickname: matt
Registered: Feb, 2002

Desigin Graphic Interfaces Posted: Dec 26, 2003 1:56 PM
Reply to this message Reply
I've always thought that the auto-generated or manually generated GUI code was the one thing in Java that was a major step backward in programming. Seems to me that the GUI layout should be specified in another, separate specicialized layout language (like resources, but with a better language than the old Windows RC file format, of course).

I'm surprised that Microsoft decided to copy that aspect of Java when designing C# -- that's a shame. I've already encountered some strange and scary bugs that result from the IDE mucking with source code and if it wasn't for source control (and some Python scripts I had to cook up to repair and prevent damage), it would have been really disastrous.

The layout tools available in Delphi and C++ Builder have yet to be improved upon in anything I've seen since. Things like anchors and docking are so much simpler to use and understand than nested layouts and they work great for dealing with things like localization and adapting to different system metrics (font sizes, etc.). Although VS.Net/C# makes the auto-edited code mistake, at least it supports these simple methods.

Are layouts the invention of a rectangular wheel when plenty of round ones existed?

Eric Armstrong

Posts: 207
Nickname: cooltools
Registered: Apr, 2003

Re: Desigin Graphic Interfaces Posted: Apr 5, 2004 9:13 PM
Reply to this message Reply
> I've always thought that the auto-generated or manually
> generated GUI code was the one thing in Java that was a
> major step backward in programming.
>
I sympathize. It's an area in which I'm still looking for good solutions myself. That Packer hack looks like it's worth exploring, though.

Eric Armstrong

Posts: 207
Nickname: cooltools
Registered: Apr, 2003

Re: Designing Graphic Interfaces Posted: Apr 5, 2004 9:17 PM
Reply to this message Reply
> I created a new wrapper class, called Packer, that
> provides a TCL/TK like interface.
> ....
> Using my Packer class, you would do something like
>
> JPanel p = new JPanel();
> Packer pk = new Packer(p);
>
> to associate the container with the Packer instance.
> Then, you'd use that Packer instance as
>
> pk.pack( new JLabel("Field") ).gridx(0).gridy(0).west();
> pk.pack( new JTextField() ).gridx(1).gridy(0).fillx();
>
> ...
>
> Packer is out on java.net for those that might be
> interested ....
>
> I'll have to look at Radical to see what's up...
>
And I, in turn, want to have a look at Packer.
By all means, let me know what you think of Radical. I'll be interested in your opinion. Contact me at eric [dot] armstrong [at] sun [dot] com.

Flat View: This topic has 4 replies on 1 page
Topic: Push-me-pull-you, Or challenges Facing Corporate Research Previous Topic   Next Topic Topic: A Week at PyCon DC 2004


Sponsored Links



Google
  Web Artima.com   

Copyright © 1996-2014 Artima, Inc. All Rights Reserved. - Privacy Policy - Terms of Use - Advertise with Us