Response on key press handling
- From: Owen Taylor <otaylor redhat com>
- To: timj gtk org, gtk-devel-list gtk org
- Subject: Response on key press handling
- Date: Sun, 29 Feb 2004 20:35:18 -0500
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
[Date Prev][
Date Next] [Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]