Nested GridBagLayout and its pitfals

[nukleus]

I am working on one app that has few frames
to get/set various program parameters.

Some of those frames have several buttons,
several text fields with labels, several checkboxes,
a text area and, status field and a choice boxes.

To make it all look nice and clear from the standpoint
of GUI element layout, you would have to get into
some pretty hairy issues.

Working with it, what I was seeing is nothing less
than magic. Buttons would dissapear in run time,
text fields would have Y size several times smaller
than the font Y size and on and on an on.
I could not believe my eyes seeing all that madness,
and I ended up spending probably 10 times more time
on it all, than it should have taken me, or any
mortal for that matter.

I decided to use my gadget and review the 25000
article archive of this group, going back at least
half a year, and see if this issue was ever discussed.
The result was nothing but shock. There were but a
handful of articles, most in Sept. 2006, addressing
this issue, and even there, the advices were so
scetchy, that they wre virtually useless,
in case of just about any realistic frame imaginable
having more than a few similar GUI elements.

So, let us attempt to fix that problem
and put an end to the whole grdibag debate.

I was recomended by one of people here to read the
Sun's tutorial on GridBagLayout. Yes, I agree, it
is humanly readable, but, unfortunately, the example
it provides is nothing more than a childish invention,
and there is very little chance it is going to be of
any use to you. It does not address ANY of subtleties
of realistic layouts, having not just a bunch of buttons,
filling the entire frame, but a mix of various GUI
elements.

Finally, what i came up with, was a realization
that about the easiest and the best way of doing it,
was to use nested layout.

Here is the summary of what I have found.
It is all out of memory as I do not want to load
another piece of bloatware and wait for days
when I want to switch some tab.

1. In just about any realistic GUI frame,
you are likely to have a mix of various elements.
If you try to lay them all out using a single
GridBagLayout, you'll waste half of your life,
being blown out of the chair when you change
any parameters.

You may try to cheat and create more grid cells,
trying to properly position various unrelated
groups of elements, setting trying to make one
GUI element to occupy more than one cell in X or
Y dimension, trying to accomodate for your
positioning requirements, but it will likely
to und up in nothing less than utter frustration.

So, use nested layout instead.
Meaning: Organize all of your similar GUI
elements into logically related areas on your
frame. Group buttons in one group, labels and
text fields in another group, and so the checkboxes,
text areas and the rest of it.

2. Create separate panels for each of those groups,
where you put related items.

Use GridBagLayout for each of those panels.
For the group of checkboxes, GridBagLayout is not
the best choice as it does not guarantee the equal
Y offsets between the checkboxes.

So, for check box panel, use GridLayout instead
as it will guarantee the equal X size distribution
between all the checkboxes.

Use GridBagLayout for the frame itself, and put
all those panels into separate cells of the frame
GridBagLayout.

3. Avoid using fills as much as possible,
as their effect may be such that you'll never have
a handle on your layout. Say, for example, you have
a group of labels, in Y dimension, that label the
corresponding text fields. The entire row of labels
will be dimensioned at run time to have an X size
of the label having the longest text string.
If you use fills to pad the label column size,
and, later on, decide to change the text of your
longest label and make it much smaller, all of a
sudden, your whole layout will change.

Fills are not the absolute size of some GUI element.
They are what needs to be added to the size of a
text string, that element contains, be it label,
button, text field. That is why their are called
paddings, which should immediately turn the warning
lights on.

That means that if you use fills hoping to minimize
the size of some row or a column, you'll be sweating
half of your life to make it work, especially if you
try to resize that frame in run time.

Use insets instead. Those are guaranteed not to change
regardless of the size of your GUI element.

4. Try to keep all the values of constraints structure
at zero instead of filling them with values you THINK
will make it look better. Use only those parameters
that you feel are absolutely necessary, such as insets.

The exception is the row/column numbers and a number
of cells you want your GUI element to occupy in X or Y
dimension.

5. On all labels, use a small X padding of 3 - 6 pixels
for the labels so that the text field, following that
label in X position have some margin and does not run
into the end of the label string.

6. Try not to use fills for any of constraints structures
for each of your GUI elements, unless it is absolutely
necessary in such cases as the length of text field
in X dimension to make sure your field occupies as
much of X dimension of your frame, as possible.
Fills are only applicable to the cases where you resize
frame to make it BIGGER than what you designed with you
GUI designer, or you set the initial size of your frame
bigger than what you saw with your GUI designer.

