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
