Re: [gtk-list] Re: RE:menu bar justification ?

[Raph Levien <raph acm org>]

On Sun, 15 Jun 1997, Shawn T Amundson wrote:

> gtkbox.h have expand and fill attributes.  Wouldn't that do what you are
> looking for?  Of course, that only applies to box children.  I haven't
> looked enough at the menu stuff to figure out if that is helpful.  Probably
> not.

gtkbox also has pack_start and pack_end, which, if adapted to the menu 
widget, would acheive the goal of right justifying the Help menu much 
more simply and cleanly than doing glue.

> This is another thing that should apply to all widgets.  (fill, expand)
> I assume this would be a difficult change?

Tedious, definitely, but not particularly difficult. Basically, what 
you're proposing is to move the fill and expand options from being 
options to the box pack routines into flags in the widgets themselves, 
and modifying all (or at least most) of the containers to implement these 
options.

The question is: what does this buy you? Certainly, it's one way to 
implement right justification in menus, but are there any other places 
where it is helpful? Considering that there are far easier ways to 
right justify menus, I don't see it as being a particularly good idea to 
implement in gtk+.

But it's still an interesting question - my current plan is to do a small 
mini-widget set for the inside of Web pages, featuring (among other 
things) completely redone size negotiation. Should this new widget set 
support glue? I haven't been planning on it, but maybe it is a good idea.

For those curious, here's what I have in mind for the new widgets:

+ Simple class and function pointer dispatch, i.e. a method call on an
object is implemented as object->klass->method (object, args). This both
easier to program and more efficient than gtk signals, but less flexible. 
I'd still use gtk signals (on the containing gtk widget) for stuff like
clicking links. ince every bullet and every table entry is going to be a
widget, it's essential to pare overhead down to the absolute minimum. 

+ Much better size negotiation, including support for wrapping widgets and
baseline alignment options. Sizes won't be limited to 32767 pixels. There
will be a scroller gtk widget that's responsible for mapping the new
widgets to a 32767 pixel window. Size negotiation will also be separated
from exposure so that non-flashing becomes a lot easier to do. 

+ Hit testing. Containers will be responsible for dispatching mouse 
events to their children. Thus, it's possible to avoid creating a new X 
window for every table entry, which would be a sure performance killer.

At first, I'd develop these widgets separately from, but compatible with, 
gtk. I don't plan to duplicate the entire gtk widget hierarchy, 
just things needed for web pages and containers like boxes and 
tables. There will be a container for gtk widgets, so I can reuse 
buttons, entries, etc. Later, it may become desirable to merge the two 
widget sets, or at least use the experience from the gzilla wedget set to 
guide the evolution of gtk.

Raph