Re: Locked accels hardcoded for GtkWindow
- From: Paul Davis <paul linuxaudiosystems com>
- To: Zveroy <zveroy gmail com>
- Cc: gtk-list gnome org
- Subject: Re: Locked accels hardcoded for GtkWindow
- Date: Wed, 7 Dec 2011 07:14:28 -0500
On Wed, Dec 7, 2011 at 3:22 AM, Zveroy <zveroy gmail com> wrote:
> /* movement keys are considered locked accels */
> if (!accel_mods)
> {
> static const guint bindings[] = {
> GDK_KEY_space, GDK_KEY_KP_Space, GDK_KEY_Return, GDK_KEY_ISO_Enter,
> GDK_KEY_KP_Enter, GDK_KEY_Up, GDK_KEY_KP_Up, GDK_KEY_Down,
> GDK_KEY_KP_Down,
> GDK_KEY_Left, GDK_KEY_KP_Left, GDK_KEY_Right, GDK_KEY_KP_Right,
> GDK_KEY_Tab, GDK_KEY_KP_Tab, GDK_KEY_ISO_Left_Tab,
> };
[ ... ]
> What the hell is this?! Anyone know workarounds?
GTK has extensive internal support for "key navigation" that allows
users to move keyboard focus and
which-widget-will-be-activated-by-default around a GUI without having
to resort to the mouse.
The keys above are all involved in this support, although Return plays
a special role - it activates the current default widget, if any. This
means that GTK prevents them from being used as accelerators.
For many GUI apps, this key navigation system is a real positive for
many users. For a few apps (like the one I work on) its generally a
liability. There are ways around it but they are complex and a bit
ugly.
I am currently thinking about a patch that makes the use of these keys
for key-nav optional at the request of the application and/or user.
Not likely to surface any time soon, though.
--p
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]