Good tool for developing Swing based GUI

M

marcussilfver

I want to use Swing for developing the GUI of a web based poker game.

I downloaded Eclipse and cut'n pasted a Swing "hello world"
application (just for testing if Eclipse supports Swing). Swing is a
part of the J2EE standard, yes? Anyhow the application run correctly,
showing the Swing components.

My questions:

1) Should I go for some other tool than Eclipse to make my Swing GUI
developement easier?

2) I becomes kind of confused when I read on the net about plugins
that enhances Eclipse with Swing support. I guess they only mean a
plugin that adds the feature of drag'n dropping Swing components to
the workspace? Since compiling and running Swing seems to work fine.

3) Does Eclipse support building GUI:s by drag'n dropping buttons,
sliders etc on a workspace or do I have to get JBuilder to have that?
Coding it all by hand seems like to much work.

thanks
 
A

Andrew Thompson

I want to use Swing for developing the GUI of a web based poker game.

I downloaded Eclipse and cut'n pasted a Swing "hello world"
application (just for testing if Eclipse supports Swing). Swing is a
part of the J2EE standard, yes?

No - J2SE. And J2EE is not so much a standard,
as a specification.
...
1) Should I go for some other tool than Eclipse to make my Swing GUI
developement easier?

Once you understand the AWT and Swing layouts,
I guess some of the D'n'D plug-ins might speed
GUI development.
3) Does Eclipse support building GUI:s by drag'n dropping buttons,
sliders etc on a workspace or do I have to get JBuilder to have that?

See <http://profectus.com.au/ee_programming_javaide.html>
for one developer's take on IDE's with a GUI builder. The
author prefers NetBeans/Matisse..
Coding it all by hand seems like to much work.

Trying to create D'n'D GUI's before understanding
Java layouts will cause some angst, as well.

--
Andrew Thompson
http://www.athompson.info/andrew/

Message posted via JavaKB.com
http://www.javakb.com/Uwe/Forums.aspx/java-general/200705/1
 
S

SomeBloke

I want to use Swing for developing the GUI of a web based poker game.

I downloaded Eclipse and cut'n pasted a Swing "hello world"
application (just for testing if Eclipse supports Swing). Swing is a
part of the J2EE standard, yes? Anyhow the application run correctly,
showing the Swing components.

My questions:

1) Should I go for some other tool than Eclipse to make my Swing GUI
developement easier?

2) I becomes kind of confused when I read on the net about plugins
that enhances Eclipse with Swing support. I guess they only mean a
plugin that adds the feature of drag'n dropping Swing components to
the workspace? Since compiling and running Swing seems to work fine.

3) Does Eclipse support building GUI:s by drag'n dropping buttons,
sliders etc on a workspace or do I have to get JBuilder to have that?
Coding it all by hand seems like to much work.

thanks

Eclipse has a visual editor plugin that can be installed by going to
Help/Software Updates/Find and install. This may be what you are looking
for.

Hope this helps,

Tim.
 
T

Thomas Kellerer

Silly me, no. J2EE *is* a standard that includes
a variety of specs. ..Oops!
No you were right :)
The standard is JavaEE, it's no longer called J2EE

Thomas
 
B

Bent C Dalager

I want to use Swing for developing the GUI of a web based poker game.

I downloaded Eclipse and cut'n pasted a Swing "hello world"
application (just for testing if Eclipse supports Swing). Swing is a
part of the J2EE standard, yes? Anyhow the application run correctly,
showing the Swing components.

My questions:

1) Should I go for some other tool than Eclipse to make my Swing GUI
developement easier?

If you aren't familiar with Swing and its component layout system,
then you should use some drag-and-drop type GUI design tool in order
to learn. I don't know what Eclipse offers for this. JBuilder was very
good back when I was learning this.

If you _are_ familiar with Swing, then you're probably better off
doing it by hand as this allows you to write properly factored GUI
setup code. Automated tools tend to make a mess out of things. If you
are aiming for a very artsy GUI for the poker game, you are probably
also better off doing it by hand and possibly writing your own layout
manager. Which I am told isn't difficult.
2) I becomes kind of confused when I read on the net about plugins
that enhances Eclipse with Swing support. I guess they only mean a
plugin that adds the feature of drag'n dropping Swing components to
the workspace? Since compiling and running Swing seems to work fine.

