Response on key press handling

[Owen Taylor <otaylor redhat com>]

Reference:
http://mail.gnome.org/archives/gtk-devel-list/2003-December/msg00186.html
and followups.

I really don't think that making unmodified key presses behave
different than modified key presses is a good idea. 

 * It adds a further complexity and uncertainty to the already
   complex key handling forwarding around that we have now. It's not
   quite different processing only on Tuesdays, but it's getting 
   close.

 * I really don't see a distinction between this and the
   input method situation; while you may consider that typing
   'a' is an obvious key that must go first to the current
   input widget, a Japanese user will think that typing
   'Control-space' is an obvious key that must go first 
   to the current input widget. 

   We have to solve the input method issue at some point; if
   we do something here for this, and then something different
   for that, then we've not just added one extra wrinkle
   of complexity to our system, we've added *two* wrinkles.

My comment about Plug/Socket wasn't one about implementation; 
rather, the precedence of accelerators is part of XEMBED
protocol. Accelerators are handled first, then the
key is sent to the client; it doesn't come back.

I'm OK with exporting gtk_window_activate_key(); I don't really
think that overriding the default window key press handler
is a wonderful idea, but it doesn't do any real harm to allow
it. Someone who wants non-standard key-press handling can do
it easily enough currently with a ::key-press-event 
signal handler, as you point out.

So, I'm going ahead and doing that:

Sun Feb 29 20:34:06 2004  Owen Taylor  <otaylor redhat com>      
                                                                                                               
        * gtk/gtkwindow.[ch] gtk/gtkmenu.c: export
        gtk_window_activate_key() (Request from Tim Janik)

Regards,
					Owen