John O'Conner's Blog

Layout Manager Showdown

My recent blog about NetBeans GUI Builder (Matisse) and GroupLayout have encouraged a vigorous debate. Except for a fertile forum for comments, I've contributed practically nothing to the conversation and I feel somewhat intimidated by the brain power and energy that go into the discussions. However, having been encouraged by the participants, I'm announcing a Layout Manager Showdown!.

Several UI power thinkers have agreed to present their arguments for their favorite layout manager. Each researcher will provide his/her analysis of a manager and his best solution for creating forms and panels. They will present their findings so that others can compare and contrast the various layout managers available to the Java community.

At this point I have the following layout managers and researchers on the showdown roster:

Are you interested in one of these layout managers? If so, speak up, and I'll add you to my list of suckers, er...researchers. I'm just joking about the "suckers" part, but I'm glad it's you writing up the analysis and not me. I don't have enough willpower to learn a half dozen new layout managers on my own, but I'll be happy to learn from you! And I'll probably use your layout manager if it's really good.

There are still a few things to determine before we can do this in an orderly way.

1. Where will we put this information?
   
2. What forms or panels should we implement?
   
3. What are the evaluation criteria?
   

I'll take a poke at answering these:

1. I would like to suggest the wiki right here at java.net. In fact, there is already a 3rdParty Layout Manager comparison page on the Java Desktop Home wiki page.
   
2. You could get started with the frame shown below...
   
3. I'd like to know about some of these items:
   
   
   
   • Can it align components across other components? For example, can it both left and right align the 'phone' text field with the 'city' text field on the other side of the two address fields?
     
   • Does your manager know about platform specific gaps and spacing among components. Just curious.
     
   • Can the text fields, labels, etc grow and shrink when the text is localized?
     
   • Just how much code do I have to write? Java code? Declarative XML?
     
   • Can I nest panels?
     
   • Can it align components along a baseline. For example, the new GroupLayout can align labels and text fields along the text baseline...that's nice.
     
   • What's the licensing?
     
   • Will this work for bi-directional locales? How difficult would it be to mirror the layout for a right-to-left locale?
     
   • What else should we evaluate?
     
   
   

Hey, I don't want to hold anything up, so why don't you get started with the address book frame here. You don't have to fill in any data...just create this layout. Here are some more details about the frame below:

• The 'Last Name', 'Phone', etc, 'Country' labels are right aligned...in a column, maybe, but that's up to you.
• The text fields for last name, phone, etc through country are left aligned.
• All text fields and the list at the left should expand horizontally and get equal amounts of the additional space.
• Labels and text fields are aligned along the text baselines.
• The list should also expand vertically.
• Keep the row of buttons immediately under the address information even if the the list expands vertically when you resize.

Go ahead. Use your favorite layout manager to create this frame, and let us know when we should go take a look at your solution and comments.

Comments

• Well... personally, I would do it using a combination of 3 layout managers:
  One BorderLayout for the list (LEFT) and the right part of the screen (CENTER)
  Another BorderLayout for the right part of the screen, including a button bar, which I would create using JGoodies ButtonBarBuilder (SOUTH) and the form itself, created using JGoodies FormLayout (CENTER)
  Which brings me to my point: there is no such thing as a perfect layout manager. Most of the times, a combination of simple ones and more complicated will give the best results in terms of developer productivity. Use whatever layout manager you like, as long as you're happy with it.
  By the way, I think the First name, Email and Postal Code fields should all be aligned together for this UI to be consistent.

  Posted by: krakerjaak on October 11, 2006 at 05:32 AM

• 
  This sounds like an ace idea John

  
  To list of evaluated features i would add quality of documentation - API, guides, tutorials, demos etc., - and when it was last updated
  

  Posted by: laurie_green on October 11, 2006 at 07:20 AM

• Remember, ladies and gentlemen, put your solutions over on the wiki with some reasonable analysis that addresses some of the questions that have been asked. We want to create a lasting document that's easy for others to use, to compare, and to pick your layout manager. If you put your code or analysis here, you will have contributed to this blog but not to a larger, visible, lasting body of easily accessible information.

  Posted by: joconner on October 11, 2006 at 09:14 AM

• John - you can remove the comments in your admin page.

  Posted by: kirillcool on October 11, 2006 at 11:44 AM

