You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@pivot.apache.org by Niclas Hedhman <ni...@hedhman.org> on 2009/08/04 07:24:13 UTC
Proposal; Relative sizes
Gang,
I think it would be nice that preferredWidth & preferredHeight could
be expressed in % of available space (if possible). Same probably goes
for many other properties, such as SplitPane.splitLocation
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
Re: Proposal; Relative sizes
Posted by Greg Brown <gk...@mac.com>.
As Todd mentioned, it is up to the container to decide how (or if) a
component's preferred size will be used during layout. Swing layout
works the same way. TablePane allows you to specify the width and
height of a column or row as relative to the amount of unallocated
space, so I would suggest looking at that.
However, from your emails, it seems like your ideal UI would use split
panes, not table panes. Todd is the split pane expert, so I will defer
to him here. :-)
On Aug 4, 2009, at 1:24 AM, Niclas Hedhman wrote:
> Gang,
>
> I think it would be nice that preferredWidth & preferredHeight could
> be expressed in % of available space (if possible). Same probably goes
> for many other properties, such as SplitPane.splitLocation
>
>
> 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
Re: Proposal; Relative sizes
Posted by Todd Volkert <tv...@gmail.com>.
Yep - the API change would be that get/setSplitLocation would return/take a
float instead of an int.
-T
On Tue, Aug 4, 2009 at 10:18 AM, Niclas Hedhman <ni...@hedhman.org> wrote:
> Hold it off for a couple of days, and I'll try to take a stab at it... if I
> understood you, a API change would be acceptable at this stage?
>
> Cheers
> Niclas
>
> On Aug 4, 2009 9:56 PM, "Todd Volkert" <tv...@gmail.com> wrote:
>
> Well, I just created a ticket for it. It's probably about 30 minutes of
> work for me, so this is the classic issue that is getting discussed right
> now on our graduation thread: do I go ahead and tackle it since I can do it
> very easily, or do I ask you to do it with much more effort? I don't know
> the right answer :)
>
> -T
>
> On Tue, Aug 4, 2009 at 9:39 AM, Niclas Hedhman <ni...@hedhman.org> wrote:
> >
> Todd, > > Sounds like...
>
Re: Proposal; Relative sizes
Posted by Niclas Hedhman <ni...@hedhman.org>.
Hold it off for a couple of days, and I'll try to take a stab at it... if I
understood you, a API change would be acceptable at this stage?
Cheers
Niclas
On Aug 4, 2009 9:56 PM, "Todd Volkert" <tv...@gmail.com> wrote:
Well, I just created a ticket for it. It's probably about 30 minutes of
work for me, so this is the classic issue that is getting discussed right
now on our graduation thread: do I go ahead and tackle it since I can do it
very easily, or do I ask you to do it with much more effort? I don't know
the right answer :)
-T
On Tue, Aug 4, 2009 at 9:39 AM, Niclas Hedhman <ni...@hedhman.org> wrote: >
Todd, > > Sounds like...
Re: Proposal; Relative sizes
Posted by Todd Volkert <tv...@gmail.com>.
Well, I just created a ticket for it. It's probably about 30 minutes of
work for me, so this is the classic issue that is getting discussed right
now on our graduation thread: do I go ahead and tackle it since I can do it
very easily, or do I ask you to do it with much more effort? I don't know
the right answer :)
-T
On Tue, Aug 4, 2009 at 9:39 AM, Niclas Hedhman <ni...@hedhman.org> wrote:
> Todd,
>
> Sounds like a great idea, and go ahead if it isn't a big deal... or should
> I
> be doing it to increase the committer base ;-)
>
> -- Niclas
>
> On Aug 4, 2009 9:14 PM, "Todd Volkert" <tv...@gmail.com> wrote:
>
> Niclas,
>
> Ok, though as I think it out, I think a slight API change might make
> SplitPane more usable to callers. What if splitLocation were a float value
> that represented the percentage split instead an absolute value? Then, as
> the user dragged the splitter, the skin would update the percentage. And
> you as the caller could specify the percentage just how you'd like. For
> your use case, do you need to serialize the absolute values of the split
> location, or if split pane were changed in this way, could you serialize
> the
> percentages and then re-use them when you brought back up the UI?
>
> -T
>
> On Tue, Aug 4, 2009 at 9:08 AM, Niclas Hedhman <ni...@hedhman.org> wrote:
> >
> Todd, > Perhaps it is...
>
Re: Proposal; Relative sizes
Posted by Niclas Hedhman <ni...@hedhman.org>.
Todd,
Sounds like a great idea, and go ahead if it isn't a big deal... or should I
be doing it to increase the committer base ;-)
-- Niclas
On Aug 4, 2009 9:14 PM, "Todd Volkert" <tv...@gmail.com> wrote:
Niclas,
Ok, though as I think it out, I think a slight API change might make
SplitPane more usable to callers. What if splitLocation were a float value
that represented the percentage split instead an absolute value? Then, as
the user dragged the splitter, the skin would update the percentage. And
you as the caller could specify the percentage just how you'd like. For
your use case, do you need to serialize the absolute values of the split
location, or if split pane were changed in this way, could you serialize the
percentages and then re-use them when you brought back up the UI?
-T
On Tue, Aug 4, 2009 at 9:08 AM, Niclas Hedhman <ni...@hedhman.org> wrote: >
Todd, > Perhaps it is...
Re: Proposal; Relative sizes
Posted by Todd Volkert <tv...@gmail.com>.
Niclas,
Ok, though as I think it out, I think a slight API change might make
SplitPane more usable to callers. What if splitLocation were a float value
that represented the percentage split instead an absolute value? Then, as
the user dragged the splitter, the skin would update the percentage. And
you as the caller could specify the percentage just how you'd like. For
your use case, do you need to serialize the absolute values of the split
location, or if split pane were changed in this way, could you serialize the
percentages and then re-use them when you brought back up the UI?
-T
On Tue, Aug 4, 2009 at 9:08 AM, Niclas Hedhman <ni...@hedhman.org> wrote:
> 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
>
Re: Proposal; Relative sizes
Posted by Niclas Hedhman <ni...@hedhman.org>.
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" <tv...@gmail.com> 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 <ni...@hedhman.org> wrote: >
As I have not told yo...
Re: Proposal; Relative sizes
Posted by Todd Volkert <tv...@gmail.com>.
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 <ni...@hedhman.org> 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<tv...@gmail.com> 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 <ni...@hedhman.org>
> wrote:
> >
> >> On Tue, Aug 4, 2009 at 7:07 PM, Todd Volkert<tv...@gmail.com> 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
>
Re: Proposal; Relative sizes
Posted by Niclas Hedhman <ni...@hedhman.org>.
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<tv...@gmail.com> 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 <ni...@hedhman.org> wrote:
>
>> On Tue, Aug 4, 2009 at 7:07 PM, Todd Volkert<tv...@gmail.com> 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
Re: Proposal; Relative sizes
Posted by Todd Volkert <tv...@gmail.com>.
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 <ni...@hedhman.org> wrote:
> On Tue, Aug 4, 2009 at 7:07 PM, Todd Volkert<tv...@gmail.com> 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
>
Re: Proposal; Relative sizes
Posted by Niclas Hedhman <ni...@hedhman.org>.
On Tue, Aug 4, 2009 at 7:07 PM, Todd Volkert<tv...@gmail.com> 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
Re: Proposal; Relative sizes
Posted by Todd Volkert <tv...@gmail.com>.
TablePane supports laying out its children using relative width and height -
might it satisfy your use case?
-T
On Tue, Aug 4, 2009 at 5:44 AM, Noel Grandin <no...@gmail.com> wrote:
> Hi
>
> That would be nice, but the API and implementation is not trivial.
>
> We would need to change the API to either
> (a) expose the current unit of preferredWidth (pixels or percentage)
> i.e. have some kind of width-unit field.
> (b) change to using some kind of SizeConstraint class/struct to
> encapsulate {value, unit}
>
> (b) would be better in my opinion - less possibility of current code
> getting confused about what the value from getPreferredWidth() means.
>
> Regards, Noel.
>
> Niclas Hedhman wrote:
> > Gang,
> >
> > I think it would be nice that preferredWidth & preferredHeight could
> > be expressed in % of available space (if possible). Same probably goes
> > for many other properties, such as SplitPane.splitLocation
> >
> >
> > Cheers
> >
>
>
Re: Proposal; Relative sizes
Posted by Noel Grandin <no...@gmail.com>.
Hi
That would be nice, but the API and implementation is not trivial.
We would need to change the API to either
(a) expose the current unit of preferredWidth (pixels or percentage)
i.e. have some kind of width-unit field.
(b) change to using some kind of SizeConstraint class/struct to
encapsulate {value, unit}
(b) would be better in my opinion - less possibility of current code
getting confused about what the value from getPreferredWidth() means.
Regards, Noel.
Niclas Hedhman wrote:
> Gang,
>
> I think it would be nice that preferredWidth & preferredHeight could
> be expressed in % of available space (if possible). Same probably goes
> for many other properties, such as SplitPane.splitLocation
>
>
> Cheers
>
Re: Proposal; Relative sizes
Posted by Sandro Martini <sa...@gmail.com>.
Hi Niclas,
I like this idea, but what others say ??
Byeeee