I expect you are right. Java Swing is part of the J2SE that you will
already have and so you can run Swing applications from Eclipse out of
the box.
3) Does Eclipse support building GUI:s by drag'n dropping buttons,
sliders etc on a workspace or do I have to get JBuilder to have that?
Coding it all by hand seems like to much work.

Hand-coding GUIs isn't a lot of work, but depending on what layout
manager you are using, it may be very confusing and unsatisfying
unless you're very familiar with that particular layout manager. In
particular, trying to manually set gridbaglayout constraints is an
exercise in frustration for the beginner (that is not a layout manager
I would recommend at any rate but it seems popular enough).

The main benefit in hand coding is that you can write GUI layout code
that is actually readable and maintainable into the future as well as
being properly modular. Also, it can be considerably faster than
fiddling around with dragging, dropping, pulling and whatnot with the
components in a GUI builder. But you do need to know what you're
doing for this to be a workable approach.

Cheers
Bent D
 
L

Lew

Bent said:
If you aren't familiar with Swing and its component layout system,

That should be if you /are/ familiar with Swing then use a GUI.
then you should use some drag-and-drop type GUI design tool in order
to learn. I don't know what Eclipse offers for this. JBuilder was very
good back when I was learning this.

If you _are_ familiar with Swing, then you're probably better off
doing it by hand as this allows you to write properly factored GUI

If you are /not/ familiar with Swing then you should do it by hand until you
are or you won't understand anything.
setup code. Automated tools tend to make a mess out of things. If you

Automated tools make a mess out of things for people who don't know how to do
it by hand. They are very useful once you understand what they are automating.
are aiming for a very artsy GUI for the poker game, you are probably
also better off doing it by hand and possibly writing your own layout
manager. Which I am told isn't difficult.

Some people relate to code better, some to visual metaphors when writing GUI
code. Either way, doing it by hand first will teach you what's happening,
otherwise you have no control with either the hand-coding or the GUI-tool
approach.
Hand-coding GUIs isn't a lot of work, but depending on what layout

Nor is GUI-coding, if you have some hand-coding experience to inform your work.
manager you are using, it may be very confusing and unsatisfying
unless you're very familiar with that particular layout manager. In
particular, trying to manually set gridbaglayout constraints is an
exercise in frustration for the beginner (that is not a layout manager
I would recommend at any rate but it seems popular enough).

Check out the Swing tutorial on java.sun.com.
The main benefit in hand coding is that you can write GUI layout code
that is actually readable and maintainable into the future as well as
being properly modular. Also, it can be considerably faster than
fiddling around with dragging, dropping, pulling and whatnot with the
components in a GUI builder. But you do need to know what you're
doing for this to be a workable approach.

You need to know what you're doing to use any approach.

For many people who understand Swing programming, using a GUI tool enhances
productivity. It's impossible to know in one's own case until one has tried
it both ways. Coding the text first as one is learning often helps master the
details; certainly reviewing any GUI-generated code to achieve full
understanding is a necessity.
 
B

Bent C Dalager

If you are /not/ familiar with Swing then you should do it by hand until you
are or you won't understand anything.

Having used the exact opposite approach, I would say this is wrong. Of
course, if you steer well clear of gridbaglayout and use a layout
manager with more intuitive constraints objects it might be correct.
Automated tools make a mess out of things for people who don't know how to do
it by hand. They are very useful once you understand what they are automating.

Having all my GUI initialization code in one single mammoth block of
code is what I call a mess. This is what JBuilder does, I'm not
familiar with the competition.
Some people relate to code better, some to visual metaphors when writing GUI
code.

I am not sure what you are trying to say.
Either way, doing it by hand first will teach you what's happening,
otherwise you have no control with either the hand-coding or the GUI-tool
approach.

If you are actually _trying_ to learn how it works, then using a GUI
editor is a perfectly good tool to do so. At least, it is if it does
what JBuilder does and produces source code that is somewhat readable
so you can see how it's doing its stuff. If you're not really trying,
of course, then you're not going to learn anything in any case.
Nor is GUI-coding, if you have some hand-coding experience to inform your work.

