[Bug 56070] Can't click button after setting it sensitive.

[gtk+ (bugzilla.gnome.org)]

Do not reply to this via email (we are currently unable to handle email
responses and they get discarded).  You can add comments to this bug at
http://bugzilla.gnome.org/show_bug.cgi?id=56070

  gtk+ | gtk | Ver: 2.6.x


Owen Taylor changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |otaylor at redhat.com




------- Comment #73 from Owen Taylor  2007-01-07 04:53 UTC -------
Hmm, in one sense, I like the patch a lot ... the approach of sending
enters/leave is is much better than GtkButton querying the pointer when it's
sensitivity is changed or something.

But I have some reservations as well:

 - Crossing events are not a widget thing (despite the current LEAVE_PENDING 
   flag), but rather a GdkWindow thing. If you try to track the enter/leave 
   state per widget, then you have problems with widgets with multiple windows.

 - I forsee problems from ignoring the detail field of the crossing event. The 
   detail field is important if you, for example, want to distinguish the 
   pointer being in a window or any descendent from the pointer being in 
   the window itself. Sending events with a detail of NOTIFY_UNKNOWN basically
   means that any such tracking is a lost cause.

 - I don't like the way, in your patch, that 
    gtk_widget_synthesize_crossing_from_grab_notify
    gtk_widget_synthesize_crossing_from_state_changed
   are made public and then GtkButton calls them. That seems to me like
   confusion over this is something maintained by the core widget system
   or by widgets. What we really want to do is make any tricky invariants
   handled by the core widget system, and remove hacks from the widgets.

   Really, if the generation of synthetic crossing events is handled properly,
   we should be able to remove the setting of button->in_button() from
   gtk_button_state_changed() and gtk_button_grab_notify().

 - Should GTK_LEAVE_PENDING be removed? The purpose of it overlaps entirely
   with this patch, though it only handles the LEAVE side, not the ENTER side.

Without working through all the details, the way I would have approached this
issue is to track two "pointer windows" for each toplevel. The real pointer
window is defined by the events delivered by X. (If crossing events aren't
selected for a window, then it can never be the real pointer window.) The
effective pointer window is:

 - The root window, if the widget that owns the real pointer window is
   insenstive, or if there is a grab widget that is not an ancestor of
   the real pointer window's widget.

 - The real pointer window otherwise.

When the effective pointer window changes for a reason other than an
event delivered from the window system, that's when we synthesize crossing
events... we deliver all the crossing events that are defined by the
X protocol spec ... so this well generally include "VIRTUAL" enters and
leaves on the ancestor windows of the real pointer window. If you don't
sent those VIRTUAL events, then the accounting won't work right in complex
situations, where children are made insensitive, parents are made insensitive,
the pointer is moved, widgets are made sensitive again ... things like that.

I know that sounds like a lot more complex than what you have now ... probably
not more code, but maybe trickier code. And after all those patch 
iterations too! But we have to keep the events that get generated well
defined or it's basically impossible to know what to expect. And since
the existing GTK+ system (complexity layered on top of complexity inherited
from X) is complex, it's hard to make changes to it that are simple.


-- 
Configure bugmail: http://bugzilla.gnome.org/userprefs.cgi?tab=email