• varan, I've removed your code sample comment. However, I've taken the liberty of creating you your own PageLayout wiki page, and I've copied your code there. :)
  

  Posted by: joconner on October 11, 2006 at 12:43 PM

• What kind of deadline are you thinking of for this?

  I would be happy to implement this with good old GridBagLayout, but I'm not sure at the moment how much time my schedule would allow me.

  More specifically, I could probably write the layout in one sitting, but I don't know how long it will take me to research things like bidirectional support.

  Posted by: afishionado on October 11, 2006 at 01:31 PM

• Interesting challenge!

  
  I banged out a quick response. I uploaded it to CVS here as AddressBookDemo.java.

  
  I relied on my DesignGridLayout layout manager. It's pretty much ideal for this type of problem. It facilitates the construction of typical forms-based user interfaces using canonical grids, a design tool used by graphics artists.

  
  The "meat" of my solution, the construction of the address form, is about 30 lines of code. I banged that part out in less than 30 minutes.

  
  Putting the listbox on the left took me longer. My layout manager didn't handle that one very well. I'll have to investigate. Meanwhile, I'm relying on a BorderLayout to put the listbox in the right place and an EmptyBorder to mimic the "look and feel" spacing. Not very satisfactory.

  Posted by: josgood on October 11, 2006 at 02:53 PM

• I forgot to answer the quiz. Answers for DesignGridLayout.

  Can it align components across other components? For example, can it both left and right align the 'phone' text field with the 'city' text field on the other side of the two address fields?

  I'm not sure. I think so. DesignGridLayout relies on canonical grids. So everything lines up. But there are rules that have to be followed. There are ways to not use the grid (e.g. for the bottom row of buttons), but there's no way to break the grid.

  Does your manager know about platform specific gaps and spacing among components. Just curious.

  Yes! That was one of the big motivators. DesignGridLayout relies on Swing Layout to get the LAF specific values.

  Can the text fields, labels, etc grow and shrink when the text is localized?

  Yes.

  Just how much code do I have to write? Java code? Declarative XML?

  UI construction with DesignGridLayout is very terse. Only Java code. XML is fool's gold.

  Can I nest panels?

  I don't understand the question.

  Can it align components along a baseline. For example, the new GroupLayout can align labels and text fields along the text baseline...that's nice.

  Yes! That also was one of the motivators for DesignGridLayout.

  What's the licensing?

  Free, open source, whatever. Currently using LGPL. I think. Holler if someone needs something different.

  Will this work for bi-directional locales? How difficult would it be to mirror the layout for a right-to-left locale?

  Not currently supported. Shouldn't be too much work. Happy to do it if anyone really needs it.

  What else should we evaluate?

  I believe that ease of construction and correctness of results are the most important issues. We spend too much time figuring out how to organize our code and then tweaking (nudging) components to make everything look "just so".

  DesignGridLayout is designed for typical forms-based user interfaces. It does that one thing very well. If you need to do something else, write a new layout manager. I've started a "center based layout", as illustrated in the Mac OS X user interface guidelines as well as a property sheet layout manager. By doing one thing very well, each layout manager is simple to use and debug.

  DesignGridLayout also strives to be visually correct when used with all look and feels. I haven't checked in a while, but I think Karsten's JGoodies is the only other layout manager that attempts this. (Matisse doesn't count. First, because it's a GUI builder, not a layout manager. Second, because when I tried it last, it blew up after just a few components. Lastly, the resulting code is not human editable.)
  

  Posted by: josgood on October 11, 2006 at 03:17 PM

• Thanks for your enthusiasm! I insist, however, that everyone put your info over on the wiki, and I'll spotlight it in the next few days. While having it as a comment in my blog is great, you'll be able to add to your analysis, modify, etc only if you put it on the public wiki. If you have a java.net user name, you can contribute layout manager wiki content.

  Posted by: joconner on October 11, 2006 at 04:10 PM

