The most powerful Java LayoutManager. It has a steep learning curve, but unlike some of the other LayoutManagers shipped with Java, this one allows to build no-nonsense GUI layouts.
Components (widgets) are placed in grid cells, and each grid cell / component pair is controlled by a constraints object. The GridConstraints object specifies such things as relative alignment within the cell, resizing behavior, insets within the cell, etc. It is also possible to stretch one component over multiple rows or columns in the grid.
I usually wind up using this for most non-trivial GUIs. The learning curve is steep, and I find it's easy to get out of practice. A lot of tweaking is usually necessary (for me, at least), but a good GBL results in a GUI that handles resizing and different platforms pretty well. --JohnWebber
It's a nice design but far from perfect. The most annoying feature is that if the user enlarge the window and brings it back to its original position, the layout of the components inside will generally change. Frustrated but this feature I designed a new layout long time ago.
The basic idea is great, an unequal grid of rows and columns. The width of a column/ height of a row can be specified either as a number of pixel or as a proportion (percentage of the remaining available space). The rest is pretty much the same as in the GridBagLayout, but I get to specify fixed sizes for things like header and footers, left columns, etc. And the distribution of space is deterministic. If anybody is interested I'm considering publishing it here as open-source -- sourceforge is too much trouble. --CostinCozianu
I for one would be interested in seeing it. -- DougMerritt
On first quick read it looks very clean. Are your comments above still pretty accurate about the difference between it and GridBagLayout?
I haven't checked GridBagLayout lately, but certainly in 2001 my definitive impression was that it was non-deterministic in dividing the space. It may as well be that I didn't know how to use it properly, but the complexity of constraints specification turned me off, I thought it was largely unnecessary, and onj the other hand not very powerful as I really needed fixed size rows and columns. I tried to eliminate things that I thought were not needed. The code below is without much unit tests, but it worked pretty well, for my limited needs, it may have bugs in areas that I haven't tested, so improvements were welcome.
Unimportant digression: what is your philosophy about getters and setters? -- DougMerritt
There's no "philosophy", it's EmulateKeywordAndDefaultParameters and supporting LongParameterList, hopefully the client code will look nicer than the code of this class. Writing this kind of code is an exercise in frustration over Java language design. EmulateKeywordAndDefaultParameters is a workable workaround, but other workarounds are damn ugly. For,example discriminated types: the constraint for column/row size should be:
type size_constraint= FixedSize? of int | Quota of float;But instead I use an array of booleans, and array of ints and an array of floats.Arghhhhh! Also the enumerated types. Another very ugly thing: there are largely repetitive code blocks being written through copy & paste for rows then for columns, it's just the name of the variables and the name of the method calls that get changed. Putting the right abstractions in place to refactor the algorithm to be the same would be trivial in ML, but in Java I strongly believe it will bloat the code and look ugly. So I left it ugly like this for practicality.
Ah! That explains some things I was wondering about but hadn't formulated a clear question about yet. Comments like this, that expose some of the hours of thinking and design tradeoffs and fighting with the language, are worth their weight in gold. I would copy it into the code.
Oh, and I love this page: EmulateKeywordAndDefaultParameters. I hadn't read it before.
-- DougMerritt
An alternative take on GridBagLayout is in GridLayoutEx.