Re: volunteer needed: event return values

[Tim Janik <timj gtk org>]

On 19 Feb 2001, Owen Taylor wrote:

> srlytle_list yahoo com writes:

> Of the signals you listed, 
> 
> > GtkWidget::button-press-event
> > GtkWidget::button-release-event
> > GtkWidget::key-press-event
> > GtkWidget::key-release-event
> > GtkWidget::drag-motion
> > GtkWidget::drag-drop
> > GtkWidget::delete-event
> > GtkWidget::selection-request-event
> > GtkWidget::selection-notify-event
> > GtkWidget::client-event
> 
> Are basically actions, and should typically have a single
> handler. [ Though selection-request and selection-notify
> are horribly internal, and never should have been signals ]

not neccessarily a single handler, which is why the return
values matter so much here.

> These are the signals you should concentrate on.
> 
> > GtkWidget::map-event
> > GtkWidget::unmap-event
> > GtkWidget::enter-notify-event
> > GtkWidget::leave-notify-event
> > GtkWidget::focus-in-event
> > GtkWidget::focus-out-event
> > GtkWidget::motion-notify-event
> > GtkWidget::visibility-notify-event
> > GtkWidget::destroy-event
> > GtkWidget::configure-event
> > GtkWidget::property-notify-event
> > GtkWidget::selection-clear-event
> > GtkWidget::proximity-in-event
> > GtkWidget::proximity-out-event
> 
> These however, are mostly notifications of state changes. There is no
> reason why multiple entities shouldn't get notified of state changes.
> Thus, there handlers should typically return FALSE, regardless
> if they take note of the event.
> 
> (There is even some question whether these signals should
> have the TRUE-stops-emit behavior, though it may be less
> confusing if they do.)

i don't think so (now, spent some thoughts on this).
for a start, i'd like to introduce return-TRUE-stops-emit only
for a _very_ defined set of signals. i think a good definition
for now would be:
1) only GtkWidget::*-event signals introduce TRUE-stops-emission behaviour
2) of those widget event signals, the ones introducing it are:
    GtkWidget::button-press-event
    GtkWidget::button-release-event
    GtkWidget::key-press-event
    GtkWidget::key-release-event
    GtkWidget::drag-motion
    GtkWidget::drag-drop
    GtkWidget::delete-event
    GtkWidget::selection-request-event
    GtkWidget::selection-notify-event
    GtkWidget::client-event
   i.e. the ones you listed as "action" events, plus GtkWidget::event.
   
lemme make clear that i'm not implying we shouldn't fix the return
values of the other signals as well, i'd just like to apply the
new behaviour to a restricted set of signals until it got some
major testing with third-party apps, since i suspect the potential
for breakage to be much higher for non-action signals where people
usually care less about return values.

> Actually, my feeling is that expose event handlers should just
> categorically return FALSE.

just expose handlers? not even all "notification" events in general?

> > for things like key_press/etc, it seems a lot simpler.
> 
> These are the things I'm worried about. 
> 
> I'm sure I've muddied the water a lot with this mail - made
> this a less clear task. Don't hestitate to ask more questions
> if you need help figuring things out.

your email is a good start to form a doc section on event signals
and also propagation. with the new behaviour, such a section will
be much needed to reduce confusion on the user side.

> 
> Regards,
>                                         Owen
>     

---
ciaoTJ