pivot-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Greg Brown <gk_br...@verizon.net>
Subject Re: The patchwork that is Pivot layout
Date Fri, 18 Mar 2011 20:51:17 GMT
> I think the real double duty is BoxPane itself.  
> (1) It is a simple way to place a series of components linearly in a container.  In that
role, it really would be more logical for it to behave as if it had fill=true, much like many
other containers implicitly do.  

While it is common to use BoxPane with fill=true, it is also pretty common to use it with
fill=false and some alignment values. So I think having support for both is handy.

> (2) With its default fill=false, it is a kind of wrapper (maybe the only one in Pivot?)
that allows you to position a single component within a "filled" container, much as I do in
the example that started this thread.

FlowPane also allows you to do this. The main difference is that FlowPane will wrap, whereas
BoxPane does not. FlowPane also doesn't support a fill style. 

An "AlignmentPane" might help, but it would be kind of redundant, since it would basically
be a box pane that is limited to one child component. I do wonder if maybe providing alignment
support for table cells might not be a bad idea.

> Were we designing Pivot from scratch, I'd propose no fill property on any container

The problem is that, without some concept of "fill" (or "justify"), there's no way to determine
width or height constraints, so wrapping wouldn't work.

> Would it make sense for an explicit preferred width/height on a component to trump fill?
 Today, if I want my component to fill the space available in its parent, I simply don't specify
a size, right?  

It depends on the container you put the component in. StackPane and Border, for example, will
always size their children to fill. BoxPane with fill=false will not, nor will FlowPane. TablePane
will size each cell component to fill (to the column width/row height of the cell).

> Given that, then what do preferred width/height really mean, and why should a parent's
fill behavior cause those properties to be ignored?

They are hints to the container. They also help the container determine its own preferred
size. For example, a Border will report a preferred size equal to its content's preferred
size plus the border thickness, padding, etc. If a Border is placed in a container that respects
preferred size, then its content will also be given its preferred size. In all cases, though,
Border simply sizes its content to fill its available client area.

> I second Roger's point that we could use a tutorial on how layout works, and how to think
about it.  A less elaborate way to help in this regard might be to document (in the javadoc)
many more of the current style properties.  For example, at the moment, there is no doc at
all for BoxPane#setFill and BoxPane#setHorizontalAlignment.  Given all the confusion in this
thread about those properties, a little javadoc might head off the next round of same.

Agreed. Any volunteers?  :-)

> I notice that Pivot has a barely populated Wiki.  Can anyone contribute to it?  I've
been thinking recently that I ought to write up some kind of "Pivot for the WPF programmer"
advice.

It's not public, but if you have an account on the Wiki you can be granted access.



Mime
View raw message