1. 24 Jul, 2014 2 commits
  2. 16 Jul, 2014 1 commit
    • Owen W. Taylor's avatar
      Add a framework for restarting the compositor with nice visuals · 3a57f843
      Owen W. Taylor authored
      The current GNOME Shell Alt-F2 restart looks very messy and also
      provides no indication to the user what is going on. We need to
      restart the compositor to switch in and out of stereo mode, so
      add a framework for doing this more cleanly:
      
      Additions:
      
       meta_restart(): restarts the compositor with a message
       MetaDisplay::show-restart-message: signal the embedding
          shell to show a message
       MetaDisplay::restart: signal the embedding shell to restart
          itself.
       meta_is_restart(): indicates whether the current instance is a
                          restart so we can suppress login animations.
      
      A helper program meta-restart-helper holds the composite overlay
      window up during the restart to avoid visual artifacts.
      
      https://bugzilla.gnome.org/show_bug.cgi?id=733026
      3a57f843
  3. 11 Jul, 2014 1 commit
  4. 08 Jul, 2014 3 commits
  5. 12 Jun, 2014 1 commit
  6. 20 May, 2014 1 commit
    • Jasper St. Pierre's avatar
      Rework timestamp pinging · 4053c92a
      Jasper St. Pierre authored
      If a window temporarily goes unresponsive, and then returns later, we
      should hide the kill dialog that we showed to the user.
      4053c92a
  7. 17 May, 2014 1 commit
  8. 14 May, 2014 1 commit
  9. 02 May, 2014 1 commit
  10. 29 Apr, 2014 1 commit
  11. 24 Apr, 2014 2 commits
  12. 23 Apr, 2014 2 commits
  13. 22 Apr, 2014 2 commits
  14. 20 Apr, 2014 4 commits
  15. 12 Apr, 2014 1 commit
    • Jasper St. Pierre's avatar
      display: Rename grab_op_is_wayland to grab_op_should_block_wayland · 30d534f1
      Jasper St. Pierre authored
      The idea here is that while we take a WM-side grab, like a compositor
      grab or a resizing grab, we need to remove the focus from the Wayland
      client.
      
      We make a special exception for CLICKING operations, because these
      are really an internal state machine while you're pressing on a button
      inside a frame, and in this case, we need to not kill the focus.
      30d534f1
  16. 07 Apr, 2014 5 commits
  17. 26 Mar, 2014 2 commits
    • Jasper St. Pierre's avatar
      display: Kill off grab_screen · 47aa5836
      Jasper St. Pierre authored
      Just like active_screen, the screen can always be inferred
      from the MetaDisplay, so there's no point in keeping it around.
      47aa5836
    • Jasper St. Pierre's avatar
      Remove any possibility for zaphod mode · d7519f4e
      Jasper St. Pierre authored
      We previously separated out MetaDisplay and MetaScreen. mutter
      would only manage one screen, but we still kept a list of screens
      for simplicity.
      
      With Wayland support, we no longer care about the ability to
      manage more than one screen at a time. Remove this by killing
      the list of screens, in favor of having just one MetaScreen
      in MetaDisplay.
      
      We also kill off active_screen at the same time, since it's
      not necessary anymore.
      
      A future cleanup should merge MetaDisplay and MetaScreen. To avoid
      breaking API, we should probably keep MetaScreen around as a dummy
      type.
      d7519f4e
  18. 20 Mar, 2014 5 commits
  19. 04 Mar, 2014 2 commits
    • Rui Matos's avatar
      keybindings: Keep keybindings in an hash table instead of an array · 46af3ef9
      Rui Matos authored
      This allows us to look for a match with an O(1) search instead of O(n)
      which is nice, particularly when running as a wayland compositor in
      which case we have to do this search for every key press event (as
      opposed to only when our passive grab triggers in the X compositor
      case).
      
      We actually need two hash tables. On one we keep all the keybindings
      themselves which allows us to add external grabs without constantly
      re-allocating the array we were using previously.
      
      The other hash table is an index of the keybindings in the first table
      by their keycodes and mask which is how we actually match the key
      press events. This second table thus needs to be rebuilt when the
      keymap changes since keycodes have to be resolved then but since we're
      only keeping pointers to the first table it's a fast operation.
      
      https://bugzilla.gnome.org/show_bug.cgi?id=725588
      46af3ef9
    • Rui Matos's avatar
      keybindings: Keep keybindings in an hash table instead of an array · 7e8833a2
      Rui Matos authored
      This allows us to look for a match with an O(1) search instead of O(n)
      which is nice, particularly when running as a wayland compositor in
      which case we have to do this search for every key press event (as
      opposed to only when our passive grab triggers in the X compositor
      case).
      
      We actually need two hash tables. On one we keep all the keybindings
      themselves which allows us to add external grabs without constantly
      re-allocating the array we were using previously.
      
      The other hash table is an index of the keybindings in the first table
      by their keycodes and mask which is how we actually match the key
      press events. This second table thus needs to be rebuilt when the
      keymap changes since keycodes have to be resolved then but since we're
      only keeping pointers to the first table it's a fast operation.
      
      https://bugzilla.gnome.org/show_bug.cgi?id=725588
      7e8833a2
  20. 27 Feb, 2014 1 commit
    • Giovanni Campagna's avatar
      display: clean up event handling · 5c99eae8
      Giovanni Campagna authored
      The only events we handle as XIEvents are FocusIn/Out, Enter and
      Leave.  Motion, ButtonPress/Release, KeyPress/Release are handled
      through clutter instead.
      Among other things, this means we don't need to fake motion compression
      by peeking over gdk event queue...
      5c99eae8
  21. 23 Feb, 2014 1 commit