Re: [gtk-list] [patch] gtkmenu.c, gtkentry.c

[Raph Levien <raph acm org>]

The gtkmenu.c patch still holds, but please disregard the gtkentry.c 
patch. I found a different solution to the problem, which is now 
incorporated into gzilla 0.06. Forms work pretty well now, although 
passwords, imagemaps, and POST methods are not yet supported.

If any of you are curious about the guts of gtk's mouse handling code, 
here's what the problem was. The gtk_page widget, unlike all of the 
containers shipped with gtk, itself handles mouse input. Embedded widgets 
have the option of saying they handled the mouse event (by returning 
TRUE) or having it passed up to its parent (by returning FALSE). One 
place where this mechanism is heavily used is in lists and list items. A 
button press in a list item has an effect: to grab the focus. However, it 
must also get passed up to the list containing it so all the selection 
can happen.

What was happening is that some widgets (including entries, scrollbars, 
and lists) were returning FALSE, so the events were coming back up to 
gtk_page. To make matters worse, gtk_page_button_press did a grab, so 
there were _two_ widgets trying to grab the mouse. This doesn't work.

The fix turned out to be quite simple: check the event window against the 
gtk_page window. If they don't match, ignore the event. This enforces the 
heuristic that non-NO_WINDOW widgets get their own mouse events, while 
NO_WINDOW widgets get their events handled by gtk_page (this is how 
images inside <a href> tags are handled). Seems reasonale.

There are still some minor glitches. For example, the gtk_list widget 
never does a grab, so if you click inside the list and then drag to 
another widget (for example, an entry), the second widget will see the 
motion_notify events. This is a bug in gtk (you can duplicate it in any 
container widget, not just gtk_page), but should be a pretty low priority.

That's probably more than anyone wanted to know, but I figured I would 
share what I learned. Sorry about all the ineffective patches.

I still haven't figured out how to fix the prelight problem in buttons. 
The problem is that the state change functions are happening inside the 
button_clicked method, which is in turn getting called in 
gtk_real_button_release, which mixes in other set_state operations. The 
easy solution would be to delay the state change into an idle function, 
but I think it would be nicer if a signal handler hooked into 
gtk_button_clicked could just do a state change and have things work.

Raph

P.S. What happened to gimp-developers? I haven't seen any traffic since 8 
June. Is it just me?