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
  2. 05 Nov, 2012 1 commit
  3. 31 Oct, 2012 3 commits
  4. 29 Oct, 2012 3 commits
  5. 27 Oct, 2012 2 commits
  6. 26 Oct, 2012 3 commits
  7. 25 Oct, 2012 2 commits
  8. 24 Oct, 2012 1 commit
  9. 22 Oct, 2012 21 commits
  10. 21 Oct, 2012 1 commit
    • Matthias Clasen's avatar
      xsettings: Optimize xsettings changes · c99b272b
      Matthias Clasen authored
      I've noticed that we are updating XSettings several times during
      login, which wakes up all running GTK+ apps, and possibly makes then
      do a lot of work due to theme or font changes.
      
      This patch addresses this in two ways:
      1) Assume that gnome-shell will be running, and initialize the
         appmenu setting accordingly. This avoids a change when the shell
         comes on the bus later (g-s-d starts before the shell)
      2) Batch updates in an idle
      
      With these changes, I see XSettings getting set exactly once during
      login, which is as it should be.
      
      https://bugzilla.gnome.org/show_bug.cgi?id=686505
      c99b272b
  11. 20 Oct, 2012 1 commit
  12. 19 Oct, 2012 1 commit