Creating a simple visual user interface

[Danger_Duck]

Right now, I have a program that you run off command prompt by typing:
java progName arg0, arg1, .....

like many homemade programs out there. Fine and terrific for me, but
not for the average joe who doesn't know how to access a file
directory....

So, are there any recommendations of how to make a more user-friendly
graphical interface that can consist of a form and input entries? Like
java.util.form or something?

I also use eclipse, but creating an entire view/plugin takes up a lot
more space/time than I want for simple programs.

So, I'd just like to hear suggestions on your favorite ways to make
simple programs accessible to non-technical users. Til then, I will
continue to use command prompt as I always have...

Thanks

 

[Mark Space]

So, I'd just like to hear suggestions on your favorite ways to make
simple programs accessible to non-technical users. Til then, I will
continue to use command prompt as I always have...

<http://java.sun.com/docs/books/tutorial/uiswing/>

You do need to learn how to code, regardless what you use.

However, that tutorial does say to get NetBeans and use the GUI builder,
and you should. That can eliminate 90% of the hassle in creating a user
interface. The NetBeans GUI builder is quite good, here's an intro:

<http://www.netbeans.org/kb/60/java/gui-functionality.html>

 

[Mark Space]

http://java.sun.com/docs/books/tutorial/uiswing/

Jinx!!

You owe me a Coke....

 

[Knute Johnson]

Right now, I have a program that you run off command prompt by typing:
java progName arg0, arg1, .....

like many homemade programs out there. Fine and terrific for me, but
not for the average joe who doesn't know how to access a file
directory....

So, are there any recommendations of how to make a more user-friendly
graphical interface that can consist of a form and input entries? Like
java.util.form or something?

I also use eclipse, but creating an entire view/plugin takes up a lot
more space/time than I want for simple programs.

So, I'd just like to hear suggestions on your favorite ways to make
simple programs accessible to non-technical users. Til then, I will
continue to use command prompt as I always have...

Thanks

Simple GUIs are very easy to do. Just create a frame, add your
components and the code to populate and depopulate the fields. Learn
how to use GridBagLayout. You can make very simple GUI programs that
way. I don't use an IDE, I just use vim for an editor. I'll even write
you a simple sample.

import java.awt.*;
import java.awt.event.*;
import javax.swing.*;

public class SimpleGUI extends JFrame implements ActionListener {
JTextField tf;

public SimpleGUI() {
setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE);

setLayout(new GridBagLayout());
GridBagConstraints c = new GridBagConstraints();

c.gridy = 0; c.gridwidth = 2;
tf = new JTextField(20);
add(tf,c);

++c.gridy; c.gridwidth = 1; c.weightx = 1.0;
c.anchor = GridBagConstraints.EAST;
JButton getButton = new JButton("Get Data");
getButton.addActionListener(this);
add(getButton,c);

c.anchor = GridBagConstraints.WEST;
JButton processButton = new JButton("Process Data");
processButton.addActionListener(this);
add(processButton,c);

// make the buttons the same size
Dimension d = processButton.getPreferredSize();
getButton.setPreferredSize(d);

pack();
setVisible(true);
}

public void actionPerformed(ActionEvent ae) {
String ac = ae.getActionCommand();

if (ac.equals("Get Data")) {
// get the data from somewhere
// put it in the JTextField
tf.setText("New Data");
} else if (ac.equals("Process Data")) {
// process data
String str = tf.getText().toUpperCase();
// put result in JTextField
tf.setText(str);
}
}

public static void main(String[] args) {
// Swing components must be created and accessed on the EDT
EventQueue.invokeLater(new Runnable() {
public void run() {
new SimpleGUI();
}
});
}
}

 

[Danger_Duck]

Thanks guys! This helps a lot!

 

[JK]

<http://java.sun.com/docs/books/tutorial/uiswing/>

You do need to learn how to code, regardless what you use.

However, that tutorial does say to get NetBeans and use the GUI builder,
and you should. That can eliminate 90% of the hassle in creating a user
interface.

