Geertjan is a DZone Zone Leader and has posted 466 posts at DZone. You can read more from them at their website. View Full User Profile

MigLayout: Inevitable Choice for Griffon Users?

09.18.2008
| 14934 views |
  • submit to reddit

It seems to me that in the same way that Griffon will make Groovy an ever more viable option for Swing developers, so it will make MigLayout increasingly inevitable. This will not be news to anyone who is familiar with Groovy or with MigLayout. However, let's put words aside and look purely at code, for any hold outs out there, as well as for newbies to MigLayout.

Firstly, read My First Griffon App, written yesterday by Josh Reed (also to see how Griffon handles Arctic conditions), where he states:

"I spent the majority of my time on the UI. It was a seemingly endless cycle of tweaking the code and testing with griffon run-app to get it to look the way I wanted. This is no knock on Griffon; writing Java UIs, especially by hand, just plain sucks. After far too long trying to get the standard Java layout managers to do what I want, I did myself a favor and downloaded MigLayout."

That was exactly my experience in Porting to Griffon. The one single pain point that Groovy leaves one with is the design of UIs. Perhaps a GUI Builder as NetBeans IDE has for Swing could help, but that shouldn't be necessary, and I don't believe it is in fact necessary. Firstly, I'd like to point to Metawidget, an automatic UI generator, as explained in detail some time ago here on Javalobby by Richard Kennard, its creator, himself. Secondly, there's MigLayout. As pointed out above (look at the code in Josh Reed's blog entry) and below, we have Gregg Bolinger's MigLayout rewrite (line 9 to 24 below) of my horribly convoluted GridBagLayout from Porting to Griffon:

application(title:'Anagrams', minimumSize:[297, 200], location:[50,50],
    pack:true, locationByPlatform:true) {
    menuBar( id: 'menuBar') {
        menu(text: 'File', mnemonic: 'F') {
            menuItem(aboutAction)
            menuItem(exitAction)
        }
    }
    panel(border:emptyBorder(12), layout:new MigLayout('fill')) {
        label(text: 'Scrambled Word:')
        textField(id: 'scrambledWord', text: bind {model.scrambledWord},
            columns: 20, editable: false,
            constraints: "wrap")
        label(text: 'Your Guess:')
        textField(id: 'guessedWord',
            columns: 20,
            constraints: "wrap")
        label(id:'feedbackLabel', text: bind {model.feedback}, constraints: "wrap")
        panel(name:'buttonPanel', layout:new FlowLayout(FlowLayout.RIGHT),
constraints: "growx, span") {
          button(action: guessWordAction)
          button(action: nextWordAction)
        }
        bean( model, guessedWord: bind {guessedWord.text} )
    }
}

Just for contrast, look at the original GridBagLayout which, aside from its complexity, is about twice as long:

application(title:'Anagrams', minimumSize:[297, 200], location:[50,50],
pack:true, locationByPlatform:true) {
menuBar( id: 'menuBar') {
menu(text: 'File', mnemonic: 'F') {
menuItem(aboutAction)
menuItem(exitAction)
}
}
panel(border:emptyBorder(12)) {
gridBagLayout()
label(text: 'Scrambled Word:',
constraints: gridBagConstraints(
gridwidth: 1, gridheight: 1,
fill: HORIZONTAL, anchor: WEST,
weightx: 0.0, weighty: 0.0,
insets: [0,0,12,6]))
textField(id: 'scrambledWord', text: bind {model.scrambledWord},
columns: 20, editable: false,
constraints: gridBagConstraints(
gridwidth: REMAINDER, gridheight: 1,
fill: HORIZONTAL, anchor: CENTER,
weightx: 1.0, weighty: 0.0,
insets: [0,0,12,0]))
label(text: 'Your Guess:',
constraints: gridBagConstraints(
gridwidth: 1, gridheight: 1,
fill: HORIZONTAL, anchor: WEST,
weightx: 0.0, weighty: 0.0,
insets: [0,0,20,6]))
textField(id: 'guessedWord',
columns: 20,
constraints: gridBagConstraints(
gridwidth: REMAINDER, gridheight: 1,
fill: HORIZONTAL, anchor: CENTER,
weightx: 1.0, weighty: 0.0,
insets: [0,0,20,0]))
label(id:'feedbackLabel', text: bind {model.feedback},
constraints: gridBagConstraints(
gridx: 1, gridy: RELATIVE,
gridwidth: REMAINDER, gridheight: 1,
fill: HORIZONTAL, anchor: CENTER,
weightx: 1.0, weighty: 0.0,
insets: [0,0,20,0]))
button(action: guessWordAction, constraints: gridBagConstraints(
gridx: 1, gridy: RELATIVE,
gridwidth: 1, gridheight: REMAINDER,
fill: NONE, anchor: SOUTHEAST,
weightx: 1.0, weighty: 1.0,
insets: [0,0,0,6]))
button(action: nextWordAction, constraints: gridBagConstraints(
gridwidth: REMAINDER, gridheight: REMAINDER,
fill: NONE, anchor: SOUTHEAST,
weightx: 0.0, weighty: 1.0,
insets: [0,0,0,0]))
bean( model, guessedWord: bind {guessedWord.text} )
}
}

Not only was the above next to impossible to write, but just imagine needing to maintain all of that. And the result is the same as Gregg's rewrite to MigLayout. I believe that the Grails-like structure Griffon offers to Groovy users will make it increasingly attractive, which in turn will make MigLayout an inevitable first choice when it comes to designing the view of Griffon applications. And therefore, in short, if you're a convert to MiGLayout too, please show your appreciation, and your need, by voting to add MiGLayout to the JDK!

Published at DZone with permission of its author, Geertjan Wielenga.

Comments

Jacek Furmankiewicz replied on Thu, 2008/09/18 - 7:35am

It's a disgrace that Sun has not made MigLayout a part of the JDK yet. It could be the single best new thing in Java 7 (if the will to accept it was there).

MigLayout vs other JDK layout managers is like coding with garbage collection vs. managing memory by hand. It's not an incremental improvement, it's a radical massive step forward.

Everytime I demo MigLayout to any developer familiar with GridBagLayout their jaw drops to the ground.

When I did my Java SwingBuilder library, I realized I could achieve pretty much all the layouts in the world with nothing else but MigLayout, CardLayout (and rarely FlowLayout). And those should be the only layout managers active in the JDK, all the other ones should be flagged as @Deprecated.

Mikael Grev has contributed the single biggest enhancement to Swing since the time it was invented and even he can't get any respect.

Bug ID: 6530906
Votes 232
Synopsis Add MiG Layout to the JDK
Category java:classes_swing
Reported Against
Release Fixed
State --> 3-Accepted, request for enhancement
Priority: 5-Very Low

 232 votes and priority Very Low? NIH (Not Invented Here) Syndrome is in full effect, I guess.

 

 

John Denver replied on Thu, 2008/09/18 - 11:08am

Tell me where I sign to send to the expert group so they depricate all the layouts and keep just Mig layout.

Java, Swing, Mig layout, Groovy, SwingBuilder, Griffon looks very interesting and now with the JRE6_10 it will rock more. I really hope the expert group incorpore Mig layout as a stadard for Swing in Java 7 or we have to bring the drums and begin to scream for it.

Me I think that for business or enterprise GUI development Java/Swing or Groovy/Griffon is the way to go.

JavaFX it is cool but it looks it is heading more to the Rich Media or Mobile.

Note: I think we will need a book for Groovy/Griffon soon. By the way Geertjan all this articles are awesome.

 

 

Andrew McVeigh replied on Thu, 2008/09/18 - 11:38am in response to: John Denver

By the way Geertjan all this articles are awesome.

I second that wholeheartedly. Thanks for your work on all the GUI articles, Geertjan. I only regret I don't have more time to read and comment on them as they come out. You should assemble them into a book.

Andrew

Jacek Furmankiewicz replied on Thu, 2008/09/18 - 12:03pm in response to: John Denver

[quote=alpha512]Tell me where I sign to send to the expert group so they depricate all the layouts and keep just Mig layout.

Java, Swing, Mig layout, Groovy, SwingBuilder, Griffon looks very interesting and now with the JRE6_10 it will rock more. I really hope the expert group incorpore Mig layout as a stadard for Swing in Java 7 or we have to bring the drums and begin to scream for it.[/quote]

I wish it was that easy. I mean, the bug is in the Top 25 RFEs, the code is done, production ready and released under the BSD license, so Sun can just take it, refactor the package names and off you go.

I  think the problem is there is no real "Swing expert group" that I've ever heard of...the two folks that were most vocal representation of Sun's Swing team now work for Adobe. :-(

James Williams replied on Thu, 2008/09/18 - 1:02pm

Out of the LayoutManagers, GroupLayout is the worst and it is part and parcel of Matisse. Whilst creating SwingXBuilder and converting a lot of examples, I had to read GroupLayout GUIs and distill it down to the essentials. MigLayout quickly became my friend.

As touched on in the comments of this blog post, part of the supposed need depends on your motivations. Some are willing to rob Peter to pay Paul and deal with the extreme hardache of having to tweak it by hand if need be. Some are not. I wonder how many of these ugly UIs would disappear if people had to sit down and sketch it out on paper or Photoshop/GIMP/whatever first.

Jacek Furmankiewicz replied on Thu, 2008/09/18 - 1:17pm in response to: James Williams

Funny...the thing that pushed me to MigLayout was the exact same problem: trying to break down GroupLayout into something usable for my Java SwingBuilder. I gave up very quickly and started looking for alternatives.

Once you discover MigLayout, you're never going back.

 

 

Geertjan Wielenga replied on Thu, 2008/09/18 - 5:34pm

Thanks all for the support for the perspective address in this article. Maybe a way forward is to create a JSR for a standardized layout manager? Sun takes JSRs very seriously. On the other hand, why not look for avenues into the OpenJDK? How open is it if the most popular layout manager (maybe not now, but only not now, if not now, because not enough actual developers know about it) is not part of the "Open"JDK? Just two thoughts, take them as you want them. One can play victim to your feelings about company XYZ, or you could take the bull by the horns yourself. Either see Sun as the guardian of Java, and feel yourself to be submissive to it (e.g., "why does Sun not blablabla" fits into this line of thinking), or consider yourself equal partners and push your own line, via the OpenJDK, or some other route.

Secondly, thanks Sidewinder and Andrew McVeigh for supporting my articles on JL. Re your comments about a book, Andrew, I think a very practical book like Jason Rudolph's one for Grails should be written for Griffon (once all the dust settles, of course).

Mikael Grev replied on Fri, 2008/09/19 - 2:27am

Thanks you all for your kind words and your support!

A JSR might be a way to go actually. It is kind of similar to JSR 310 (Date & Time) in that it is new good functionality replacing something bad that is already there. If Sun would just send me one note that that would be a good idea I would be happy to be the spec lead. And the job is mostly done.

Thanks again all!

Regarding votes. 387 votes and MiG Layout would be #4... ;)

Mikael

Ricky Clarkson replied on Fri, 2008/09/19 - 4:48am

For what it's worth, I respect Mikael, and don't think MigLayout should be in the JRE.

Edit: I respect him enough to spell his name right.

Jacek Furmankiewicz replied on Fri, 2008/09/19 - 5:10am in response to: Ricky Clarkson

So you would prefer that generations of Swing programmers grapple with GridBag and GroupLayouts, until the lucky day that some kind soul shows them MigLayout? :-)

I think MigLayout *should* be in the JDK...this way Sun could add a killer desktop enhancement that would leapfrog anything that is in Flex or .Net right now. Would surely help JavaFX as well.

Jacek Furmankiewicz replied on Fri, 2008/09/19 - 5:19am in response to: Mikael Grev

Well, Geertjan is probably right...we can all complain about nothing being done, but maybe it's time to do it ourselves.

If you start up a JSR on this (I presume this is the way):
http://jcp.org/en/procedures/jcp2

then I will be happy to support you in whatever way possible to make MigLayout a part of the JDK.

 

Mikael Grev replied on Fri, 2008/09/19 - 5:47am

Hey Guys, it has been upgraded to "Priority: 3-Medium". :)

