Re: Nested GridBagLayout and its pitfals


"nukleus" <nukleus@xxxxxxxxxxxx> wrote in message
news:eqg01l$1u0g$3@xxxxxxxxxxxxxxx
By wrapping GridBagLayout in a helper class that
does the common things I need, I probably save
75% of the size of the gui part of the source code,
and a lot of space in the class file as well. It also
keeps my layouts consistent by enforcing common
spacings, etc. Most of my GridBagLayout code
uses one line of code for each component added,
and that is a method call with two parameters.
For example (part of one layout):

It'll break your GUI designer, if you use one.
Otherwise, just write it all by hand.
Good luck on that one.
....
If you are doing a large amount of gui code using
GridBagLayout, creating such a helper class is
well worth the effort.

The problem is that you are talking about making
things by hand, which I, personally, do not support.
At THIS stage of the game, you'd better have some
automation.

I don't support using a gui builder for anything other
than prototyping and toy applications. In the long
run doing your layouts by hand will save a lot of
time and frustration. With a wrapper class like I use,
coding by hand with GridBagLayout is very simple.

Also, using a gui builder prevents you from creating
systems that automatically build gui from data (like
a list of settings names and types) and methods that
build similar interfaces with minor variations. Having
the gui-builder mindset means you will miss out on
chances to make your code easily maintainable in
this way.

12. Try not to use weights, if at all possible.
If your frame has several groups of GUI elements,
each having several elements, then what you think
is space distribution may end up being utterly
different in run time and you'll waste hours if
not days, trying to play with those weights.

Having zero weights can cause strange effects.
Always use weights, but choose from a limited set.
Normally you have some group of components
that together should use all of the extra height or
width (text fields, text areas, sliders, editable combo
boxes, lists, etc.) and others that should have a
fixed size (labels, buttons, etc), and you can get by
with always using a weight of either 1000000 or
..000001.

That is another problem, the inconsistency of behavior.
In some instances, changing weight from 0 to 0.00000001
changes the behavior in such drastic manner,
it is well beyond comprehension.

To be fair, the GridBagLayout documentation does
say "Unless you specify a weight for at least one component
in a row (weightx) and column (weighty), all the components
clump together in the center of their container.

Creating your own layout manager is much simpler
that you think. For some reason people will spend five
hours fiddling with GridBagLayout or SpringLayout
trying to get it to do something it wasn't meant to do,
when they could write a custom layout manager in
under an hour.

If they had enough experience to do that.

When people need a custom layout, it's usually for a
row of buttons or something; they don't need to
create a general-purpose layout manager. I've seen
people do what I describe above many times. They
have some very simple layout requirement for a few
components for which GridBagLayout and SpringLayout
are ill suited, and go through all kinds of hoops and
hours of work to try to use them. Then they decide to
write their own layout manager and find that it is trivial.
There's some kind of fear that it's "low-level work" or
something.

If the behavior of the desired layout is easy to
understand, then the layout manager is easy to design
and build.


.