• I have a builder panel called TableLayoutPanel I use for almost all but very simple layouts, and it makes me feel very productive.

  Internally it uses TableLayout but wraps the API and is very easy to use for creating static forms like this. But then I created it, so I am biased.

  You work row by row when you add Components or Strings (a JLabel gets created and added internally), spaces in the grid are added as nulls.

  it lets you add a whole row of N components or Strings mixed in with constraints at a time.

  the layout part of the example comes out at about 13 lines, not including Component creation and I did put all the buttons in a separate panel and use an EmptyBorder rather than a margin to make it look nice.

  Handles Row and Column spans, Component Alignments but not BaseLine, (don't know if TableLayout does), Row and Column sizes, FILL or PREFERRED.

  the basic format of adding is something like this (varargs so 1.5+ only)
  panel.addComponentRow(stringOrComponent [ ,Constraint [,Constraint]] [, stringOrComponent,[ ,Constraint [,Constraint]], ...]);

  Would that be of interest even though it's not a LayoutManager?

  Posted by: jorgenrapp on October 11, 2006 at 04:32 PM

• As the Pagelayout code referenced above shows, it solves the problem with a SINGLE layout manager.

  It obviates the need for nested panels.

  As to John's questions, the main answer is that it is LGPL as in FREE, and allows all sorts of layouts with the same uniform API.

  I guess I can implement the other features like baseline alignments, laterally reversed layout etc can be easily implemented but they do not yet exist.

  Posted by: varan on October 11, 2006 at 04:44 PM

• Hi John-

  
  I just tried updating the wiki. Something about a version control system error. Gave up. I'll try again in a day or two.

  Also, I updated the project DesignGridLayout project page with the AddressBookDemo example, including screenshot and webstart link.

  Cheers, Jason Osgood / Seattle WA

  zappini.blogspot.com

  Posted by: josgood on October 11, 2006 at 05:00 PM

• I will give FormLayout a shot.

  Posted by: lmfinney on October 11, 2006 at 07:13 PM

• I have commented the the Pagelayout code and reorganized it a bit without making any changes to the actual program. Although such measures are not that important, the line count of the layout code (without comments) comes out to be just thirty.

  I think the comments should enable anyone to understand what actually is being done. If anyone has any questions, please let me know. You can reach me via my Sourceforge page.

  Although the title of my tutorial on the Sourceforge page is a little bit tongue in cheek, I think that the example should convince many that the claim therein that PageLayout is the only layout manager you will ever need is not exactly extravagant.
  

  Posted by: varan on October 11, 2006 at 08:08 PM

• I added an example and answers to the questions for FormLayout.

  Posted by: lmfinney on October 11, 2006 at 08:33 PM

• Hi John, I can provide the example and answer questions for GroupLayout.

  Commenting the criteria/questions, I think the "Can I nest panels" is a bit misleading. You can always nest panels. The question should be quite the opposite: "Do I have to use nested panels to achieve certain layouts?"

  Some question about maintainability of the code, making additional changes, tool support, ... would also make sense.

  Overall I'm just curious what the result of this "showdown" should be. Because there is nothing like "the best layout manager", it depends on the purpose it was designed for (type of UI, ways of use, API level). It would be very valuable, though, if someone could do an independent summary in the end, reviewing the principles the layout managers are built on, main common characteristics and differences, the most important features, limitations, trends, etc.

  Posted by: tpavek on October 12, 2006 at 01:01 PM

• How important is it that the First Name, Email, and Postal Code fields be of different lengths? For FormLayout, following that rule pretty much requires using nested panels, but I've noticed that at least one of the other entries were set up with fields of the same size.

  If that's acceptable, then fewer subpanels are needed.

  Posted by: lmfinney on October 12, 2006 at 01:15 PM

• Hi lmfinney-

  How important is it that the First Name, Email, and Postal Code fields be of different lengths?

  Good question! Putting my bias on display, I assumed those fields were to all be the same width. If they need to be different widths, then DesignGridLayout isn't really an ideal solution.

  Cheers, Jason

  PS- The preview comment feature for weblogs.java.net truly sucks. Someone should be embarrassed.

  Posted by: josgood on October 12, 2006 at 01:50 PM

• > How important is it that the First Name, Email, and Postal Code fields be of different lengths?

  Well, if we can all make slight changes to the spec so that it fits our special layout manager this wouldn't be much of a showdown. IMO the spec is the spec and should be followed, or it's meaningless.

  Posted by: mikaelgrev on October 12, 2006 at 01:56 PM

• Hi Mikael-

  You wrote:
  Well, if we can all make slight changes to the spec so that it fits our special layout manager this wouldn't be much of a showdown.

  Sure it is. Call it "artistic license".

  If you were designing Address Book Demo, would you align the first name, email, and postal code fields?

  A week ago, John O'Conner wrote:
  When I finally accepted that I couldn't align components across other elements (Address 1 and 2), most of my troubles went away. Another example...At first I wanted First Name, Email, and Postal Code to all be anchored to the right as if they were in the same column. Of course, that didn't work either.

  See? Matisse and GroupLayout prevented John from achieving his desired design. Which was pretty much my experience with those tools and part of my motivation for creating DesignGridLayout.

  Cheers, Jason

  Posted by: josgood on October 12, 2006 at 03:14 PM

• I think it would be better to ask John to change the spec accordingly, so that we are on even terms, don't you think?

  Posted by: mikaelgrev on October 12, 2006 at 03:54 PM

• Btw, what if you don't want things aligned? Maybe the dialog have very little space to deal with or there are other reasons such as customer demands or a very ling label with a very short text field. I think it is good to show if the LM can handle both aligned and unaligned.

  Posted by: mikaelgrev on October 12, 2006 at 04:02 PM

• I guess we'll just have to hear from John whether he wants the entries to look like his original goal or to look like what he was able to get with Matisse.

  Also, I think it's up to John whether he allows some artistic license, or whether we should hew to the spec precisely.

  Another nit-picking question: Why does the Delete button look different? Is it the button with focus or the default button? I ask because I don't have a Mac, and I'm not familiar with the L&F.

  Posted by: lmfinney on October 12, 2006 at 06:01 PM

• I think it would be better to ask John to change the spec accordingly, so that we are on even terms, don't you think?

  As long as it's not a ridiculous layout spec (which I've seen in other comparison efforts), I'm not sure that we can say that we're not on "even terms".

  Perhaps another question to answer for John is which parts of the spec didn't fit well for the layout manager. The unequal label sizes is not a good fit for FormLayout, and I suspect that's true for other grid-based layouts as well.

  Posted by: lmfinney on October 12, 2006 at 06:06 PM