Not sure what this means in practice but I can see no disadvanages at least.

I am considering filing for a JSR. I don't like duplicate work though so any hints from any "official" people would be apprecited.

Again, thank you all for your support.

Jacek Furmankiewicz replied on Fri, 2008/09/19 - 5:53am in response to: Mikael Grev

So, it looks like a single JL thread accomplished in 1 day more than 240 votes over a year? *grin*

We just need 2 more threads like this on other websites to move it to "High". I guess this ties in nicely to your recent blog entry on "what's the point of voting in the bug parade?"...

Either way, this is great news and gives us hope. Adding MigLayout (I think "DynamicLayout" would be a nice name for it if it were to be included as part of the JDK) will be a major shot of steroids for Swing.

 

Jean-Francois P... replied on Thu, 2008/09/25 - 11:40am

One original idea of LayoutManagers and Containers was to be able to mix several together to obtain complex layouts, although keeping LayoutManagers themselves simple.

If we omit GridBagLayout and GroupLayout, all JDK-provided managers are -indeed- simple (although too limited).

I am working on Swing GUI quite often and, to be honest, I think MigLayout is too complex to use (learning curve), error-prone (no possibility to check layout mistakes at compile-time), probably due to its endeavour to be a "one-fits-all" layout manager.

Two years ago, while I was looking for the "best" LayoutManager for my needs, I found John O'Conner "LayoutManager Showdown" competition and could appreciate the pros and cons of each competitor (including MigLayout). The most important points for me were:

  • no need for a graphical designer
  • simple API
  • visualization of the real layout just by browsing the source code
  • ease of maintenance (in particular, moving rows or components, or inserting rows or components; LOC count was also meaningful)