For example, using fills on your text fields in Y dimension,
will increase the Y margin betwee the different label/text
fields in a group, which is not what you would want to do
in most cases. You would probably want them to stay equally
positioned regardless of the size of your frame
and to be guaranteed their minimum size as limited by the
font you are using and the lengths of your string.

7. Try to make your frame resizable and resize it in
run time. If all the GUI elements and groups keep sain
proportions, it means you've got all your constrains
and structure of your nested layout correctly configured.

8. If you use a GUI designer, and it generates Java code
for your constraints, panels, etc., do not modify that
code by hand. You'll waste half of your life if you
ever need to change your layout in the future, which
is pretty much inevitable.

The same exact code as generated by the GUI designer
should work like a champ in just about ANY situation
imaginable.

Forget about the minimum and preferred sizes.
They are virtually useless. If you do your
design correctly, you'll have the absolute
minimum of variour parameters to be set
as far as boundaries, sizes, etc.,
behaving the in the most predictable way
possible under the Sun.

9. Separate your GUI related code for the frame
and do not add anything to that class beyond
get/set methods for each element.

Make a superclass that extends that frame and that
is where you can add the keyboard and mouse listeners,
and all the bells and whistes to your frame. That
superclass has access to its underlying frame's
variables and has right to do anything it pleases
with those variable, even though it should not attempt
to modify the sizes, constraints etc. It all has
to be done by the code generated by your GUI designer.

10. Try not to use some proprietary layout managers
because they are not guaranteed to work with the
future versions, unless they rely on the existing
basic layouts, which you can do yourself.

Futhermore, they'll end up doing the same thing
the gridbag does, and, if you are trying to be lazy,
hoping to save some time or effort, you are likely
to regret at the end, it is all just a matter of time.

Some claim that by using some proprietary
layouts, they can save half the amount of code lines,
which is about the funniest argument possible.

Your frame look and feel is about one of the most
important aspects of your entire application.
Just about ALL the users will see with your app
is those very frames. Trying to save a few hundred
bytes or code lines is simply foolish.

11. Spend enough time on making sure your frame
behaves in a very predictable way regardless of
its size. All the GUI elemenents have to look
consistent and corresponding margins should not
change when frame is resized.

If that is the case, it implies that all your
constraints and the entire logical structure
of your frame are correct.

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.

Even if you use weights with such elements as
buttons, you may be unpleasantly suprised at
how it looks during the render time, especially
when you resize your frame.

Weights refer to relative distribution of space,
within the group of gui elements, they call
"display area" - ugggghhhh,
and not the frame as such.
So, if you only have one group of elements
in your frame, weights may work fine,
but, as in any realistically complex frame,
where you have more than one row/column of
your main gridbag, the things may and WILL
become simply bizzare. You'll sooner go nuts
than get the results you expect from all that
mess. By changing any element in a different
group of elements, the whole frame may look
utterly ugly, as those weights only affect
the elements in a group.

Even to use weights for each cell of the maing
gridbag of your frame, hoping that relationship
between groups will remain consistent, you may
be very unpleasantly surprised with the results
while resizing that frame or adding/removing
some elements.

Weights is probably close to useless if you consider
all the remifications of using them in a relatively
complex frames.

Summary:

Instead of using a single GridLayout on just about
any realistically complex frame, that has several
different types of GUI elements, group the related
elements and put them into separate panels.

Select the layout for each panel that suits your
frame design concepts in the easiest and most
natural way. Do not try to make things more complex
than necessary as about ALL you are going to get
at the end is a royal grade pain on the neck.
It won't work. Trust me.

Try to use GridLayout for all those panels
whenever possible as this is the most general
purpose layout having all the power to do just
about anyting imaginable. But it has its limitations
and unpredictability of behavior if you expect
some rows or columns to be of equal size
regarless of the label, text field or button text
string sizes.

GridLayout is not a good choice for that because the
column size relationships may change in run time and
your columns will end up of not equal size, and,
trying to make them of equal size, by using paddings
or weights, could end up being a pain on the neck
and of a grand proportions.

Use as few parameters in your constraints structure
as possible.

By using nested gridbags, your design will end up
being the simpliest possible with WAY more predictable
results, having the smallest amount of various cells
possible, and with the smallest amount of various
constraint parameters, which will eventually translate
into the most stable, predictable and flexible run
time behavior and having the minimum amount of
maintenance efforts of your code.