• what if you don't want things aligned?

  Then you definitely wouldn't use DesignGridLayout.

  At which point, I'd then probably ask "What are you doing?" Mullet and Sano, authors of "Designing Visual Interfaces", make a compelling case for using canonical grids for forms design. Karsten (of JGoodies fame) also makes the case for the use of (proper) grids.

  It's my thesis that the reason we developers create "suboptimal" user interfaces is because we haven't had the tools to easily implement canonical grids. Provide better tools and better designs will follow.

  Ditto other common layout "design patterns", like property sheets, outlines, etc. Whenever there's a useful, semi-common layout "design pattern", it's an opportunity to create a special purpose layout manager targeting that need. We already do this with login boxes, alert boxes, color pickers, font pickers, etc.

  Posted by: josgood on October 12, 2006 at 06:32 PM

• Wow, I'm beginning to see the limitations of doing this via blog. I think there are lots of potential panels we could do, but we might have to limit the discussion here to just a couple. Let me see what I can clear up in the next blog entry. I'll draw on the panels too to make the alignments more clear. Now here's a problem we can't solve...my poor design skills for UI! So, you're going to have to bite your tongue and humor me on this...for the sake of creating a comparison that is comparing apples and apples. We will never agree on what the layout should be, but we can compare solutions for something, and I'll try to define that more clearly.
  P.S. Someone mentioned that the comment "preview" feature didn't work so well...i see what you mean. Anyone listening on java.net? If you preview your comment, then "post" it, the post is empty because...well, it appears that the comment doesn't actually get copied over into the comment text field.
  

  Posted by: joconner on October 12, 2006 at 09:19 PM

• Very interesting.

  Why should the spec be changed? A problem has been specified, and if you cannot solve the problem, then that's it.

  I think this issue of 'canonical grids' is also a red herring. Layout managers are supposed to perform certain functions, and the best one is the one that performs as many of them as possible in fashion that is easily understood and therefore useable by the programmers. I think for this reason, it's also a cop out to say that there is no best layout manager.

  Finally to ask John to answer 'which parts of the spec didn't fit well for the layout manager' is completely uspside down: it's upto the proponents and the designers of the layout managers to say what part of the spec their favorite layout manager could not satisfy.

  
  

  Posted by: varan on October 12, 2006 at 10:19 PM

