Re: GridBagLayout - A simple test program

On 2008-02-10 18:45 +0100, Knute Johnson allegedly wrote:


You think so? How about: putting a border around the container, adding a
MouseMotionListener, changing the cursor to RESIZE when it hovers the
eastern or southern border, or the south-eastern edge, and reacting to
mouse drags by resizing the container every few pixels, or indeed every
pixel?

Yeah, I kind of suspected the code didn't correspond to what I was
seeing, being a JFrame rather than a JApplet -- but I wasn't too sure
whether there may be was some neat trick you were using that I was
unaware of.
I think it is misleading to proclaim a link as being to the "Source
Code" when it actually isn't.

That being said, I'm not too sure whether the possibility for the user
to be able to compile and run the code himself deserves as much emphasis
as you put on it. I don't see it as much of a constraint to have to play
with an applet rather than with a self-compiled program. I suppose you
would like to see your utility as a tool which any GUI developer could
toy with whilst in the process of designing his new layout -- but unless
your app sports some more complex features (see below), that expectation
is unrealistic IMHO.

The sole fact of the matter is I didn't realise it was a menu (on WinXP,
Firefox 2.something). Can't tell you exactly why. It may have been due
to the lack of the window's title bar commonly concomitant to a menu bar.
Bearing in mind that this is strictly tied to my own personal flavour of
disability, I would suspect the slight visual hint of an underlined
character (as accelerator keys are commonly visualised) would have led
me on the right track. I don't think the menu title is misleading or
inappropriate in itself.

I am not entirely satisfied with the approach of 1/2/4/... JButtons,
though. I think it ought to include other widgets in order to enhance
its use-cases and broaden its scope beyond providing the most basic
understanding of the GridBagLayout.
I would suggest the following scenario, instead of the static menu item:
- add a right-click (or its equivalent on Mac) support with a
popup-menu. If the right click occurs on an existing component, the
popup will list a menu item for removing that component. In any case, it
will list a menu item for adding a new component, and one for emptying
the container.
- Alternatively or additionally to having it in the pop-up menu, a
static button (or a menu item) links to the "add component" feature.
- When the add component feature is requested, open a dialog where the
user selects a widget type (button, label, text field, combo box,
spinner, text area, you name it) and a text area to input the widget's
content (would be superfluous for some, like combo boxes or spinners).
- The editing of the GridBagConstraints shouldn't be done in a dialog.
Nice though Dialogs may be, they tend to suck rather rapidly. You've got
plenty screen estate. Add a area, say on the right-hand side (or
left-hand side in case of concurring component orientation ;-) ) where
the constraints for the currently selected component are displayed and
modifiable (updated either on focusLost or via a dedicated button).
Incidentally, components should be "selectable". As for the visual
feedback for the selected state, think of something. Maybe a thin
coloured border would be appropriate.
To ensure selectability, you would have to set a non-zero lower bound
for minimum size, say 10x10.

In his post on this topic, Mark Space notes the trouble he had with
components overlapping each other and suggested the use of a second
panel to display the results of the layout.
I don't think that is necessary. Besides, that way the first panel
essentially becomes visual garbage.
I think it would be a more appropriate approach to detect and prohibit
such overlapping by preventing two components from having the same
combination of non-negative integer values for their gridx and gridy
fields (and as extended by positive integer gridwidth and gridheight).
The only problem this would pose would be, quite evidently, the
inability to do so purposefully. Maybe there would be an elegant
solution to that, too. I am not sure the problem is worth considering,
though. Components normally shouldn't overlap, at least not normally in
such cases where a GridBagLayout is appropriate.

Yeah, I still seem to recall my first gridbag layout -- a figure
compared to which Frankenstein would stand as a brilliant display of the
most refined aesthetics, and a likely fabric of nightmares if I had any
:-).

But, as I have already noted in the thread which I suppose sparked off
your current effort, the most important thing I have come to realise
during my process of learning how to write GUIs, was that however
powerful the layout manager for a single container may be, it was still
more important to properly and extensively nest containers, to create
dedicated containers with specific layout behaviour of their own and
thus work your way from bottom to top. Of course, discussion on this
matter isn't solely dependant on technical considerations, that is
what's feasible with the API, but also and foremostly on conventions as
to good (or bad, incidentally) interface design -- the interface hall of
shame*, albeit a tad old, is a must-read for GUI developers.

*<http://homepage.mac.com/bradster/iarchitect/shame.htm> et al.

df.