If you follow these few simple advises,
you'll be amazed at how much power and flexibility
you can achieve with nested GridLayout.

Good luck.

Finally, if any experts around have any comments,
it would probably be a good idea to clarify some
more subtle points and issues, or correct some
errors or philosophical fine points as this information
will become a permanent reference on this issue
and will be available through argives for generations
to come.

Simmply sending people to read some Sun "tutorial",
you are effectively sending them to hell,
as those "tutorials" cover only the most primitive
and most basic concepts having virtually nothing
to do with a realistic application.

Instead, you can spend half an hour of your time
and spill out the fine points of this most important
thing there is in the entire concept of GUI design,
GridLayout, which all would have to learn eventually
no matter what.

 

[Larry Barowski]

Use GridBagLayout for each of those panels.
For the group of checkboxes, GridBagLayout is not
the best choice as it does not guarantee the equal
Y offsets between the checkboxes.

I'm not sure what you mean by this. Of course
you can get equal y offsets or y spacing. Maybe
you meant "X" here?

So, for check box panel, use GridLayout instead
as it will guarantee the equal X size distribution
between all the checkboxes.

If you have some checkboxes with long labels
and some with short labels, you may not want
equal spacing in X.

4. Try to keep all the values of constraints structure
at zero instead of filling them with values you THINK
will make it look better. Use only those parameters
that you feel are absolutely necessary, such as insets.

The exception is the row/column numbers and a number
of cells you want your GUI element to occupy in X or Y
dimension.

I think for most layouts it's better to place components
left-to-right and top to bottom using gridwidth=REMAINDER
to end a "line". The layout is easier to modify that way.

Forget about the minimum and preferred sizes.
They are virtually useless. If you do your
design correctly, you'll have the absolute
minimum of variour parameters to be set
as far as boundaries, sizes, etc.,
behaving the in the most predictable way
possible under the Sun.

Sometimes you need certain components to be
shrinkable to zero size to get the effect you want,
so setting a zero preferred and minimum size of
zero in one or both directions is useful.

Some claim that by using some proprietary
layouts, they can save half the amount of code lines,
which is about the funniest argument possible.

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):

panel.addLabel("Color", GBLPanel.ANCHOR_EAST |
GBLPanel.FLUSH_BOTTOM);
panel.add(color_setter, GBLPanel.ANCHOR_WEST |
GBLPanel.HOG_WIDTH | GBLPanel.FILL_HORIZONTAL |
GBLPanel.FLUSH_ALL);

If you are doing a large amount of gui code using
GridBagLayout, creating such a helper class is
well worth the effort.

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.

Use as few parameters in your constraints structure
as possible.

Use mostly consistent parameters, and few choices
for weights and spacings.

GridBagLayout does not play well below preferred
size. Consider only using it within a scrolled pane
or a window that is not shrinkable below preferred
size.

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.

 

[nukleus]

I'm not sure what you mean by this. Of course
you can get equal y offsets or y spacing. Maybe
you meant "X" here?
Yep.

If you have some checkboxes with long labels
and some with short labels, you may not want
equal spacing in X.

Well, than this issue does not apply to your situation.

I think for most layouts it's better to place components
left-to-right and top to bottom using gridwidth=REMAINDER
to end a "line". The layout is easier to modify that way.

Sometimes you need certain components to be
shrinkable to zero size to get the effect you want,
so setting a zero preferred and minimum size of
zero in one or both directions is useful.


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.

panel.addLabel("Color", GBLPanel.ANCHOR_EAST |
GBLPanel.FLUSH_BOTTOM);
panel.add(color_setter, GBLPanel.ANCHOR_WEST |
GBLPanel.HOG_WIDTH | GBLPanel.FILL_HORIZONTAL |
GBLPanel.FLUSH_ALL);

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.

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.

Use mostly consistent parameters, and few choices
for weights and spacings.

GridBagLayout does not play well below preferred
size. Consider only using it within a scrolled pane
or a window that is not shrinkable below preferred
size.

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.
But, no matter what is the situation,
writing a GUI class by hand seems to be like a joke
considering where we are. It is like writing an app
with a hex calculator. Sure, some experienced users
will be able to do it, but even there, if you want
to change some things in the future, your scull may
crack trying to read back your own code if your
frame is complex enough. That is why there are GUI
design tools on the first place.

 