Depending on the nature of the UI. Yeah, for simple throwaway things a
GUI builder can be OK, but I've never met a GUI builder that can build
code that's simpler and clearer than code I could write by hand;
much less immune to the eventual near-certain market death of the
UI-builder tool in question. IOW it's likely that a day will come when
the generated code will *have* to be maintained by hand.

IMO UI builders are at best a crutch, and it's really better to
learn how to build a UI by hand. Of course it's been a while since
I bothered to even try any such tools, so perhaps the state-of-the-art
has improved dramatically in recent years?

-- JK

 

[Mark Space]

I bothered to even try any such tools, so perhaps the state-of-the-art
has improved dramatically in recent years?

I would have to assume that the state of the art has advanced. I never
used GUI builders in the bad old days, so I can't say how much they have
improved.

GUIs should require no maintenance, imo. They should be thin enough
that they can be tossed out and another quickly built in it's place.
All the real application logic should happen elsewhere, and be "plugged
in" to the GUI (probably via various ActionListeners). Good use of
interfaces here is crucial.

How achievable that would be on a real, large project I can't say.

NetBeans builds "Plain Old Java Objects". They don't require a GUI
builder to maintain. Aside from some tricky use of the LayoutManager,
they're a breeze to maintain by hand. The only disadvantage of the GUI
builder in NetBeans is it won't read arbitrary classes and allow you to
edit them. If you loose the special layout fie it uses ("form", I
think) you can't edit the class source files with the builder any more.
(Hint: make certain the form file is under source code control.)

 

[Daniele Futtorovic]

Depending on the nature of the UI. Yeah, for simple throwaway things a
GUI builder can be OK, but I've never met a GUI builder that can build
code that's simpler and clearer than code I could write by hand;
much less immune to the eventual near-certain market death of the
UI-builder tool in question. IOW it's likely that a day will come when
the generated code will *have* to be maintained by hand.

IMO UI builders are at best a crutch, and it's really better to
learn how to build a UI by hand. Of course it's been a while since
I bothered to even try any such tools, so perhaps the state-of-the-art
has improved dramatically in recent years?

Amen. I also get the feeling that GUI builders, or development
environments altogether becoming ever greater and greater a deal
introduces the tendency to dumb down the API to make it more
"GUI-builder-friendly". That's the impression I got from .NET anyway.

Of course, there's a bit of my own personal judgement implied in that
sentence above by the verb "dumb down". We could probably argue whether
it's good or bad for quite a while. I'm presently more concerned with
the question of whether there is a back-effect at all. Presuming there
is -- while I wouldn't deny this can sometimes be a Good Thing, it's
most definitely a double-edged one, I'd say.

 

[JK]

I would have to assume that the state of the art has advanced. I never
used GUI builders in the bad old days, so I can't say how much they have
improved.

GUIs should require no maintenance, imo. They should be thin enough
that they can be tossed out and another quickly built in it's place. All
the real application logic should happen elsewhere, and be "plugged in"
to the GUI (probably via various ActionListeners). Good use of
interfaces here is crucial.

Yes, I agree completely.

How achievable that would be on a real, large project I can't say.

NetBeans builds "Plain Old Java Objects". They don't require a GUI
builder to maintain. Aside from some tricky use of the LayoutManager,
they're a breeze to maintain by hand. The only disadvantage of the GUI
builder in NetBeans is it won't read arbitrary classes and allow you to
edit them. If you loose the special layout fie it uses ("form", I
think) you can't edit the class source files with the builder any more.
(Hint: make certain the form file is under source code control.)

I may give NetBeans a try and see if it engages my despite as strongly
as VisualAge did

OTOH there's that aphorism, "code generation is a design smell". (From
here: http://c2.com/cgi/wiki?CodeGenerationIsaDesignSmell )
The upshot is: what's the point of even *having* the generated classes,
if the "form" file contains everything necessary to build the UI?

-- JK

 

[Mark Space]

OTOH there's that aphorism, "code generation is a design smell". (From
here: http://c2.com/cgi/wiki?CodeGenerationIsaDesignSmell )
The upshot is: what's the point of even *having* the generated classes,
if the "form" file contains everything necessary to build the UI?

