pivot-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bill van Melle <bill.van.me...@gmail.com>
Subject Re: The patchwork that is Pivot layout
Date Fri, 18 Mar 2011 21:21:26 GMT
>
> > (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.
>

Hmm, true, given what I have now come to understand about alignment.  On the
other hand, I think alignment should to some extent trump fill, though not
completely.  E.g., you ought to be able to have alignment=center, which
would mean all components are centered and not stretched to the full width,
but the width of the BoxPane still should be a size constraint on its
children, so that, for example, text could wrap.  In the absence of a fill
property, this would imply an additional default alignment value, call it
"stretch" or maybe even "fill".


> 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.
>

Would it make any sense for there to be an attached property of that sort?
 E.g., in my original example, I'd have said
BoxPane.horizontalAlignment="center" for the 1st and 3rd components.  Oh,
wait, alignment is a style property.  (Another source of confusion for me,
really.  I get how font and color and such are styles and might change if
you had a global style (skin?) system, but alignment?  Well, maybe so.  CSS
has it, after all.)

> 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.
>

I didn't mean to suggest that there wouldn't be fill behavior, just that it
wouldn't be exposed.  Lots of containers today implicitly fill, while only a
few (notably BoxPane) have an explicit property to control it, something
which has clearly led to a lot of confusion.  If all containers filled
automatically where it made sense, you'd get fewer of those "why isn't my
text wrapping?" questions.


> > 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.
>

So you've just demonstrated the recursive aspect of my question.  If I set a
preferred size on a component, and stick that component inside a Border, the
latter now also has a notion of preferred size.  If the Border is then
placed inside a TablePane cell, why should the TablePane cause it to ignore
that size?

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?  :-)
>

If you're suggesting that I'm one, okay, what is the protocol?  My
suggestion involved editing a whole bunch of source code.  Do I do that and
submit patch files or something?  (And if so, is there anything in Eclipse
to make that easy?)

Mime
View raw message