• josgood

  It seems to me that your GUI stretches both the labels and the textboxes when the window is resized. Is that correct?

  This brings me to one more criterion that might be used to judge the managers: Do they automatically determine which components (or columns/rows within a grid) are to be streteched, and how much, when the window resizes, or do they require the programmer to set specific parameters (like 'grow', 'fill' etc) that control this behavior?

  Posted by: varan on October 12, 2006 at 10:33 PM

• Finally to ask John to answer 'which parts of the spec didn't fit well for the layout manager' is completely uspside down

  I'm sorry for the confusion, but that's not what I meant. I'm proposing that as a question John could ask us, not that we should ask him. Essentially, we could explain some of the limitations (as you obviously prefer).

  It seems to me that your GUI stretches both the labels and the textboxes when the window is resized. Is that correct?This brings me to one more criterion that might be used to judge the managers: Do they automatically determine which components (or columns/rows within a grid) are to be streteched, and how much, when the window resizes

  Well, the initial requirements included these:
  # All text fields and the list at the left should expand horizontally and get equal amounts of the additional space.
  # The list should also expand vertically.
  # Keep the row of buttons immediately under the address information even if the the list expands vertically when you resize.

  I take that to mean the JTextFields grow, but not the labels. I think all LayoutManagers have some default behavior when a component is resized, so the matter here is matching the spec, which does require specific coding.

  Posted by: lmfinney on October 13, 2006 at 05:55 AM

• infinney

  I agree that specific requirements may require specific coding. My statement was meant for the general behavior of a layout manager. I think it adds to the useability of a manager if the programmer does not have to explicitly specify what has to stretch automatically and what need not.

  I am of the view that a layout manager is supposed to solve what is essentially a geometrical problem. So it should be assessed on the basis of at least three criteria: (a) how general and robust is its algorithm for the layout, (b) how easy it is for the programmer to quickly understand the API-specific concepts, and (c) how easy it is for him to use the API. Many other issues being talked about here are not quite germane to the problem. It might be difficult to judge many managers on the score (a) as their algorithm is not very well specified publicly. On the other hand, the scope of problems solved by some, say the Flow Layout, is so limited that it's not even worth considering

  Posted by: varan on October 13, 2006 at 07:28 AM

• The code and answers for ZoneLayout are now posted on the wiki.

  Posted by: bnahas on October 15, 2006 at 12:01 PM

• I can't use LGPL for legal reasons outside my control (I've tried) - is there any hope of an alternate licence version, such as Apache?

  Posted by: prabysupport on October 18, 2006 at 12:22 PM

• My GridBagLayout example is on the wiki now.

  I think that it serves as a good reminder of why we have third party layout managers in the first place. :-)
  William

  Posted by: afishionado on October 18, 2006 at 09:18 PM

• Is there going to be any follow-up on this? Any closure?

  Posted by: lmfinney on October 31, 2006 at 11:12 AM

• lmfinney, I have provided a follow-up blog that points to the results of this layout manager comparison. As far as closure, I think this particular layout comparison effort will wane soon. However, I'm thinking about providing yet another challenge for a different panel. My own contribution to this discussion was to prompt and promote it. I'm hoping that others will contribute to and maintain the existing wiki entries for the layout managers discussed so far.

  Posted by: joconner on October 31, 2006 at 11:29 AM

• I found https://transparentlayout.dev.java.net/ today !
  Looks trival, just working with rectangles !!
  I do not know if author is aware of this blog !

  Posted by: nitinchauhan on March 04, 2007 at 04:10 AM

• Can you include RCLayout in the showdown list at the top? It is available on sourceforge, project name rclayout. I will research it. Thanks.

  Posted by: rkippen on April 02, 2007 at 12:02 PM

• J O'ConnerCan you please create a results wiki page for RCLayout? I can't find how to do this. Also, I can only find the PageLayout results because there is a link on this page. Is there a page with links to all of the showdown results???

  Posted by: rkippen on April 02, 2007 at 05:07 PM

• Nevermind. The comparison page can be found here:
  http://wiki.java.net/bin/view/Javadesktop/LayoutManagerShowdown

  
  To create a new page there, navigate to the URL as if it existed. Then you will see a "Page Not Found" page, but there is a "Create" link on that page.

  Posted by: rkippen on April 04, 2007 at 03:04 AM

This work is licensed under a Creative Commons License.