And at that time with these criteria, the winner was... DesignGridLayout (who had heard of it before?)

Since then, I have used it in all my Swing projects (and I have joined the DesignGridLayout project itself because I found it lacked involvement last year and that really was a pity).

What I want to say here is not "everybody should use DesignGridLayout" (although I would like this to be true;-)), but rather show that, due to the lack of good LayoutManager in the JDK, lots of great LayoutManagers have been invented (generally OSS) each with their pros and cons, some with revolutionary ideas. Now if MigLayout was included in the JDK, I thing this would hinder any further innovation in the domain of layouts (and I believe there are still opportunities for improvement in this area).That's why I'd rather not see MigLayout included in the JDK.

Jacek Furmankiewicz replied on Thu, 2008/09/25 - 12:46pm

I had a quick look at DesignLayout and it's pretty interesting, but it seems much more verbose than MigLayout (with its dynamic layout constraints). And it sort of goes against the typical Swing API by adding components to the layout manager, instead of to the parent panel. But that's a minor issue.

I think JDK should have a kick-ass layout manager out of the box (which it is lacking right now) and if anyone is dissatisfied with it, they are free to keep developing open source alternatives.

 

Mikael Grev replied on Thu, 2008/09/25 - 4:37pm in response to: Jean-Francois Poilpret