[Larry Barowski]

It'll break your GUI designer, if you use one.
Otherwise, just write it all by hand.
Good luck on that one. ....

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.

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.

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.

 

[Chris Uppal]

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.

It may also, in part, be a fear of failing to re-use ("NIH-phobia"). I think
that many people's reluctance to create custom Collections has a similar root.

(Though, to be fair, that's not the whole explanation.)

-- chris

 

[nukleus]

I don't support using a gui builder for anything other
than prototyping and toy applications.

Well. Thats your choice.

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.

Could be. Can you post that code here?

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.

Unfortunately, in my case, GUI is not some database
type of form with lots of repetitive elements.
It has to be hand sculpted to the most minute detail.
THAT kind of automation does not help in my case.

Having
the gui-builder mindset means you will miss out on
chances to make your code easily maintainable in
this way.

Well, I happen to think just the other way around.
Right now, i have converted about 7-8 of my frames
and all the gui designer generated code is kept
in a separate class to be extended by higher levels.
So, from now on, i can modify that gui in the easiest
possible way, within minutes, then simply switch to
another piece of bloatware and hit "build" button.
The source file is the same for both environments
and they both build nicely.

So, once the initial phase is done with,
it becomes the simpliest thing in the world to extend
that gui in the most precise way, and that GUI is
not that simple at all. Pretty intricate in fact.
Not lika full blown IDE, but not far from it.

That is how I see it.

Looking back, when I was recomended to use layouts
instead of null layout and my own on-the-fly XY layout
approach, I am not sure this whole thing is even worth
bothering with, as the code I had, after all the mods
I did to it, was probably the most optimal, the easiest
thing to maintain and modify possible, and it correctly
took into account font sizes and things like that.
So, it should render properly on just about any platform
and screen resolution.

But we are past that phase, and it was an interesting
trip to see all this layout madness as I call it,
because I have no better term for it.

I wasted more than a week trying to convert about
a dozen of my frames, which I initially estimated
should last no more than a week, and I am still not
quite done with it.

The gridbag is screwed up beyond repair as far as
I can see. I think conceptually, some things will
NEVER reconcile, just looking at behavior of weights
and fills.

So...

I have chosen the path of "mr. GUI designer, do
your trick and give me that code, which I do not
even want to see". And that code is overkill by
ANY standards. But it is fine with me. For me,
GUI, even if it takes 5% of total code, is something
worth paying attention to.

Most of the frames I converted look REALLY good,
by ANY standard I know of. It is just perfect.
I did not expect it to get THIS good.

I know. I am dealing with this issue this very moment.
I just took a lil break from it to read usenet.
I am working on the main app's frame, which is pretty
intricate. There are 3 pannels, 2 of which have text
areas either for text entry or for command history
display.

The third one is a panel that contains all the buttons,
and there are about 8 of them, 3 per each row.

All implemented using gridbags. The problem is:
I do not want buttons to be touched in ANY way.
So, I set weights to 0.

But my text areas need to adjust when you resize.
So, beside the text areas, each panel has several
labels, text fields, choice boxes, and checks.
All have to look real good.
So, I set the X weights on all the rows but the
text area to 0, and set text area weight to 1.0.

The same is with other panel that ALSO has a text
area.

Then, in the frame's gridbag, I set Y weight of one
panel to 0.3 (of the whole frame), and the other
panel at ...

At what should I set it?
Well, When I set it to 0.5, hoping that the panel
with buttons would take about 20% of total Y dimension,
the things would simply go bezerk, and I suspect
because total weight exceeds 1.0. The entire button
pannel just disspeared in run time, and text areas
would not be of size corresponding to weights.
The one with smaller weight was rendered bigger,
and the one with bigger weight, was rendered smaller,
and I had to waste at least an hour till I realized
that the panel with bigger weight, that rendered
smaller, should had its weight REDUCED in order to
make it render LARGER.

Kinda madhouse logic. But I am sure there is an
explanation for this monkey logic somewhere.

And how could I possibly know how much weight
give to a button panel? I do not use paddings
at all, if I can help. So, what weight should
i use considering that the weight of my button
pannel is unknown, is something beyond believable.

Yes, I suspect if i did it by hand, I could easily
calculate the correct ratios.

Anyway, the gridbag concept is flawed as far as
I can see.

Exactly.

Weird, ain't it?
Could you explain the effect of going from 0 to 0.0001
or from 1 to 100000?

What does it do?
May be I should actually try it. The problem is this
GUI designer is a buggy as hell. Not sure how could
one of the biggest and baddest manufacturers out there
could even release this kind of crap.
It swallows 50 megs per mouse click and, after about 5-10
minutes of work, starts freezing my box, yelling at me
that it runs out of heap. It says there is only 10 megs
of heap left.

Ever heard?

10 megs of heap is not enough just to lay out a 20k source
code, at the VERY most. And I have about 1 Gig of virtual
memory, and this stupid thing is telling me it does not
have enough heap. Well, go get it, dummies, I've as much
as you want. But, if i do not exit this "super" IDE,
the box simply eventuall freezes and I can not even
exit the IDE. You can't close the damn thing.

Now, if the biggest and the baddest produce THIS kind
of "advanced" tools, hailed on every corner, then
what are you asking of ME, a mere mortal?

:--}

