After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 107000 - Add signals to GdkKeymap for monitoring caps_lock, etc.
Add signals to GdkKeymap for monitoring caps_lock, etc.
Status: RESOLVED FIXED
Product: gtk+
Classification: Platform
Component: Backend: X11
2.2.x
Other Linux
: Normal enhancement
: Small API
Assigned To: gtk-bugs
gtk-bugs
Depends on:
Blocks:
 
 
Reported: 2003-02-25 00:41 UTC by Owen Taylor
Modified: 2008-09-29 20:41 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
untested patch (6.38 KB, patch)
2006-02-13 07:09 UTC, Matthias Clasen
none Details | Review
working patch (9.30 KB, patch)
2006-02-13 15:02 UTC, Matthias Clasen
needs-work Details | Review

Description Owen Taylor 2003-02-25 00:41:28 UTC
For a password entry, it's useful to be able to track
whether caps lock is down... we should be able to
allow this without cluttering the API with too
much bloat.
Comment 1 Matthias Clasen 2006-02-13 07:09:38 UTC
Created attachment 59236 [details] [review]
untested patch
Comment 2 Matthias Clasen 2006-02-13 15:02:10 UTC
Created attachment 59264 [details] [review]
working patch

This patch works for me. Note that
- I haven't tested the group switch modifier
- I have made no attempt to handle the non-XKB case
- The API is currently restricted to Caps Lock, Num Lock and Group Switch.
  Do we need to support more of the excessive genericity of XKB ?
Comment 3 Owen Taylor 2006-02-14 14:08:50 UTC
- Hmm, group_switch seems less useful to me than scroll_lock.
  (Not that scroll_lock is that useful...)

- The three-outs interface makes me twitchy as inflexible.
  Not that we *really* are likely to want to change it in
  the future, but who knows...

  What if you just had:

   guint gdk_keymap_get_locked_keys(keymap)

  And left it fuzzy as to exactly what keys might be reported
  there?

  (You could even include the old state in the signal
  like GtkWidget::direction-changed, or do it like 
  GdkWindowStateEvent; quite possibly both are just extra
  useless complexity.)

 - The XKB code looks plausible to me, without digging out the
   spec.

 - In terms of X-without-XKB and Windows, my suggested method
   would be

   1. Query the state on focus in (this really wants gdkasync.c
      action, but for legacy systems, it's probably not worth it.)

   2. Check the state on each received key press or release.

   I don't know how to get active notification on windows without
   adding a global hook on WM_KEYDOWN, which is almost certainly
   a bad idea. (You need a separate DLL that communicates with
   GTK+, unless you want to load the GTK+ DLL into every application
   on the system...)




 - 
Comment 4 Matthias Clasen 2006-02-14 14:17:53 UTC
What does gdk_keymap_get_locked_keys(keymap) return,  a single keyval ?
Or is it rather gdk_keymap_get_locked_modifiers(keymap) and returns modifier
masks ored together ? The problem with that is that we don't have a fixed
modifier bit for num lock, group switch or scroll lock, I think.
Comment 5 Matthias Clasen 2008-09-29 20:41:34 UTC
For now I've decided to only add a simple getter for caps lock status, since
that is what I need for capslock warning in password entries.

2008-09-29  Matthias Clasen  <mclasen@redhat.com>

        Bug 107000 – Add signals to GdkKeymap for monitoring caps_lock, etc.

        * gdk/gdk.symbols:
        * gdk/gdkkeys.[ch]: Add a new GdkKeymap::state-changed signal, and
        a gdk_keymap_get_caps_lock_state function.

        * gdk/x11/gdkkeys-x11.c: Implement it here. For now, only emit
        state-changed when caps lock lockedness changes.

        * gdk/x11/gdkdisplay-x11.c: Also select for modifier lock status
        changes in the XkbSelectEventDetails call.