DesignGridLayout is not only a LayoutManager, it is a GUI build tool. This means it can cut corners. This is sometimes ok.

It seems only creators of other layout managers say MiGLayout is "Too complex". It is not a common complaint among its users.

Furthermore, it cuts even more corners by not following the showdown rules by saying it creates a better GUI... Maybe it was intentional to both have left and right aligned components as well as non-column aligned ones to see if the layout manager could handle it?

Another problem with your showdown layout is that the spacing is wrong. There are equal spacing between the label and its related textfield as it is to the next textfiled that is unrelated. This is not style guide compliant.

If you want to cut such corners that is ok, but please don't make claims that it is simpler just because it does it in a simpler way.

Also, you can use MiGLayout in API mode, which means no strings and only compiler checked stuff. You have a choice. And 90% of the developers choose the string constraints... (judging from the forum feedback).

Cheers,
Mikael

Jean-Francois P... replied on Thu, 2008/09/25 - 7:40pm

Mikael,

 

my intent was not to flame MigLayout in any way, but just to say that there is room for more than just one LayoutManager in the Swing ecosystem. Moreover, Swing API is already complex enough not to add a new Layout to it (I think adding GroupLayout to Java6 was bad).

You are right that DesignGridLayout "cut corners" and does not allow you to do every layout you would want (but hey, you have MigLayout for that;-)) This somehow matchesyour statement "This is sometimes OK" (except that 'd rather say "This is OK, most of the time; for other situations, use another Layout").

However, DesignGridLayout provides best practices and good-looking layouts for free (I mean with no hassle on the developer). After leading severalSwing projects involving only developers (no "designers" for the UI), I can judge that many developers totally lack sense of what a good GUI should look like, henceI believe that any LayoutManager encouraging -and even enforcing- good practices is good for them.

I don't understand your claim on spacing between labels and text fields: DesignGridLayout uses LAF-provided spacing exclusively, so if spacing is wrong, this means that LAF gave wrong spacing. If there is indeed spacing problems, please let me know (maybe not in this thread though).

For MigLayout API mode, I was not aware of it, I'll take a look, should be interesting (as you understood, I am reluctant to runtime-errors caused by codes in Strings, that's why I like Guice, but that's another story).

Cheers, Jean-Francois

Andrew McVeigh replied on Fri, 2008/09/26 - 5:34am in response to: Mikael Grev

Also, you can use MiGLayout in API mode, which means no strings and only compiler checked stuff.

I must admit, I like the code examples for DesignGridLayout from the shootout -- even though it doesn't do everything, i like the OO-ness of it. I've heard the points about "you shouldn't add components to a layout mgr", but it doesn't seem wrong to me. I also don't have a problem with the spacing in the example, it looks nice to me. of course, it's not duplicating exactly the spec of the shootout, but ce'st la vie.

So, i'm glad we have some really, really good layout mgrs. MigLayout, DesignGridLayout, TableLayout. Bring them on!

As an aside, do you have some online code examples of using the Mig API for layout? I'd be interested in this.

Andrew

Mikael Grev replied on Fri, 2008/09/26 - 8:44am

Moreover, Swing API is already complex enough not to add a new Layout to it (I think adding GroupLayout to Java6 was bad).

I would say it is so complex because there are so many bad LayoutManagers (part of the problem though) and fixing that problem would not escalate it.

It is not IMO a ood idea to have to revert to another layout manager as soon as things gets tough since that usually menas you have to rewrite the GUI rather than to refine it. It is therefore important that your tool is simple to use but can handle the last pixel adjustments as well. Take for instance resolution independance, it isn't something that you just can slap on at the last stage if the layout manger doesn't support it.

I don't understand your claim on spacing between labels and text fields: DesignGridLayout uses LAF-provided spacing exclusively, so if spacing is wrong, this means that LAF gave wrong spacing.

I just looked at the screenshot for the showdown and the spacing was wrong. Particularily there was no difference between an unrelated and a related gap. An unrelated gap is typicall 50% larger. Btw, where do you get the LAF gaps? Do you use the Java 6+ GroupLayout plaf defaults?

 Cheers,
Mikael

Andrew McVeigh replied on Fri, 2008/09/26 - 8:59am in response to: Mikael Grev

 Btw, where do you get the LAF gaps? Do you use the Java 6+ GroupLayout plaf defaults? 

Looks like it relies on a library: https://swing-layout.dev.java.net/

Looking at the classes inside (support for aqua, gnome, windows, metal), it made me wonder if there are other platforms that are not supported?  What about 3rd party LnFs?

Andrew 

Jean-Francois P... replied on Fri, 2008/09/26 - 10:17am

That's correct, DesignGridLayout uses swing-layout project (which has been then integrated to java 6).

This library is used for 2 purposes:

  • component baseline calculation (for baseline-alignment of components in a row)
  • inter components gaps calculation (for both horizontal and vertical spacing of components)

I am not much knowledgeable of the internals of this library, but I could see that it worked well with the following LAFs (I didn't test any other LAF): WinXP, Metal, Substance. For Substance, Kirill the project owner, had included special support on my request about one year ago (note that there is no need to change swing-layout.jar to include support for other LAFs).

If you use a LAF that is not natively supported by swing-layout and that also does not bring support for it, then the library falls back to "sensitive" defaults (but no crash).

DesignGridLayout has no dependency on Java 6. Thus, so far I did not check what, from swing-layout, was included in Java 6 (if not all); I'll take a look at it sometime. For the time being, I don't want DesignGridLayout to depend on Java 6, it is still too early I believe (many users are still depending on Java 5 deployment of desktop apps).

Note that swing-layout was the first GroupLayout implementation, not that I like this Layout, but one good point is that it has brought this new baseline thingy and had it included in Java 6.

Jean-Francois

Carla Brian replied on Sat, 2012/06/02 - 11:35am

This is the first time i heard about MigLayout. It is kinda interesting. I will try this application. - Markus Lattner

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.