A recent article on JavaLobby discussed the MiG layout manager, which is a cross-widget layout manager that can be used by both SWT and AWT-based systems. It's interesting that someone is trying to come up with a better layout manager (other than the defaults, or bastardizing
GridLayout), and doubly so that it is being aimed squarely at both the two major UI widget sets that are currently in use.
If you're the kind of person who throws together
GridLayout (along with all of their corresponding foibles and support costs) then the MiG layout might be a good choice for you to look at. It has a number of flexible constraints that can be added to widgets, and those constraints can be specified to override what the widgets in question believe should be used for preferred size, spacing etc.
Unfortunately, for almost everyone else, this is probably something else that has been thrown together due to poor experience with UI (or layouts in general, in fact) and a frustration with the current
GridLayout manager. From the article:
Nested layouts (a.k.a. panels in panels) is an abomination if you want to create exact and clean layouts with predictable results. The built in layout managers in Swing forces you by design to use nested panels. The problem is that since the different layout managers behaves differently regarding the interpretation and adherence to minimum, preferred and maximum sizes they get hard to handle when nested, and you must figure out for instance why the minimum size is disregarded, and at which panel level...
The flexibility of MigLayout should get rid of almost any panel-in-panel urges. In fact, when I was doing the mandatory research for how general layouts looked like (using Windows XP's and Mac OS X's standard dialogs as examples) the goal was to create a layout manager that was so flexible that every dialog could be done with one layout for every tab.
This quote really summarises everything you need to know about this layout manager. Either you know how to design UIs properly, or you don't, and whether you interpret the above quote as correct or not will be correlated completely with whether you should use this layout manager or not. In short, what
MigLayout tries to do is be The One True Layout Manager, and espouses the concept of nested layout managers to do the work for him.
Amusingly enough, he cites Windows XP's dialog as an example of something using a single layout manager. Seriously. He's quoting that, and he's assuming its a
He also quotes Mac OS X's dialogs (again, not often resizable, though there are many more windows e.g. in the System Preferences.app that are resizable and do layout). But -- and this is the laughable part -- he's saying that this is an example of good design because it's one layout that's used.
Unfortunately, for Mac OS X's case, that just isn't true. Widgets such as the Tabbed view are actually themselves nested
NSViews, and each tab has their own layout manager. Furthermore, just like Java, it's possible to have nested
NSViews with their own sizing and placement. Groups (with the lines around and the titles on the top), column views (like the Finder), or plain old nested
Not only that, but any decent typographical system (and by 'decent', I mean 'not Microsoft Word') such as LaTeX or even good old HTML with CSS typically deal with the ability to have nested areas in order to provide more detailed formatting. Long gone are the days when web developers advocated having a single large table with multiple items spanning arbitrary numbers of rows and columns. In fact, even since Java 1.0, Java developers have followed good practice and split up UIs appropriately. Not only does it make sense programmatically (it's easier to maintain if your UI code is itself encapsulated; after all, no-one claims that methods are bad and that all code should be stored in one giant method/class) -- but it also makes sense from a maintainability perspective. Want to add a new field? Just add it in the view that contains your list of fields. Need to add a button into the toolbar? Just add a button into the group panel. Why it even starts to make sense having to update all your references with
col+1 just because you've added a new item/list/button/checkbox really doesn't make sense in this day and age.
The conclusion of this is that nested layouts
GridLayout manager is horribly overused in Swing, and as this builds on top of the principles (granted, doing a better job in some ways) it is essentially doomed to follow the same path. It's also unclear why a separate mini-constraint language was developed to represent constraints, when it could easily have been extracted into some kind of type-safe class; after all, it would be trivial if such a string format were necessary to provide a parser that converted the string into a type-safe class, whilst still allowing those cases listed in the main article.
Unfortunately, this layout manager promises to solve all your problems, but in reality, will probably cause more. The only type of developer who should investigate this is those wedded to the use of