Re: BUTTON_*_MASK




Tim Janik <timj@gimp.org> writes:

> hi owen,
> 
> i just checked out the new notebook code that lars sent
> me, and i discovered a bug in the notebook menu, it didn't
> disappear if the pointer was released outside of the menu.
> after debugging some code i came across the following:
> 
> attributes.event_mask |= GDK_EXPOSURE_MASK | GDK_BUTTON_PRESS_MASK  | GDK_KEY_PRESS_MASK;
> 
> this was the event mask for widget->window in gtk_notebook_realize.
> setting this to
> 
> attributes.event_mask |= GDK_EXPOSURE_MASK | GDK_BUTTON_PRESS_MASK | GDK_BUTTON_RELEASE_MASK
>                         | GDK_KEY_PRESS_MASK;
> 
> fixed the menu bug. now i looked at some other *.c functions
> (fgrep -A1 -B1 PRESS_MASK *.c is your friend ;) i came across a few other
> locations that did unbalanced mask settings. since there is lots of code
> around that requires certain events to appear in pairs i think we should
> at least require this kind of behaviour in some kind of documentation.

[...]

> /* use these defines instead of the above discouraged masks:
>  */
> #define GDK_BUTTON_CLICK_MASK	 (GDK_BUTTON_PRESS_MASK | GDK_BUTTON_RELEASE_MASK)
> #define GDK_KEY_CLICK_MASK	 (GDK_KEY_PRESS_MASK | GDK_KEY_RELEASE_MASK)
> #define GDK_CROSSING_NOTIFY_MASK (GDK_ENTER_NOTIFY_MASK | GDK_LEAVE_NOTIFY_MASK)
> #define GDK_PROXIMITY_MASK	 (GDK_PROXIMITY_IN_MASK | GDK_PROXIMITY_OUT_MASK)

IMO, this is just a waste of network bandwith and event handling. For
key presses and proximity events, they aren't generally needed in
pairs, and won't necessarily come in pairs. (Unless the app does a
grab when the first one occurs) For button clicks, I can write
perfectly legitimate code that only looks at the presses, not the
releases. For button code, it is (always?) the entity setting up the
mask that requires the events to be paired, so I don't see any reason
to enforce this in GTK.

The only one of these which might bear changing is the enter/leave
events - since GTK does special processing of those. I'd actually
rather do it invisibly than change the way the masks work. The easiest
way to do this is in GDK :

In the event mask table, just change :

  EnterWindowMask,
  LeaveWindowMask,

to

  EnterWindowMask | LeaveWindowMask,
  EnterWindowMask | LeaveWindowMask,

Though it isn't really correct to do it in GDK, since it is a GTK
requirement, not a GDK requirement. The other thing to do would be
just to document it for widget writers, then enforce it in
gtk_widget_set_events.

Actually, I don't think there is any real harm in not having the
events paired - the LEAVE_PENDING will be left set for the widget,
but it only ever matters when LEAVE events occur for that window,
which won't happen.


So, my opinion is, that we probably don't need to do anything.
As far as I know, the rule now is very simple:

  If you want to receive BUTTON/KEY_RELEASE, PROXIMITY_OUT, LEAVE,
  events, you need to set the appropriate mask. 

This seems easy enough to get right. (The only part when it might
be difficult is when you inherit from another widget and use
your own realize function, but that problem will occur for any event
type)


Regards,
                                        Owen



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]