JSplitPainInTheAss: A less abominable fix for setDividerLocation
Update: Some discussion of this idea and code updates are in the gist here. Hubris.
If you use Swing much there will come a time when you’d like to create a splitter, aka
JSplitPane. Overall, it works fine, but it has one lame, lame, lame feature; if you want to set the divider’s initial position proportionally, you’re screwed. I say feature, because the documentation for
JSplitPane.setDividerLocation clearly states that it won’t work if the component hasn’t been “displayed” yet.
I bet that 95% of the time the programmer using this function is calling it at start-up before anything is displayed. Way to cover the 5% case there.
Anyway, you’ll go to Google and try to find a solution to this problem and you’ll find a lot of discussion and many variations on the same workaround. But they inevitably rely on sub-classing (isn’t that the solution to everything in Swing?) and hacking in some logic to fix things right before the splitter gets painted the first time. Nasty.
I’ve been thinking about this in terms of Seesaw, a Clojure/Swing API I’ve been working on. I want
setDividerLocation to cover the 95% case and I don’t want to sub-class anything if I can help it. It’s not composable. So I thought about it a bit and came up with a much more elegant solution that works on a vanilla
JSplitPane. Since I think this will be much more interesting to the Java Swing developers toiling away out there, I’ve coded it in pure Java. Here it is, a simple function:
If you can’t see any code, look here.
By the way, this code is insanely shorter in Clojure. Just sayin’.
The basic idea is to keep putting off the call to … strike that. The
invokeLater until the splitter is realized on the screen. No fuss, no muss.
invokeLater approach did indeed work, but under certain circumstances, a split pane that wasn’t displayed very soon would result in an infinite cascade of
invokeLater events. The main problem with this is that the processor never gets to sleep, etc, etc. So I came up with an alternate approach which takes advantage of a
HierarchyChange event to detect when the split pane is displayed (learn something new every day) optionally followed by a resize listener because the hierarchy event may arrive before the split pane’s been laid out by its parent. Swing’s exhausting.