Skip to content

GitLab

Switch branch/tag
  1. 06 Nov, 2012 1 commit
    • Bastien Nocera's avatar
      keyboard: Prevent potential infinite loop · 15baf341
      Bastien Nocera authored 
      XKB would notify us in the same way if the lockedMods
changed because of a programmatic, or a physical/human change.

This causes us changing the Num-Lock state generating another
event on top of the one we just processed, and might cause
infinite loops and 100% CPU usage.

Instead, we now only apply the settings:
- on startup
- when remember-num-lock is changed to true

https://bugzilla.gnome.org/show_bug.cgi?id=679151
      15baf341
  3. 26 Oct, 2012 1 commit
  5. 25 Oct, 2012 1 commit
  7. 22 Oct, 2012 2 commits
  9. 15 Oct, 2012 1 commit
  11. 05 Oct, 2012 5 commits
  13. 23 Sep, 2012 1 commit
  15. 22 Sep, 2012 2 commits
  17. 17 Sep, 2012 3 commits
  19. 14 Sep, 2012 1 commit
  21. 13 Sep, 2012 4 commits
  23. 03 Sep, 2012 1 commit
  25. 29 Aug, 2012 1 commit
  27. 20 Aug, 2012 1 commit
  29. 13 Jul, 2012 2 commits
    • Rui Matos's avatar
      keyboard: Use GSettings::change-event to cut on needless work · 207d0ef3
      Rui Matos authored 
      Since we end up always doing the same amount of work for in input
sources settings we might as well save some when several keys change
in bulk.

https://bugzilla.gnome.org/show_bug.cgi?id=676102
      207d0ef3
    • Rui Matos's avatar
      keyboard: Add functionality to set IBus engines from input sources · 557bfce8
      Rui Matos authored 
      We connect to IBus and tell it to switch engine when the current input
source setting is changed and an IBus engine is specified there.

If an IBus engine is specified, we flip the setting that backs the
Gtk/IMModule XSETTING so that GTK+ applications get notified to load
the IBus input method when needed and go back to the simple input
method when IBus isn't required.

The ibus-daemon claims a well known name in the session bus but
doesn't ship a .service file to make it activatable so we ship one
ourselves which will spawn it in a convenient way for us. In
particular, we disable its 'panel' component since that functionality
is provided by gnome-shell and would conflict at run time. We also
tell it to replace an existing ibus-daemon since traditionally it
would be spawned at session init time before even DBus was up and out
of control of gnome-session so, in case that happens, our own spawned
version will take place which is what we inte...
      557bfce8
  31. 14 Jun, 2012 2 commits
  33. 01 Jun, 2012 1 commit
    • Rui Matos's avatar
      keyboard: Apply XKB layouts ourselves and stop relying on libgnomekbd · b6e011ad
      Rui Matos authored and Bastien Nocera's avatar Bastien Nocera committed 
      libgnomekbd/xklavier aren't a good fit to have the keyboard input
story that we want since they rely on implementation details of the
XKB protocol to provide users with a means to switch keyboard layouts.

Of note here is a) their reliance on XKB groups, of which there can be
only up to 4, to specify the layouts the user is able to switch
between and b) their reliance on XKB options to specify the keybinding
to switch layouts which is a restricted set and falls outside the
regular GNOME desktop wide keybindings management as it's implemented
entirely on the X server side.

This commit introduces the use of a shared GSettings schema from
gsettings-desktop-schemas which will be the storage for our new
concept of "input sources".

We only handle XKB layouts as input sources for now. We do it using
roughly the same method that setxkbmap(1) uses which should allow the
users that want to specify their own XKB features (except layout) to
still do so outside of GNOME (e.g. in a session startup script).

https://bugzilla.gnome.org/show_bug.cgi?id=676102
      b6e011ad
  35. 17 May, 2012 3 commits
  37. 09 May, 2012 1 commit
  39. 26 Apr, 2012 6 commits