Re: Events delivered to not-viewable windows

[Owen Taylor <otaylor redhat com>]

On Fri, 2003-06-06 at 14:06, Owen Taylor wrote:

> On Fri, 2003-06-06 at 12:03, Tim Janik wrote:
> > there's one last thing i'm worried about wrg your patch. that's
> > delivery of "paired" events like button releases or focus-out.
> > with your patch, a second such event that might be connected to a
> > handler which "cleans up" stuff will be ignored.
> > i guess for most cases you'll want to tell people to guard their
> > code against not getting the second event (though that is really
> > mnasty to take care of in times). 
> 
> Ugh, you are right - the second event really should be delivered
> because it is conceptually tied to the first event, which was
> delivered. Widgets that depend on paired button-press/leave already
> do need to do some special handling - they have to stop expecting
> the second event when the widget:
> 
>  - becomes insensitive
>  - becomes grab-shadowed
>  - becomes unrealized
> 
> But I don't like adding yet another condition to track (and one
> which is actually almost impossible to track currently, since there
> is no notification on the idea of viewability we are using.)
> 
> Simplest hack - simply omit the check for BUTTON_RELEASE,
> KEY_RELEASE (not guaranteed to be paired, but probably nicer
> to preserve when possible), LEAVE_NOTIFY, PROXIMITY_OUT.
> 
> That would be my preferred solution, I think, rather than anything
> more complicated.

Addendum on this - of course, BUTTON_RELEASE isn't guaranteed to 
be paired either, if the window where the button was pressed
is hidden.

You can produce a bug pretty trivially in GtkButton, GtkTextView,
and probably just about every other widget if you switch notebook
pages with the keyboard (Control-Alt-PageUp/PageDown) while dragging
in that widget. So, LEAVE is the only one where pairing is 
guaranteed.

What might be best is to in HEAD introduce notifications for:
 
 - Lost X grab (you can also get stuck selections from menu
   popups, etc.)

 - Viewability change (we need the logic anyways to implement
   Lost X grab) 

Though that brings up the question:

 Do we continue adding GDK event types, or do we do all new
 notifications as signals on GDK objects?

And the other question:

 Should there be some generic "loss of event control" signal
 at the widget level to over all the different cases that 
 a widget needs to worry about.

For now, I think I'll exempt the paired events, and we can consider
adding them in once we have a more general solution.

Regards,
                                            Owen