Re: Stretching cells (Was Re: [Gzz] Asko 2002-11-22 (client))

[Benja Fallenstein]

Hi Asko,

Asko Soukka wrote:

> Sat, 23 Nov 2002, Benja Fallenstein kirjoitti:
>  
>
> [stretching cells]
>
> > >should use a stencil of box's size. So, is streching actually view's
> > >feature as in 0.6? If view is allowed to strech cells, it requests the
> > >size from the current CellView, which passes the request to the current
> > >CellContentView?
> > Yes.
> >    
>
> With one line cellcontentview this is still trivial, but how should we
> handle multi-line cellcontentviews? 

Do you really consider this a problem related to your question quoted 
above? I see that it's not trivial to decide what size a multi-line cell 
content view should request, but once we figure this out, is there 
anything wrong with the cell view adding its border and padding, and the 
view then using this size in layouting?

> When do we strech both cell's width
> and the height and when only height (with rectangular cell)? 

Multiple algorithms are possible. I'm currently thinking:
- The cell content view has a minWidth, minHeight, maxWidth and 
maxHeight computed somehow.
- We return at least (minWidth, minHeight).
- If that doesn't suffice, we scale horizontally up to (maxWidth, 
minHeight).
- If that doesn't suffice either, we use maxWidth and scale vertically 
up to maxHeight.

For a single-line ccv, I'd use a degenerate form of the algorithm where 
maxHeight = minHeight. (The point being to place an upper bound on the 
cell size, in order to avoid the larger-than-screen cells that were so 
horrible in 0.6's stretch-vanishing view.)

To compute the minWidth etc. parameters, the ccvs would usually get two 
strings, like the current "XXXXXXXXX" ones, and a line count. They'd 
compute the minWidth using the first string and the maxWidth using the 
second (by computing the width of that string using their TextStyle). 
The minHeight would be the height of a single line (i.e. 
textStyle.getHeight()) and the maxHeight would be minHeight * line count.

> Should therev
> be an option to keep the current aspect ratio of a cell? 

Probably not very useful: re-wrapping the lines when the cell grows both 
x- and y-wise is bound to look ugly. Can experiment with it, but I don't 
see it as vital for now.

> Anyway, this
> complicates the interface...

Not really: we can have different CellContentView instances for the 
different policies. Or are you saying that the views should be able to 
specify these things? I don't see important use cases for that, yet.

> Currently I'm thinkin about 2D ball cell, where the text is inside the
> cell (AFAIK this was not implemented in 0.6?). 

You mean the text is drawn in an elliptical frame? No. Why do you want 
it-- just for fun, or is there something special to it?

> Even line divisioning with
> static size don't feel very trivial for me, since every width of the lines
> varies (some kind of array of linewidths should be delivered to
> linebreaker?). 

Hm, linebreaking is difficult. Passing an array of line widths is 
possible, but interacts with billowing in ugly ways. I would suggest 
putting this off a little bit, except if you really need it right now, 
because it makes the line breaker yet more complex while it should get 
simpler... :-)

- Benja