[ patch ] Paned window widgets.

[Owen Taylor <owt1 cornell edu>]

Jay Painter <jay@a42.com> writes:

> * I have a list of messages in a scrolling window, and a text window
> directly under it.  I would like to be able to re-proportion the sizes  
> of the two windows by a click/drag somewhere between them.

You may be in luck with this ... I just finished a set of paned window
widgets, so if you can get them to work, they might be what you are 
looking for.

The patches are available as a unified diff at 

   http://www.msc.cornell.edu/~otaylor/paned-patch.gz

Because they come out of a very messy source tree, they probably won't
patch completely cleanly, but the parts that are most likely to mess
up are "obvious" changes to gtk.h and gtk/Makefile.am. (Which reminds
me, you'll need automake to install this properly, but you can almost
certainly get away with hacking your Makefile.)

I've included both another example in testgtk.c and texinfo
documentation for these widgets (and as a bonus, texinfo documentation
for my AspectFrame widget), so they shouldn't be too hard to figure
out. I'm receptive to any suggestions and bug fixes....

The process of sorting these out from bug fixes, i18N stuff, and my
own XInput stuff would certainly inspire me to start fulminating for
CVS or something, if I wasn't convinced that our Moses will shortly
reappear and lead us to the promised land (?). But maybe we should
consider delegating someone to mantain a unofficial tree of less
conservative changes, and let the higher-ups attend to stabilizing
things for the GIMP 1.0 ... 

> * In the message index, which is a gtk_list (actually 3 with the mouse
> click events linked together), I would like to designate a different
> action for each mouse button pressed.  Specifically, I'd like a popup menu
> of mail folders to come up (for moving mail messages) bound to the right
> button.  I think this could be solved by inheriting the gtk_list and then
> overriding the mouse event and adding a new signal; however, I'm not
> farmiliar with GTK's object/class emulation to be sure this would work
> that easily.

As far as I can see there shouldn't be a problem just writing your own
button_press_event signal handler to add your behavior. (letting the
default handler take effect afterwards for the left button, but
calling gtk_signal_emit_stop_by_name to halt processessing in the
right button case.) Should be easier than writing a whole new widget.

 Regards,
					 Owen