But I tell ya, my stuff NEVER behaves like that
royal grade crap, where one hand does not even
know what the other is doing. Weirdest thing I have
EVER seen in my life.

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.

Well, but that is a chicken shit level.
Even if i DO specify it, it is still behaving
in the most insane manner I have ever seen.

True. And I did that, and about the only problem
I had is the Y size of menu and a title bar.
When I added menus, all of a sudden the top row was
obscured by the menu, and I couldn't find any place
where I could get the menu size.

The same thing is with scrollbar. But, if I recall
correctly, you can get a scroll bar size by creating
a scroll pane or something of a kind.
Never tried it, but there could be even problem with
that, because, I suspect, the scrollbar size may be
returned as 0, unless the pane is shown, which is about
the weirdest thing imaginable. And I wouldn't like
to flash things and make some funky panes just to
get the X/Y size of a scroll bar. This stuff is
simply obscene.

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.

I totally agree. Use gridbag ONLY if you have some
pretty sophisticated and pretty complex GUI.
Othewise, it is a ROYAL pain on the neck.

Then they decide to
write their own layout manager and find that it is trivial.

Isn't it?

About the ONLY problem I had was that i could not
get the insets that give me the value of a title bar
and a menu, because there seems to be no way of getting
them until the frame is shown. So, the old code, used
addNotify() and it kinda worked, but not for the menu.
The result was utterly different on different compilers.

That is how I got into this layout madness.

There's some kind of fear that it's "low-level work" or
something.

Well, if I knew what am I getting into,
I would NEVER, even for a moment have considered it.
But it was a good experience I guess, and I am
pleased with the overall results.

You see, the way I did it in the on-the-fly XY layout
is to create a few variables telling the relative
offsets of various columns and X/Y sizes of text
fields, checkboxes, etc. Then, as things would get
layed out on the fly, I would use the Y size of text
fields, based on the font size, and add a inter-field
margin to it, and the next row would get layed out
at that Y position. It worked just perfectly and
the code was VERY easy to modify and maintain.
It was all just a matter of cut and past of a block,
containing a row, and it would contain all correct
offsets, and then paste it where I wanted to add
more elements to extend the GUI.
By the time I layed out all the rows,
I had a final value to be used to set the frame's size.
Worked like a champ.

The whole trip of adding or modifying it, would take
SECONDS, LITERALLY. Well :--}
But no more than a couple of minutes.

And now?

Just look at this mess this thing generated.
It is such an overkill, that i can hardly believe
all these piles of code it generated.
For every single gui element, there are couple of
heavy duty calls with about 10 arguments each.
This stuff is probably 5 times the size of my
original code. Well, at least 2 times, thats fer sure.

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

Well, if you were here when I was asking about
how to get the Y size of a title bar and a menu,
and proper insets, I wouldn't have to waste more
than a week of my time. Even my system crashed
to the point where I had to reinstall the whole
world from scratch, which is like having a heart
attack.

But it is all done deal now, more or less.

But thanks for your feedback.

 

[nukleus]

It may also, in part, be a fear of failing to re-use ("NIH-phobia"). I think
that many people's reluctance to create custom Collections has a similar root.

Well, looks like something smart sounding.
But where is the specifics of the issues?