I find GUI helpers to be more about fiddling around than about being
effecient. I get the same job done in either case, but writing by hand
takes me far less time than the point-and-click approach.

There might of course be some special highly verbose activities that
are faster with point-and-click, such as creating event handlers
perhaps, or creating new events to fire off from your class. I am
mostly thinking of component placement and layout when I say that
hand-written is faster.
You need to know what you're doing to use any approach.

Not really. JBuilder lets you plonk down your components where you
want them to be and will do a semi-decent job of cleaning up your GUI
and converting it to the layout manager of your choice. The result may
not be the image of perfection (if memory serves, the result doesn't
always resize very gracefully), but depending on your requirements it
can be perfectly servicable.

Cheers
Bent D
 
L

Lew

I am not sure what you are trying to say.

I am saying that some programmers are more comfortable with writing code in a
text editor and some with GUI tools. It's a matter of cognitive style. It's
not so much whether one is better but whether it's better for a particular
individual.
If you are actually _trying_ to learn how it works, then using a GUI
editor is a perfectly good tool to do so. At least, it is if it does
what JBuilder does and produces source code that is somewhat readable
so you can see how it's doing its stuff. If you're not really trying,
of course, then you're not going to learn anything in any case.

I do agree with you. I think it's important to really understand code in the
editor and not just blindly rely on the GUI generator. Your example of a
"mess" is a reason - in your case understanding the GUI led you to use it less.

I see what you mean by GUI-generated code being messy.
I find GUI helpers to be more about fiddling around than about being
effecient. I get the same job done in either case, but writing by hand
takes me far less time than the point-and-click approach.

So the editor provides a better impedance match to your cognitive style.

For the record, I tend to be more comfortable in an editor than in a GUI tool
myself.
Not really. JBuilder lets you plonk down your components where you
want them to be and will do a semi-decent job of cleaning up your GUI
and converting it to the layout manager of your choice. The result may
not be the image of perfection (if memory serves, the result doesn't
always resize very gracefully), but depending on your requirements it
can be perfectly servicable.

It is dangerously irresponsible to advocate that programmers not understand
what they're doing.

It isn't about whether GUI tools let you ignore what you know but whether you
have the knowledge in the first place. I have far too much experience working
with so-called "developers" who know a tool (like Matisse [in NetBeans,
another fine IDE] or Struts) but are clueless when it comes to what the tool
does.

Knowledge is power and deliberate ignorance in this profession is a sin.

People content to use GUI tools to write Swing apps without knowing what is
going on are certainly not programmers, and should not be permitted to collect
paychecks as programmers.
 
B

Bent C Dalager

Not really. JBuilder lets you plonk down your components where you
want them to be and will do a semi-decent job of cleaning up your GUI
and converting it to the layout manager of your choice. The result may
not be the image of perfection (if memory serves, the result doesn't
always resize very gracefully), but depending on your requirements it
can be perfectly servicable.

It is dangerously irresponsible to advocate that programmers not understand
what they're doing.

It isn't about whether GUI tools let you ignore what you know but whether you
have the knowledge in the first place. I have far too much experience working
with so-called "developers" who know a tool (like Matisse [in NetBeans,
another fine IDE] or Struts) but are clueless when it comes to what the tool
does.

Knowledge is power and deliberate ignorance in this profession is a sin.

People content to use GUI tools to write Swing apps without knowing what is
going on are certainly not programmers, and should not be permitted to collect
paychecks as programmers.

I don't really know what the OP's situation is, but I am guessing that
the poker software is some sort of hobby project. As such, I don't
think little things like not entirely understanding what goes on
should hold him back. GUI-design the GUI and get on with things.
Later, perhaps he will develop more of an understanding of what is
actually happening with that code and clean it up some way or other. I
find this a perfectly reasonable approach for non-professional
projects.

For professional projects, you either have to know exactly what you're
doing all the time (typically the case in small shops) or else you
need to have procedures in place that help ensure the continuing high
quality of the system in the face of having rookies in training and
such around. Assuming the latter, then, again, it is perfectly
acceptable to have the rookie blunder about with the GUI design tool
because you're going to have a QA program in place that takes this
into account and ensures both that he doesn't get to check in rubbish
code and also that he'll improve as a programmer in the process.

