Mailing-List: contact pivot-user-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: pivot-user@incubator.apache.org
Received-SPF: pass (nike.apache.org: local policy)
From: Scott Lanham <lists@sael.com.au>
To: pivot-user@incubator.apache.org
Subject: Re: TableView in a ScrollPane
Date: Wed, 26 Aug 2009 13:01:49 +1000
User-Agent: KMail/1.11.2 (Linux/2.6.28-15-generic; KDE/4.2.2; x86_64; ; )
References: <200908261133.57287.lists@sael.com.au>
 <BE4510CD-D7EF-4DAE-9E87-27D0E708DDF7@mac.com>
 <168ef9ac0908251949k7c7e376cqbaa35c53c6b59381@mail.gmail.com>
In-Reply-To: <168ef9ac0908251949k7c7e376cqbaa35c53c6b59381@mail.gmail.com>
MIME-Version: 1.0
Content-Type: Text/Plain;
  charset="us-ascii"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Message-Id: <200908261301.49268.lists@sael.com.au>

One of the problems I have always had with creating UI's has been dealing with 
variations in font sizes across different systems. Best practice for me is if I 
can write a UI without specifying a single dimension in pixels. So any feature 
that can give automatic or relative sizes is a very good thing :-)

On Wed, 26 Aug 2009 12:49:24 pm Todd Volkert wrote:
> > Oh and it would be a very cool thing if the TableView could support
> >
> >> automatic
> >> widths :-)
> >
> > By "automatic", do you mean "size to fit"? In other words, make the
> > column width the max. width of all the cells in a particular column?
> >
> > If so, we don't currently support that. We could conceivably do so by
> > supporting a value of -1 for column width (like TablePane columns), but
> > we didn't think there was a strong use case for that. TablePanes
> > generally have a small number of rows, so calculating this width doesn't
> > impose a performance penalty. However, TableViews are intended to display
> > a large number of rows and it could be costly to determine this value.
> >
> > On the other hand, if you know you are only going to have a small number
> > of rows in your TableView, it might be a useful feature. Please feel free
> > to submit a feature request for this (in JIRA).
>
> There's also been talk a long time ago about adding the ability for
> the user to double-click in between column headers to size the column
> to fit.  This wouldn't impose a big performance penalty because it
> would be a one-time hit, as opposed to something that were calculated
> every time the
> TableView were asked for its preferred size.  Would this feature meet your
> needs here?
>
> > Greg