Re: Mod to hbox/vbox

["Shawn T . Amundson" <amundson gimp org>]

Could you re-write what the code I gave you would look like
using your 'shares' idea?  (You don't have to implement shares,
just send back what you think the example should look like.)

Boxes are easy to understand because, well they are simple.  Tables
are more complex, but map well to something we can comprehend.  I'm
having a hard time imagining weighted shares for box items being as 
straightforward.

Consider also that you can derive from the box widgets to create
your weighted box widgets.

-Shawn

On Thu, Jan 21, 1999 at 09:58:06PM -0500, Jeff Evarts wrote:
> Shawn T . Amundson wrote:
> > 
> > On Thu, Jan 21, 1999 at 08:04:33PM -0500, Jeff Evarts wrote:
> > > I'd like to be able to weight the amount of space given to
> > > children of an hbox or vbox.
> > >
> > > I can't seem to find an easy way to say "I have three
> > > expandable children in this hbox, please make sure the
> > > middle one gets 3/5 of the space, and the left and right
> > > children get 1/5 each". If there is a way to do this
> > > already, please email me and skip the rest of this document.
> > >
> > ...
> > > Well, any thoughts?
> > 
> > You do not want to use a box for this, you want to use a
> > table.  Below is an example for you.  The important part
> > is that the middle button takes up 3 columns in the table
> > and the other two only take one column each.
> > 
> >
> > [Example using table deleted]
> 
> Actually, I'm pretty sure I really don't. I should have
> said that I had tried that, but didn't like it.
> 
> My reasons are as follows:
> 
> *	First, 5 passes through the data in order to
> 	come up with a sizing situation that could
> 	easily be resolved in 2 (or even 1) is excessive.
> 
> *	I know that I won't be leaving any space unused
> 	(tables must account for this)
> 
> *	A share is a share, so I can simply divide the space
> 	and go from there, rather than finding out
> 
> 		"child foo has three vertical shares, and
> 		a fixed size allocation of one line of text.
> 		Child bar is also allocated three vertical
> 		shares, but his vertical spacing is nine
> 		pixels from the shaped window..."
> 
> 	and solving the word problem
> 
> I guess I should say "I know I *can* solve the problem with
> tables, but they have a lot of overhead".
> 
> I know it sounds contradictory to want to move some overhead
> INTO a widget to solve an overhead problem out of it, but my
> additional costs are:
> 
> 	one assignment per child created, and
> 	one multiply per child per resize.
> 
> That's not too much, compared to using a table to solve the
> same problem.
> 
> Further thoughts?
> -Jeff
> -- 
> -Jeff Evarts
> --jdeassoc@earthlink.net
> ---http://www.ecst.csuchico.edu/~amarth/
> 
> 
> -- 
>          To unsubscribe: mail gtk-devel-list-request@redhat.com with 
>                        "unsubscribe" as the Subject.
> 
--
Shawn T. Amundson               
amundson@gimp.org               http://www.gimp.org/~amundson

"The assumption that the universe looks the same in every
 direction is clearly not true in reality." - Stephen Hawking