on menu accelerators and key press handlers

[Paul Barton-Davis <pbd op net>]

i want to try to make sure i understand the mindset of the GTK API
crew when it comes to combining menu accelerators with key press
handlers. 

i've discovered (the hard way) that you don't want to have an
accelerator *and* a key press handler both handling the same key. what
happens is that (assuming the right widget has focus), the
app-provided key press handler will run first (causing <foo> to
happen). then we finish the regular gtk_handlers_run() for the
event. This returns the value of the *last* handler, which is the
default handler, and is almost certainly FALSE. then, back in
gtk_window_key_press_event(), this FALSE return causes us to then move
on and activate the accelerators, which cause the action to be
performed all over again.

i can see a couple of ways to stop this. 

  1) don't use accelerators

      * well, OK, but the key names in the menus are really handy as a
        mnemonic aid for users, even if there were no accelerators,
        and i don't see an easy way to get the same effect quite so
        easily.

  2) use gtk_signal_emit_stop_by_name() from the key press handler
        if the key press was really handled. 

      * i don't know if this will actually work, but it seems as if 
        it should

  3) don't handle the accelerator keys from within the key press handler

      * seems reasonable, i think

  4) use gtk_signal_connect_after() to override the FALSE return
        from the default handler

      * seems like a kludge

So, I want to find out what the conceptual model is for the
interaction between these two methods of handling key press events is,
so that I can "do the right thing". Thanks,

--p