Todd, Perhaps it is not an issue at all, since I realize that once I get further down the road, the split settings must be saved across starts, and a programmatic approach is need.
I hope I will manage to get the base of the app up and running in full by this week, and sure will have more feedback by then. -- Niclas On Aug 4, 2009 8:03 PM, "Todd Volkert" <[email protected]> wrote: Ok, now I see the issue. Two things: 1) it's one I've run into myself, and 2) it's a SplitPane-specific issue. #2 confirms my suspicion that a relative preferred size isn't the right solution here, as the problem lies with SplitPane, not with layout in general. So here are the facts that make this a challenging problem: a) We don't want to introduce a general semantic of saying "I want the split location to be at 20%", because it would effectively lock the splitter in place at 20%, taking away the essence of what SplitPane provides (a movable splitter). b) We can't say "set it to 20% of the SplitPane's current size" because at the time we say that, the SplitPane hasn't been laid out yet and has no size. What would be nice is a way to tell the split pane "set your split location to 20% after you've been laid out, then let is be adjustable". Phrased that way, how can we solve this problem? We could add "splitPercentage" bean methods, making them WTKX compliant. The getter would return the splitLocation as a percentage of the width/height (depends on the orientation), and the setter would queue a callback to set the split location. That may work very well actually. Are there any objections or better ideas? Also, you may have already noticed this, but SplitPane is a container that has no preferred size -- it's meant to be placed in a containment hierarchy in which it will not be asked for its preferred size. Alternatively, as you have done, you can set an explicit preferred size on it. -T On Tue, Aug 4, 2009 at 7:42 AM, Niclas Hedhman <[email protected]> wrote: > As I have not told yo...
