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 you, I have temporarily given up creating the > entire Workbench environment I really would like to have, and instead > need to go with a more quick and dirty approach, in which case WTKX > enters the stage... > > So, see wtkx file below, which partitions the main working area on > start, currently 3 regions horizontally (I am putting in one more > region for "Properties" and with that there will be a mix of vert and > horiz splits). It would have been sooooooo convenient to just add > splitLocation="20%", without programming. > > Now, I am probably doing something wrong regarding "size it up to > available space", and I have not yet twisted my head around how the > Skin interacts with the 'clues' one give, so perhaps the prefSize > suggestion is premature, just borrowed the idea from CSS. > > > <Border xmlns:wtkx="http://pivot.apache.org/wtkx"; > xmlns:content="org.apache.pivot.wtk.content" > xmlns="org.apache.pivot.wtk" > > <content> > <SplitPane orientation="vertical" splitLocation="600" > preferredWidth="1024" preferredHeight="768" > primaryRegion="top_left"> > <top> > <SplitPane orientation="horizontal" splitLocation="200" > preferredWidth="200" preferredHeight="200" > primaryRegion="top_left"> > <left> > <wtkx:include src="projectview.wtkx"/> > </left> > <right> > <SplitPane orientation="horizontal" splitLocation="730" > primaryRegion="top_left"> > <left> > <wtkx:include src="editorsarea.wtkx"/> > </left> > <right> > <wtkx:include src="tools.wtkx" /> > </right> > </SplitPane> > </right> > </SplitPane> > </top> > <bottom> > <wtkx:include src="messagearea.wtkx" /> > </bottom> > </SplitPane> > </content> > </Border> > > > On Tue, Aug 4, 2009 at 7:30 PM, Todd Volkert<[email protected]> wrote: > > splitLocation aside (more on that in a minute), I was talking about using > > TablePane. The preferred size is just a suggestion to the component's > > parent -- in the end, it's up to the container that is doing the layout > to > > respect the preferred sizes of its children or not. Some containers do, > and > > others don't. Thus, it's up to the container to say "I'm going to give > 30% > > to X and 70% to Y," which is why I thought of TablePane -- it has a > notion > > of relative sizing. If you elaborate of your use case for a relative > > preferred size, then maybe I'll see why TablePane doesn't work, but out > of > > the gates, I'd expect it to work. > > > > Moving on to splitLocation, a splitter is meant to be dragged. If you > want > > the splitter to be fixed at 30%, then SplitPane isn't the right tool > (again, > > TablePane is). If you want to *initialize* the splitter to 30%, then > that's > > a different beast. In that case, I'd use > ApplicationContext.queueCallback() > > to queue a runnable that sets the splitLocation after the SplitPane has > been > > laid out, at which time you'll know how to calculate the appropriate > value > > for splitLocation. The problem with trying to say "I want the > splitLocation > > to be 30%" is that if you say that before the the SplitPane has been laid > > out, its size is 0,0, and the splitLocation will likewise be 0. If you > say > > it after it's been laid out, then we don't need the relative semantics, > > because you can just do the math yourself. > > > > -T > > > > On Tue, Aug 4, 2009 at 7:16 AM, Niclas Hedhman <[email protected]> > wrote: > > > >> On Tue, Aug 4, 2009 at 7:07 PM, Todd Volkert<[email protected]> wrote: > >> > TablePane supports laying out its children using relative width and > >> height - > >> > might it satisfy your use case? > >> > >> Are you talking about using TablePane, or applying the same semantics > >> elsewhere? > >> > >> using TablePane --> No, I actually would like to have it for pS and > >> splitLocation of SplitPane. > >> > >> same semantics --> I need to look at TablePane closer to have an > opinion. > >> > >> > >> Cheers > >> -- > >> Niclas Hedhman, Software Developer > >> http://www.qi4j.org - New Energy for Java > >> > >> I live here; http://tinyurl.com/2qq9er > >> I work here; http://tinyurl.com/2ymelc > >> I relax here; http://tinyurl.com/2cgsug > >> > > > > > > -- > Niclas Hedhman, Software Developer > http://www.qi4j.org - New Energy for Java > > I live here; http://tinyurl.com/2qq9er > I work here; http://tinyurl.com/2ymelc > I relax here; http://tinyurl.com/2cgsug >
