Hans Muller's Blog

MultiSplitPane: Splitting Without Nesting [Shameless Plug]

One aspect of many docking GUIs is support for reconfiguring tiled subwindows by dragging shared subwindow edges. MultiSplitPane and MultiSplitLayout support arbitraily complex tiled layouts that can be reconfigured interactively and programatically.

As introductory paragraphs go, the previous one has to set a new record for "not catchy". It always seems easier to start these things with a personal story or recollection. So how about this:

Earlier this year I was arguing with Tim Boudreau about docking frameworks and how best to compute an initial layout, when it occurred to me that a tree structured model would be a nice way to encode the relative sizes and positions of the tiles. If nodes in the tree corresponded to tiles arranged in rows and columns, and if tiles were allocated space proportionally, it seemed like only a small project to build a two dimensional analag of JSplitPane. Tim suggested that my project estimating skills were suspect and besides, there were more important things to do. He was right on both counts, and yet. Sometimes, when you're orbiting around an idea, headed somewhere else, you find yourself captured by the idea's gravitational field. As it turns out, I was in the software-idea equivalent of a tractor beam.

Over the next two days, I implemented the idea. Since subwindow tiles were always allocated a fixed percentage of the available space, it was easy to write a recursive layout algorithm that arranged the rows and columns. As I was just finishing up, Josh Marinacci dropped by, and so I proudly demo'd my creation. The nice way to respond to someone's new demo, on Friday afternoon, is to smile, deliver a bland compliment, and suggest that it's time for a cold one. Josh said: "that's nice, but I don't think anyone would really want to use it". After I stopped crying, he pointed out that people expect subwindow tile boundaries to stay put when the window is resized. This is true, and it makes the problem substantially more difficult. It means that growing and shrinking the layout aren't symmetrical, and it implies that the layout should honor preferred tile sizes, until the user has indicated otherwise by dragging an edge. So, with tears in my eyes, I started over again.

Version two of the layout algorithm took considerably longer than the original version. The result is the aforementioned MultiSplitPane and MultiSplitLayout classes, a small set of demos, a smattering of unit tests, javadoc, a nod to accessibility (more on that later), and an article that explains how it all works. The article bows today on java.net, it's called MultiSplitPane: Multi-Way Splitting Without Nesting. I hope you'll find the time to read it. The classes will become part of the SwingLabs project now and perhaps be incorporated into a future Java release.

Comments

• Really cool feature this MultiSplitPane, it will help a lot for docking API :D

  Posted by: alexiskinsella on March 23, 2006 at 08:41 AM

• Umm, if you were talking to Tim about this, surely he told you netbeans already had one, written back in 2004: http://www.netbeans.org/source/browse/core/windows/src/org/netbeans/core/windows/view/ui/MultiSplitPane.java

  ...and I believe it's fully separable from the netbeans codebase. Or am I missing something, and this is a completely different type of MultiSplitPane?

  Posted by: richunger on March 23, 2006 at 10:02 AM

• 
  "An article I'd written earlier this year about a multiway split pane, is now available on java.net. Read the back story in this gripping new blog.
  "

  Gripping in an understatement Hans... When I read the line:

  "So, with tears in my eyes, I started over again."

  well... I'm not too proud to admit it... I burst into cheers that rang down the hallway... Such fortitude, such stick-to-it-ness, such resolve.

  Makes me proud just to be in the same profession ;-)

  
  On a more serious note... pretty cool Hans!

  --JohnR

  Posted by: johnreynolds on March 23, 2006 at 12:17 PM

• There are lots of multiway Swing split-panes around, including the one
  in NetBeans. Most of them, including Netbeans', enable two
  dimensional row/column layouts through composition. In other words
  you compose row and column split panes to get the effect you want.
  This version uses a single tree strucutured model of the entire
  layout, so it doesn't require "nesting". Hence the title.
  

  Posted by: hansmuller on March 23, 2006 at 01:29 PM

• Hans, I haven't tried out the new component yet, but still, you're the funniest blogger on java.net, and your blogs usually make my day; I burst out giggling at this one. If working on odd components gives you and excuse to blog more often, keep it up, man. Patrick

  Posted by: pdoubleya on March 23, 2006 at 11:36 PM

• Patrick : Just imagine he's the same all day at the office ;-)

  Posted by: gfx on March 24, 2006 at 01:51 AM

• The standalone version of the NB library is here:

  http://www.netbeans.org/source/browse/contrib/uberMetaSplitContainer/

  As far as I know it is a single component with a binary tree data model, not a nesting of bilateral split panes as Hans implied. There seems to be another higher-level split panel in a different package with different behavior.

  Posted by: jglick on March 24, 2006 at 10:21 AM

• Ah, right. uberMetaSplitContainer. Yeah, I don't really get what the difference is between that and this one. I'm also confused because you'd think Tim would've mentioned that (since he wrote uberMeta) and saved Hans a lot of work :)

  Posted by: richunger on March 27, 2006 at 11:40 AM

• The NetBeans MultiSplitPane I was referring to is:

  core/windows/src/org/netbeans/core/windows/view/ui/MultiSplitPane.java

  That's the split pane code that's actually used by NetBeans. It
  defines multiway splits by nesting row/column layouts.

  If you've ever met Tim Boudreau you know that you can not discuss any
  topic for very long with seeing a demo - usually one that he's written
  - that's related to the discussion topic. Naturally he showed me a
  demo of his (unfinished) multisplit layout manager. It's
  fundamentally different from MultiSplitPane in that the layout model
  is grid-centric and because it supports resizing along shared edges
  and shared vertices. The corner cases (pun intended)
  introduced by the latter still merit some design work. The demo is
  quite impressive.

  In the "uberMetaSplitContainer" contrib directory Jesse referred
  to there are actually three different multway split layout managers.
  One is Tim's demo, one seems to have been largely deleted, and the
  third is a grid-centric multiway split pane in which the layout model
  models the (implicit) row/col hierarchy and contains references
  back to the component hierarchy. Although there are superficial
  similarities to MultiSplitPane, as I'm sure there are in the multitude
  of other multi-way split components floating around, the structure
  of MultiSplitPane is quite different. For example, I've factored the problem
  along conventional lines, with an independent layout manger, and
  the layout model is explicitly tree-structured and lacks explicit
  pointers into the component hierarchy. The design was motivated by
  my desire to make it easy to persist layouts, by storing (just)
  the layout model using the Java Beans archiver.

  
  

  Posted by: hansmuller on March 28, 2006 at 09:42 AM

• Cool, thanks! That's really interesting. So many ways to skin a cat. I can see how your approach would make persistence so much easier.

  Posted by: richunger on March 30, 2006 at 08:18 AM

This work is licensed under a Creative Commons License.