Re: GtkSpreadTable ('spread-table' branch)



On Mon, 2010-10-11 at 19:48 +0900, Tristan Van Berkom wrote:
> On Mon, 2010-10-11 at 11:04 +0200, Murray Cumming wrote:
> > On Fri, 2010-10-08 at 23:31 +0900, Tristan Van Berkom wrote:
> > > For what its worth I finally applied this algorithm
> > > to the 'spread-table' branch.
> > > 
> > > In the case that the trailing columns get no
> > > widgets, one widget is placed in each of the trailing
> > > columns (again, only happens with lots of columns
> > > and not enough widgets... and seems to look good
> > > this way IMO) 
> > 
> > I think you have broken the single-line case. No child widgets seem to
> > appear for me now when lines=1.
> >  
> 
> Interesting I'll check that out, the current expected results is that
> it still lines up children on 2 lines (i.e. thats the current minimum
> for the "lines" property, so I would expect a warning message and
> a behaviour of 2 lines).

That seem rather arbitrary. Allowing lines=1 lets me use it more
generically and dynamically. Otherwise I need to switch to a GtkBox just
for that case.

> Since having a single-line spread table is desired, I'll go ahead
> and change that (I suppose 2 lines is still a good default though).

Yes.

> fwiw, there's another unhandled case; currently when there are
> less widgets in the table than there are lines declared; space
> is still allocated for the extra missing lines.

That sounds OK to me, as long as it's documented. It's giving the coder
what he asked for. Otherwise, lines would be max-lines.

> Is it desirable to:
>   a.) Only request and allocate space for columns we have enough
>       widgets to fill ?
> 
> or 
>   b.) Request and allocate space for a third column if only 2 widgets
>       are in the box (leaving the impression that there is actually
>       a third column that is simply unpopulated) ?
> 
> I'm pretty sure that 'a' is the reasonable choice but I was not 
> entirely sure.
> 
> Cheers,
>        -Tristan
> 
> 

-- 
murrayc murrayc com
www.murrayc.com
www.openismus.com



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]