Cheers
Bent D
 
L

Lew

I don't really know what the OP's situation is, but I am guessing that
the poker software is some sort of hobby project. As such, I don't
think little things like not entirely understanding what goes on
should hold him back.

I believe you missed my point.

I said people /content/ to lack understanding should be driven out of the
profession, with prejudice. No one completely understands what they're doing
in software development and stays employed; things change too quickly to
master any one platform in complete picayune detail. It's the commitment to
understand that distinguishes those of value from patzers.

Good programmers are incredibly effective without understanding everything.

There is nothing at all wrong with ignorance, as it's a curable condition.
It's the refusal to learn that is the crime.
 
P

Patricia Shanahan

Lew said:
I believe you missed my point.

I said people /content/ to lack understanding should be driven out of
the profession, with prejudice. No one completely understands what
they're doing in software development and stays employed; things change
too quickly to master any one platform in complete picayune detail.
It's the commitment to understand that distinguishes those of value from
patzers.

Good programmers are incredibly effective without understanding everything.

There is nothing at all wrong with ignorance, as it's a curable
condition. It's the refusal to learn that is the crime.

Isn't it necessary, though, to choose what to learn?

I'm about as committed to reducing my own ignorance as anyone, a full
time student with 32 years industry experience.

If I just wanted to make a graphical display work, I might choose to do
whatever would achieve that with the minimal learning effort on my part,
not because I don't want to learn in general but because I just don't
have time to learn even everything that strongly interests me.

Patricia
 
L

Lew

Patricia said:
Isn't it necessary, though, to choose what to learn?

I'm about as committed to reducing my own ignorance as anyone, a full
time student with 32 years industry experience.

If I just wanted to make a graphical display work, I might choose to do
whatever would achieve that with the minimal learning effort on my part,
not because I don't want to learn in general but because I just don't
have time to learn even everything that strongly interests me.

My complaint isn't about smart people making choices about what to learn with
limited time and energy, but about people completely refusing to understand
what is going on.

Your statement, "I'm about as committed to reducing my own ignorance as
anyone," shows you as one of the Good Guys. It is those who say, "I never
need to learn because the Auto-Frabjulous Code Generator does all the work for
me" that I excoriate.

For example I've worked with people who knew what methods the Struts API had
but nothing about the Model-View-Controller paradigm behind it, and showed no
interest in learning more, on a team with several consecutive Struts projects
where that lack of knowledge was causing harm.

The trouble with how I made my point, perhaps, is that I was speaking in
absolutes about situations that manifest as relative. I should never generalize.

A very wise head in software told me that a responsible practitioner spends
20% again their work time in study and learning.
 
E

Ed Tidwell

Bent said:
Having used the exact opposite approach, I would say this is wrong. Of
course, if you steer well clear of gridbaglayout and use a layout
manager with more intuitive constraints objects it might be correct.

I agree with this statement. I learned Swing by doing JBuilder and used
the X-Y Layout manager. If you take this approach it will work just
like the VB IDE.

It is a great way to learn all of the events and 'bean' attributes of
each Swing JComponent.

JBuilder will force you to have a jbInit() method. NetBeans will have
blocks of code that you can't edit.

When you build a large GUI it gets to be a real pain to maintain and
re-use things.

For this reason I wrote a Java Swing application framework this is open
sourced. Look for JSR 296 to be the better solution when Java 7 ships.
I built the framework out of need back when I was using the Java 1.3
JDK. https://tframe.dev.java.net/

The thing I REALLY LIKE about JBuilder and I have not been able to drop
it for anything else yet is the CTRL-J macros for blowing out code and
event listeners. The ease of draging source code to the source folder
and it instantly seeing it. Having code formatting at a global and
project level. Being able to type /**<enter> and get instant javaDoc
comments based on the line below me.

NetBeans keeps getting better but it needs more polish. I'm still using
JBuilder 2005 Developer and it works fine with 1.6.

Regards,
Ed
 
M

marcussilfver

Thanks for the help everyone! I will look into things. I guess my
choise will be Eclipse and hand code stuff initially and getting some
plugin for D&D eventually (pretty soon though).
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,756
Messages
2,569,535
Members
45,008
Latest member
obedient dusk

Latest Threads

Top