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
  2. 26 Oct, 2012 1 commit
  3. 25 Oct, 2012 1 commit
  4. 22 Oct, 2012 2 commits
  5. 15 Oct, 2012 1 commit
  6. 05 Oct, 2012 5 commits
  7. 23 Sep, 2012 1 commit
  8. 22 Sep, 2012 2 commits
  9. 17 Sep, 2012 3 commits
  10. 14 Sep, 2012 1 commit
  11. 13 Sep, 2012 4 commits
  12. 03 Sep, 2012 1 commit
  13. 29 Aug, 2012 1 commit
  14. 20 Aug, 2012 1 commit
  15. 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.
    • 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...
  16. 14 Jun, 2012 2 commits
  17. 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).
  18. 17 May, 2012 3 commits
  19. 09 May, 2012 1 commit
  20. 26 Apr, 2012 6 commits