Who’s On Phirst

Official blog of Phurnace Software.

Tag >> Java GUI

Posted by: Shawn Spiars on

It seems like there are more visual GUI builder products available on the market today than ever before. Visual GUI builders propose an easier way to design and create user interface components. They usually consist of a palette from which you select and drag controls or widgets onto a window, frame, or dialog. Then they provide a table or list where you can manipulate the properties of your controls (size, font, color, coordinates, etc) without requiring the user to know the subtleties’ of the syntax or layout managers. Here is a really good link if you are interested in Java GUI Builders.

Call me old fashion, but I always prefer a language editor (HTML, XML, Java, etc…) over a visual editor because I want to understand the commands I write, and I want to format and organize the code in a way that is meaningful to me so I can easily edit the code later. A good language editor will have syntax highlighting, syntax checking, command completion and various other features to assist you in developing the code, but it won’t generate the substance of the code for you.

Another type of code generation tool falls into the Model Driven Development (MDA) category. With MDD, logical models are used to capture design decisions and generate code, and sometimes the generated code is user interface code. The problem I have with user interfaces generated from models is that there is no consideration by the machine for who the user is, their technical aptitude, or the way they approach a task (workflow). The entire human experience is missing and the user interface has been reduced to a bunch of domain objects and business rules.

For example, the Eclipse Modeling Framework (EMF) can use a model to quickly generate a cool looking prototype consisting of a relational tree, object listeners, pop-up menus, and a properties view, but this in no way resembles a complex, well designed, user friendly application. And don’t be fooled into thinking you can easily tweak the generated code to get it to behave the way you want it to. I’ve spent hours and hours digging thru layers and layers of cryptic machine generated code trying to find the one line that needs to be changed to get the desired behavior.

There are plenty of MDD advocates out there who will disagree with me. Most of them are experts in modeling, but I’ve never met one who is an expert in user interface design. Since most project leads and architects today are very familiar with UML and modeling tools they often buy into the promise that MDD will save them time on their UI development. This has not been my experience.

If you do choose to use a modeling tool to generate UI code – I recommend you decouple the UI model from the back-end model. Just imagine a project where every time the back-end architect decides to change a relationship in the model the UI mysteriously breaks with no warnings.

“And that’s all I have to say about that.”

-Shawn

In Java GUIEclipse
Comment (0) Read More...


Posted by: Shawn Spiars on

There are quite a few toolkits available for Java developers. Let me help point you in some directions and maybe save you some research time.

Many of you will be familiar with the Abstract Windows Toolkit (AWT) that is available with every Java Runtime Environment (JRE). AWT is the original Java GUI toolkit developed by Sun Microsystems. AWT is a peer-based toolkit meaning that each AWT control is dependent upon a host operating system control. AWT usage is limited because it was designed to only support controls which are available in all Java host environments. For example, AWT does not support Trees and Tables.

Swing is another Java GUI toolkit developed by Sun Microsystems and was designed to work with AWT and is built on top of AWT components. Unlike AWT, most Swing controls are emulated. This emulation makes user interfaces written in Swing portable across all operating systems and supports Sun’s “write-once, run anywhere” motto. One disadvantage to Swing is that the emulated controls often don’t result in a native looking application. Swing’s answer to this problem is provided by look-and-feel emulators that attempt to change the appearance and behavior of their components to adapt to a particular operation system or theme. Another disadvantage to Swing is that the emulated controls tend to run slower than peer-based controls.

The Standard Widget Toolkit (SWT) is another peer-based GUI toolkit. IBM designed SWT to solve some of the problems that have limited the usage of AWT. SWT provides a different Java implementation for each operating system platform using Java Native Interface (JNI) calls. One disadvantage for SWT is that developers are required to dispose of OS-dependent objects within their application code.

JFace is a GUI library that was developed to compliment SWT and simplify common GUI programming tasks. SWT and JFace libraries are used extensively throughout the Eclipse IDE.

As a Java user interface developer I have used each of these GUI libraries and I find the combination of SWT/JFace my favorite choice because of the native look-and-feel of the components. I also find the SWT and JFace APIs cleaner and easier to develop with than AWT and Swing. My two cents, comments welcome.

In Java GUI ToolkitsJava GUIjavaAbstract Windows Toolkit
Comment (0) Read More...