Re: [gtk-list] RE: [vh]box size allocation question (again).

[johannes nada kth se (Johannes Keukelaar)]

//> Hi All,
//>
//> A week ago or so, I posted this question, which, if I remember correctly,
//> hasn't been answered yet. I still wonder:
//>
//> It seems that, in 1.0.2 at least, the size allocation of a vbox
//> (and presumably
//> an hbox as well) tries to divide the size it's given equally over all its
//> children (rounding down), and gives the remainder to the last
//> one. This means
//> that the last child can be significantly larger (number of
//> children minus one
//> pixels) than the other ones. See for example
//> http://www.nada.kth.se/~johannes/vbox.gif for an example. This,
//> IMHO, looks
//> fairly ugly. Mind you, I'm not sure if any other solution would look any
//> better. I'm just wondering: Is this a conscious design choice? Wouldn't
//> 'dithering' the sizes (i.e. do the computations in floating
//> point, then round
//> down) look better? Then the size difference is at most one pixel...
//
//I think the table layout code works a bit better, so that there's at
//most 1 pixel difference, though I think it gives the extra pixels to
//the right/bottom cols/rows rather than spreading them out (but I'm
//not sure). Maybe the boxes should do a similar thing.

Perhaps I should look at the table layout engine, then. If/when I decide to fix 
the boxes. (Do the boxes need fixing? Two in favor, so far.)

//I think your interface would look better in a table anyway.

Yes, it probably would. However, the gif is a simplified version of my 
interface.

(1) The interface is built up interactively. The user can type perl commands, 
which can cause new 'rows' to be added to the vbox. It seems that tables have a 
fixed number of rows and columns, set on creation. There is no interface for 
changing these numbers. Can one just go in and change them in the struct? 
*shiver* It seems that this ability would be useful for others, too.

(2) The list contains (widgets representing) objects, and some of these objects 
can contain one more level of objects (max one level of recursion). For these 
'container' objects, I have some nested v and h boxes that enables me to 
dynamically show or hide the contents of the container (by a simple 
gtk_widget_show/hide call). This would also be (a lot?) more complicated in a 
table.

(3) Besides, I couldn't frame my container objects to show that they are 
container objects.

//Damon

Regards,

Johannes.
--
"Sometimes you just can't be afraid; To wear a different hat;
If Columbus had complied; This old world would still be flat" - Garth Brooks

Self-professed nerd of Mathematics and Computer Science.