(Though, to be fair, that's not the whole explanation.)

I bet you it isn't.
It isn't even CLOSE to ANY kind of explanation.
You'd have to look at specific situation and
suggest a better way of doing it OVERALL,
considering ALL sorts of things, such as esthetics,
functionality, convenience, maintenance and ease of
extendability of relatively complex GUI designs,
and that is not the end of the list.

 

[Larry Barowski]

Well. Thats your choice.

It's an opinion based on experience.

Could be. Can you post that code here?

There's a snippet above.

Unfortunately, in my case, GUI is not some database
type of form with lots of repetitive elements.
It has to be hand sculpted to the most minute detail.
THAT kind of automation does not help in my case.

Most desktop applications have a lot of gui repetition
and many similar gui elements, but yours may be
different.

Then, in the frame's gridbag, I set Y weight of one
panel to 0.3 (of the whole frame), and the other
panel at ...

At what should I set it?
Well, When I set it to 0.5, hoping that the panel
with buttons would take about 20% of total Y dimension,
the things would simply go bezerk, and I suspect
because total weight exceeds 1.0. The entire button
pannel just disspeared in run time, and text areas
would not be of size corresponding to weights.
The one with smaller weight was rendered bigger,
and the one with bigger weight, was rendered smaller,
and I had to waste at least an hour till I realized
that the panel with bigger weight, that rendered
smaller, should had its weight REDUCED in order to
make it render LARGER.

Kinda madhouse logic. But I am sure there is an
explanation for this monkey logic somewhere.

And how could I possibly know how much weight
give to a button panel? I do not use paddings
at all, if I can help. So, what weight should
i use considering that the weight of my button
pannel is unknown, is something beyond believable.

Yes, I suspect if i did it by hand, I could easily
calculate the correct ratios.

Normally you don't need any ratios. Give elements
in rows or columns that need all the extra space a
high weight and those in rows or columns that
should have a fixed size a low weight.

Anyway, the gridbag concept is flawed as far as
I can see.

Behavior between minimum and preferred size is
flawed in my opinion. This was changed to something
much better in one of the Beta releases or pre-releases,
then changed back because it broke existing applications.
Why they didn't just add a flag to support the new
behavior, I don't know; maybe they thought it would be
too much of a maintenance hassle.

Weird, ain't it?
Could you explain the effect of going from 0 to 0.0001
or from 1 to 100000?

Only the ratios of total weights between different rows
and between different columns matter. If you multiply
all the weights in the layout by 1000000, there will be
no change. I (mostly) use a high weight and a low weight
instead of a high weight and zero weight, so that things
still work in layouts where there are no high weight
rows or columns. If all the rows or columns have zero
weight, none of the extra space will be given to any
component, and they will clump together in the middle
as described in the documentation.

What does it do?
May be I should actually try it. The problem is this
GUI designer is a buggy as hell. Not sure how could
one of the biggest and baddest manufacturers out there
could even release this kind of crap.
It swallows 50 megs per mouse click and, after about 5-10
minutes of work, starts freezing my box, yelling at me
that it runs out of heap. It says there is only 10 megs
of heap left.

Ever heard?

10 megs of heap is not enough just to lay out a 20k source
code, at the VERY most. And I have about 1 Gig of virtual
memory, and this stupid thing is telling me it does not
have enough heap. Well, go get it, dummies, I've as much
as you want. But, if i do not exit this "super" IDE,
the box simply eventuall freezes and I can not even
exit the IDE. You can't close the damn thing.

You can probably run it with a bigger max heap size.

True. And I did that, and about the only problem
I had is the Y size of menu and a title bar.
When I added menus, all of a sudden the top row was
obscured by the menu, and I couldn't find any place
where I could get the menu size.

Why lay out menus and title bars? Frame and Dialog
do that for you.

The same thing is with scrollbar. But, if I recall
correctly, you can get a scroll bar size by creating
a scroll pane or something of a kind.
Never tried it, but there could be even problem with
that, because, I suspect, the scrollbar size may be
returned as 0, unless the pane is shown, which is about
the weirdest thing imaginable. And I wouldn't like
to flash things and make some funky panes just to
get the X/Y size of a scroll bar. This stuff is
simply obscene.

JScrollBar.getPreferredSize() and getMinimumSize()
return appropriate values.

I totally agree. Use gridbag ONLY if you have some
pretty sophisticated and pretty complex GUI.
Othewise, it is a ROYAL pain on the neck.

I use the standard layouts for pretty much everything,
but you have to know when they don't apply.

You see, the way I did it in the on-the-fly XY layout
is to create a few variables telling the relative
offsets of various columns and X/Y sizes of text
fields, checkboxes, etc. Then, as things would get
layed out on the fly, I would use the Y size of text

You generally want the borders, insets, and other
spacings specified by the Look-and-Feel, so this is
a bad idea. Why not do the same thing, but use
preferred sizes of the components?

In general it sounds like you have never used layout
managers before, and you just don't have a good feel
for them yet. Designing good layouts is not always
simple but it is important. Everybody hates fixed-size
dialogs like you see in many native Windows apps,
where you can't stretch the darn thing out to see the
rest of the filename or more of the text.

 

[nukleus]

It's an opinion based on experience.


There's a snippet above.


Most desktop applications have a lot of gui repetition
and many similar gui elements, but yours may be
different.


Normally you don't need any ratios. Give elements
in rows or columns that need all the extra space a
high weight and those in rows or columns that
should have a fixed size a low weight.


Behavior between minimum and preferred size is
flawed in my opinion. This was changed to something
much better in one of the Beta releases or pre-releases,
then changed back because it broke existing applications.
Why they didn't just add a flag to support the new
behavior, I don't know; maybe they thought it would be
too much of a maintenance hassle.


Only the ratios of total weights between different rows
and between different columns matter. If you multiply
all the weights in the layout by 1000000, there will be
no change. I (mostly) use a high weight and a low weight
instead of a high weight and zero weight, so that things
still work in layouts where there are no high weight
rows or columns. If all the rows or columns have zero
weight, none of the extra space will be given to any
component, and they will clump together in the middle
as described in the documentation.

Interesting. I'll try that and see what happens.

You can probably run it with a bigger max heap size.

I was trying to see where could I set that,
but, after spending at least half an hour,
just gave up.

Why lay out menus and title bars? Frame and Dialog
do that for you.

I did not try to lay out menus and title bars.
All I needed is the top inset so I knew where to start
positioning the first row.
If you start positioning it at 0 pix,
then your first row will be obscured by the menu and
a title bar.

JScrollBar.getPreferredSize() and getMinimumSize()
return appropriate values.

Sorry, AWT ONLY in my case.
Microsoft does not support anything beyond it.

I use the standard layouts for pretty much everything,
but you have to know when they don't apply.

Unfortunately, most of them do not support margins.
So, if you lay out things with grid layout, all your
elements will glue together with no margins.
Border layout is pretty much useless.
Flow layout has some validity to it, but it is also
way too limited, and I am not interested in anything
beyond the most basic, standard stuff supported by
AWT. Someone proposed some proprietary layout, but
when I downloaded and looked at the source, it was
immediately clear that it won't even build with MS.

Basically, I am pleased with the results of gridbag
overall, with all the associated pain on the neck.
I just finished my main frame, which is about the
most complex and intricate frame I have, and it all
worked out just fine at the end. So, I am happy with
it.

You generally want the borders, insets, and other
spacings specified by the Look-and-Feel, so this is
a bad idea. Why not do the same thing, but use
preferred sizes of the components?

Sorry to tell you, but I did not trust the very
concept of preferred size or minimal size after
I was trying to get bounds of some of the components
and was getting structures filled with 0.
I did have the equivalent of margins, and I do know
my element sizes. So, trying to get into this
preferred stuff seems to be like getting into another
pile of mess. Quite a lot of things are either messy,
or have inconsistent behavior, or utterly out to lunch.
At least this is the perception I have at the moment.
I can't trust just about anything beyond the simpliest
things on C level. Sure quite a lot of things work,
but even working with sockets seems like a royal pain.
Never expected anything like it in my wildest dreams.

In general it sounds like you have never used layout
managers before, and you just don't have a good feel
for them yet.

True, and to tell you the truth,
I am not even interested.
Because there are much more important things to do.
I explect to simply drag and drop the gui elements
into a graphical GUI design panel, and snap them
to some grid so they have the same exact sizes.
That is about ALL I want to know about layouts.

Designing good layouts is not always
simple but it is important. Everybody hates fixed-size
dialogs like you see in many native Windows apps,

And so do I. Because when you open a file dialog
and there are hundreds of files to chose from,
about the LAST thing I want to see is that microscopic
dialog that I can not even maximize. The stuppidest
thing imaginable.

where you can't stretch the darn thing out to see the
rest of the filename or more of the text.

EXACTLY.

When will these high priests of architects
realize that their minds are minds of 5 year old
and they are UTTERLY out of touch with the real world?

:--}