Re: Nested GridBagLayout and its pitfals

In article <V6ednYfimIGsGlHYnZ2dnUVZ_sGqnZ2d@xxxxxxxxxxx>, "Larry Barowski"
<MElarrybar-AT-eng_DOT_auburnANOTHERDOTeduEND> wrote:

"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.

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.

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.

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.

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

Exactly.

and you can get by
with always using a weight of either 1000000 or
..000001.

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.

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.

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

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.

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.

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.

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.
.