Well, in fact the "form" file won't have everything. It has the GUI
component layout (or something like that) only. You still edit the code
and customize it (hopefully just with Interfaces and addListener
methods). The GUI tool just does the grunt work of generating an
attractive, robust component layout.

In theory anyway, I haven't tried it for large projects.

All NetBeans GUI classes (that I've used) look like this:

public class YourNameHere extends JFrame {

public YourNameHere() {
initComponents();
// .. add more here
}

private initComponents() {
// machine generated code here
}

//.. more stuff, most of it added by you

// machine generated private fields here
private JComponent someField;

}

And that's it. When the JFrame is re-generated, only the machine
generated sections are touched. The rest of the class that you have
edited remains unchanged. This allows you to switch between editing
code and using the GUI editor freely, with out issue, as long as you
don't touch the machine generated parts.

In practice, this has worked really well for me, and I think it would be
very easy to adapt to almost any sane framework or design. You would
have problems I think if the design called for exceptionally
heavyweight, complicated GUI objects that were also subject to constant
wholesale revision.

If you have some specific instance or complaint that you'd like me to
try out, if it's not too complicated, I'll give it a shot and report
back with the results (before/after code, etc). I'd be interested to
see myself how it works with more sophisticated stuff that what I've
done with it.

 

[Arne Vajhøj]

Right now, I have a program that you run off command prompt by typing:
java progName arg0, arg1, .....

like many homemade programs out there. Fine and terrific for me, but
not for the average joe who doesn't know how to access a file
directory....

So, are there any recommendations of how to make a more user-friendly
graphical interface that can consist of a form and input entries? Like
java.util.form or something?

I also use eclipse, but creating an entire view/plugin takes up a lot
more space/time than I want for simple programs.

So, I'd just like to hear suggestions on your favorite ways to make
simple programs accessible to non-technical users. Til then, I will
continue to use command prompt as I always have...

Make a GUI.

Swing or SWT depending on what you prefer.

Either handcode (it is not that hard if you spend a few
hours learning) or use a GUI builder (NetBeans Matisse,
Eclipse VE etc.)

Arne

 

[Arne Vajhøj]

Depending on the nature of the UI. Yeah, for simple throwaway things a
GUI builder can be OK, but I've never met a GUI builder that can build
code that's simpler and clearer than code I could write by hand;
much less immune to the eventual near-certain market death of the
UI-builder tool in question. IOW it's likely that a day will come when
the generated code will *have* to be maintained by hand.

IMO UI builders are at best a crutch, and it's really better to
learn how to build a UI by hand. Of course it's been a while since
I bothered to even try any such tools, so perhaps the state-of-the-art
has improved dramatically in recent years?

Most Java programmers would agree with this.

But I would be reluctant to draw any conclusion, because
users of several other languages like GUI builders.

Sure the code is not as human-readable as hand-written code. But
usually the task is to provide a working GUI in a cost efficient
manner - not to produce the most brilliant code possible.

Arne

 

[Arne Vajhøj]

OTOH there's that aphorism, "code generation is a design smell". (From
here: http://c2.com/cgi/wiki?CodeGenerationIsaDesignSmell )
The upshot is: what's the point of even *having* the generated classes,
if the "form" file contains everything necessary to build the UI?

I guess that author prefer a Java pure interpreter, because
that class files on disk and JIT output in memory is a bad thing.



Arne

 

[JK]

I guess that author prefer a Java pure interpreter, because
that class files on disk and JIT output in memory is a bad thing.

No. The discussion on the page I cited ranges rather widely, but
for me the important realization is:

If you need to generate code, the INPUT to the code-generation
process is the source code. And the source code is what humans
should deal with and keep under version control. Any modification
of the generated code is going to lead to headaches, because it
breaks the relationship between the high-level source and the
generated product. This is why we generally keep Java source,
not bytecode or assembly code generated from Java source, in our
Subversion repos; and if someone tries to fix a bug by editing
a class file directly, we fire them.

In recent years I've started generating my UIs based on simple
textual or XML descriptions. Those descriptions become the source,
along with the engine that converts a UI description into a
running UI. I'm very happy with this arrangement; I spend very
little time thinking about UI code these days. Same goes for
DB-access layers. Of course there are rare cases where this
approach is too limited, but there are sufficient hooks available
in the rendering engine that make it easy to integrate custom
code when necessary.

The problem with most GUI builders is that the input to the code
generation process is human activity -- drag-and-drop, point-and-click
-- that *can't* be placed under version control, or even stored in
any meaningful way at all. So that's my principled objection to
GUI generator tools. YMMV.

-- JK

 

[Mark Space]

The problem with most GUI builders is that the input to the code
generation process is human activity -- drag-and-drop, point-and-click
-- that *can't* be placed under version control, or even stored in
any meaningful way at all. So that's my principled objection to
GUI generator tools. YMMV.

That's a bit like saying that the output of a text editor isn't suitable
for revision control, because it's the result of human activity, typing
keys on a keyboard.

Just FYI, here's part of a .form file I just started in a small personal
project. (Just part because the whole thing is rather long.)


<?xml version="1.0" encoding="UTF-8" ?>

<Form version="1.3" maxVersion="1.6"
type="org.netbeans.modules.form.forminfo.JFrameFormInfo">
<NonVisualComponents>
<Menu class="javax.swing.JMenuBar" name="jMenuBar1">
<SubComponents>
<Menu class="javax.swing.JMenu" name="jMenu1">
<Properties>
<Property name="text" type="java.lang.String" value="File"/>
</Properties>


I think that's pretty easy to place under revision control.

 

[Andrew Thompson]

Right now, I have a program that you run off command prompt by typing:
java progName arg0, arg1, .....

like many homemade programs out there. Fine and terrific for me, but
not for the average joe who doesn't know how to access a file
directory.... ...
I also use eclipse, but creating an entire view/plugin takes up a lot
more space/time than I want for simple programs.

'Simple' for who? You, the developer, or (your average)
'Joe' the end user?

The sad fact is that it is usually a lot easier(/simpler)
to write a program that does what it needs to do when
given a very restricted and precise set of inputs, but
coming up with that precise list is not easy for YAJ.

If you want to make is easy for YAJ, you will probably
need to throw in a JFileChooser for getting a (e.g. image)
file to work with, a JColorChooser to select that slightly
bluish shade of green the user wants as the BG flood fill
color, a JComboBox to set the tolerance of the fill..

OTOH, there are numerous advantages to writing classes
that can be used both ways. For example, if the class is
to be used by a 'headless' machine to programatically
change images, like a server, or if it makes any sense
to have another program churn out a file with 1000
invocations on the simple code using different parameters,
or for use with another GUId desktop application that
can already specify the exact parameters to use.

 

[JK]

That's a bit like saying that the output of a text editor isn't suitable
for revision control, because it's the result of human activity, typing
keys on a keyboard.

No, I'm saying the *input* of a text editor -- the motions I make
as I push the keys with my fingers -- isn't suitable for revision
control. However, the output of a text editor has the nice property
that it completely captures the intent of the input, so in this case
there's no effective difference between input and output.

Just FYI, here's part of a .form file I just started in a small personal
project. (Just part because the whole thing is rather long.)


<?xml version="1.0" encoding="UTF-8" ?>

<Form version="1.3" maxVersion="1.6"
type="org.netbeans.modules.form.forminfo.JFrameFormInfo">
<NonVisualComponents>
<Menu class="javax.swing.JMenuBar" name="jMenuBar1">
<SubComponents>
<Menu class="javax.swing.JMenu" name="jMenu1">
<Properties>
<Property name="text" type="java.lang.String" value="File"/>
</Properties>


I think that's pretty easy to place under revision control.

Yes. This is both an output and an input to the tool, I
expect. If this file lets the whole layout be re-loaded into
the GUI tool and edited -- *and* if the code it generates
doesn't require manual mods by humans -- then cool; this is
exactly the thing that ought to be version-controlled.

Other UI-builder tools I've used have not provided such an
easily-manageable representation of a layout; they just
spewed out several dozen pages of code, which humans often
had to (or were tempted for the sake of expediency to) maintain,
and which was sometimes not re-digestible by the tool. So
in that case the output didn't fully capture the intent of
the human neuro-muscular input -- the result had to be
processed further, which led to ongoing pain during the
maintenance cycle.

Anyway, I will say you've prompted me to think about
these issues more clearly. I really will take a look at
NetBeans

-- JK

 

[Arne Vajhøj]

If you need to generate code, the INPUT to the code-generation
process is the source code. And the source code is what humans
should deal with and keep under version control. Any modification
of the generated code is going to lead to headaches, because it
breaks the relationship between the high-level source and the
generated product.

> The problem with most GUI builders is that the input to the code
> generation process is human activity -- drag-and-drop, point-and-click
> -- that *can't* be placed under version control, or even stored in
> any meaningful way at all. So that's my principled objection to
> GUI generator tools.

I really can't follow that argument.

If you use a GUI builder you do certain drop and drag
and store the resulting files in source control. You
do not store the drop and drags.

If you don't use a GUI builder you type code and
store the resulting files in source control. You do
not store the typing.

Especially with todays IDE's that generate constructors,
getters/setters, interface implementation method stubs
etc. then I can't see a big difference.

Arne

 

[Arved Sandstrom]

Depending on the nature of the UI. Yeah, for simple throwaway things a
GUI builder can be OK, but I've never met a GUI builder that can build
code that's simpler and clearer than code I could write by hand;
much less immune to the eventual near-certain market death of the
UI-builder tool in question. IOW it's likely that a day will come when
the generated code will *have* to be maintained by hand.

IMO UI builders are at best a crutch, and it's really better to
learn how to build a UI by hand. Of course it's been a while since
I bothered to even try any such tools, so perhaps the state-of-the-art
has improved dramatically in recent years?

-- JK

Provided that I know what the IDE is producing for me I see no reason to
handcode it. I'm rather more familiar with what NetBeans and Eclipse do, so
for sake of argument I fired up VS Express 2008 for C#, and called for a new
Windows Forms app. With absolutely no GUI elements other than a single
starting form, there are two very simple classes, one for the Form and one
for the app (the Main method). The generated code, as for Eclipse and
NetBeans, tells you what you can edit and what you can't. It's all there for
inspection, it's simple, and best of all I didn't have to write it.

Adding to that, I drag in a label, text box, and a button, and the generated
code is again very clear. There's a fair amount of code now for a GUI this
simple, but it's mostly book-keeping.

Finally I double-click the button, and a third file opens up (a second
partial class, so there's still 2 classes) for the implementation of the
button Click method. This method also automatically gets added as a handler.

So far I've done no coding at all, and there's roughly a hundred lines of
code. I understand what everything is doing, nothing is hidden away, and
there is absolutely nothing there that I would have wanted to handcode. You
couldn't make it clearer if you did handcode it - you'd just waste your time
and your employer's. Furthermore, none of that code is tied to the GUI
builder - it's all clean C#/.NET.

My experience with the latest incarnations of VS express, NetBeans and
Eclipse/IBM RAD (and similar GUI builders like Glade on Linux) is that these
same observations scale to many forms/screens, many widgets, and lots of
handlers. Way back in the day I did write Windows apps and JSP and ASP and
swing/AWT by hand, but those days are over with. Don't get me wrong - I
still inspect the generated code a lot, and ultimately you have to write
your own code inside stubs, but provided you understand what your IDE does
you gain very little by writing your own stuff.

This is just me. YMMV.

AHS

 

[Arne Vajhøj]

The .java source file is the portable artifact, the .form file is not.
Store the .java in version control. That way people who do not have an
IDE that supports the .form file will still be able to check out and
build the project.

I believe that the GUI builder should only use the Java code - not extra
files.

Arne