Nits to pick on gtk+960925 (resend)

[raph acm org]

Hi gtk people,

   I've been working to integrate Gzilla with the latest GTK+, and
I've come across a number of problems, mostly what I'd categorize as
nits rather than serious bugs.

1. Pressing Enter in a file selection dialog does nothing.

   The Return button handling in gtk_entry has changed. In Gimp
0.99.10, it was not handled in the entry, so it would get passed up to
the window and down to the default action (pressing the Ok button),
but in gtk+970925, it does get handled in gtk_entry and throws an
activate signal.

   The fix is simple - in gtkfilesel.c:gtk_file_selection_init, hook
the activate signal (maybe a gtk_signal_connect_object, use
gtk_button_clicked as the handler, and filesel->ok_button as the
object.

2. size_request of a scrolled window is calculated wrong.

   Nobody ever uses the value of size_request of a scrolled window
because it's so damn tiny, but the code is wrong. The last assignment
to extra_width should be calculated using scrolled_window->vscrollbar
rather scrolled_window->hscrollbar.

3. expose of viewport is inefficient.

   The handling gtk_viewport_expose passes the widget event to the
child even if the expose event is in one of the viewport's own windows
rather than the child window. It's usually not a correctness problem
to expose in a window, but it still feels wrong.

   The fix is to do wrap the child even call in an if (event->window
== widget->window) test.

4. Size negotiation is fubar.

   I fear that the queued resize stuff may have made things worse. I
felt I understood the size negotiation in 0.99.10 pretty well and was
capable of working around its efficiency problems, but the cure in
970925 may be worse than the disease.

   The main problem is that widget lifecycle events can now occur
outside the order established in 0.99.10. Specifically, the widget can
be mapped and realized before it is size allocated. This is
generally an efficiency problem, because the X call sequence includes
making a dummy window during the realize, then moving it into position
during the size allocate, rather than just making it in the right
position. However, in Gzilla it caused some cosmetic problems as well,
because you could see the window move into position.

   I'm not sure what the best fix is to this problem. It's ok to leave
it as it is and take the efficiency hit, but that seems to go against
the whole point of the changes to the size negotiation. At the highest
level, I think now would be a very good idea to write down exactly
what the size negotiation methods are supposed to do, what order
they're supposed to happen in, and what invariants are supposed to be
maintained. I think this will help greatly to avoid bugs in size
negotiation, both in the GTK core and for people writing their own
container widgets, especially if there are going to be multiple people
working on it.

   To get a little more specific, what I think would work best is to
go back to the stricter order as in 0.99.10, but change the queued
resize code so that it enforces this order. Thus, the queued resize
handler should be responsible for realizing and mapping the widget
after size allocation, assuming the right conditions are met (as I
understand it, that the container and child widget are both visible,
and that the container is realized and mapped). The same code will
probably also be responsible for drawing the child widget if it's
NO_WINDOW. The responsibility to map and realize should be taken out
of container widgets like gtk_box_pack_start (as was correctly the
case in 0.99.10).

   However, I've got reasonable workarounds in Gzilla 0.1.2, so it's
not urgent. I just think this will cause more problems down the road
if it's not addressed now. I'm still having problems with the
scrollbars being out of step with the window size, but I can probably
find the problem and fix that too.

   On a personal note, I'm out of town for my father's funeral. I was
hoping to do a stable Gzilla release soon, but that may be a while
hence. If anyone wants to hack on the existing Gzilla code, let me
know and I'll post the most recent semistable source tree.

Raph