Mailing-List: contact user-help@pivot.apache.org; run by ezmlm
Precedence: bulk
Reply-To: user@pivot.apache.org
Received-SPF: pass (athena.apache.org: domain of noelgrandin@gmail.com
 designates 74.125.82.50 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=message-id:date:from:user-agent:mime-version:to:subject:references
         :in-reply-to:content-type:content-transfer-encoding;
        b=EPg47keV6ZDxINKJnDC762LIPrRa0ZCEWerw+kpghz+YWJSvK6oNe66JCPFgj2xr8s
         fQK5UiztSC5DtjUML0y8ipJLrOVRTM8+3e+XPHBd+Zg1ouC2k1aCDvcMyrnMu7S/iZ+z
         NDaG3h9SFeMR5GD+iYXtMkf4p6OUgbChaAZdc=
Message-ID: <4D836C00.2080807@gmail.com>
Date: Fri, 18 Mar 2011 16:28:16 +0200
From: Noel Grandin <noelgrandin@gmail.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US;
 rv:1.8) Gecko/20051201 Thunderbird/1.5 Mnenhy/0.7.3.0
MIME-Version: 1.0
To: Greg Brown <gk_brown@verizon.net>, Pivot User <user@pivot.apache.org>
Subject: Re: The patchwork that is Pivot layout
References: <AANLkTinv7JQg6mTLa=SqGc2MCSuquoE+MR=_oG27BcMZ@mail.gmail.com>
 <4D831C36.6000308@gmail.com>
 <E543EC87-B782-4361-BB30-1006A4D0747C@verizon.net>
 <4D835EEF.8010907@gmail.com>
 <4A246DB7-FD48-41B3-BDD0-EE06BCC94282@verizon.net>
In-Reply-To: <4A246DB7-FD48-41B3-BDD0-EE06BCC94282@verizon.net>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

Greg Brown wrote:
>>>> At the moment, the "fill" style of BoxPane is doing double duty.
>>>> It means two things for a vertical boxpane
>>>> (1) make the component fill the available width if the component is smaller than the boxpane width
>>>> (2) if the components preferred width is greater than the available width, cut off the component.
>>> Actually, in #2 the component isn't simply clipped to the box pane's width - it is given its constrained preferred height. This gives the component a chance to wrap its content, which wouldn't be possible without the fill style (we need a width to constrain against).
>>>
>> Yeah, but we want to give components the chance to wrap even if fill is false, which is not currently the case.
> In order to wrap, a component needs a width constraint. The "fill" flag allows us to use the width of the BoxPane as this constraint. Otherwise, how would we know what the wrap width should be? The only other way to do it would be to assign an explicit preferred width to the component.
>
In layout(), we have a width constraint we could use, which is the width that has been allocated to us. Similarly in
getPreferredHeight(int).
I already prototyped this, so I know it solves Bill's problem. (but I haven't implemented a complete solution yet).

>>>> Border could do with having alignment and fill styles, which is a fairly straightforward change and would make this
>>>> class more useful.
>>> It could, but I'm not sure how much value that might really offer. How often do you want to put something in a border that doesn't completely fill the internal space of the border? Probably not that often, and when you do, you can use BoxPane, TablePane, ScrollPane, etc.
>>>
>> Alignment and fill would affect how the bordered component sits within the space allocated by the parent container. So
>> if I wrap a component in a border and put it inside something else, I don't necessarily want it to fill the space within
>> it's parent.
> That sounds similar to what Bill described. But, as I mentioned earlier, Pivot doesn't define horizontal or vertical alignment properties on the Component class. Layout customization properties are defined by the container, not the child component. The only input a child component has into the layout process is preferred size.
>
ImageViewSkin and LabelSkin already have "child" properties like this. So we have precedent.
I implemented something similar in BorderSkin as an exercise. Pretty straightforward.
 I'm just waiting on the outcome of this discussion to see if I should check it in.

I agree that this is (minor) violation of the DRY principle, but I like my libraries to have some redundancy, especially
when it eases the life of client programmers.

Regards, Noel.