1. 24 Jul, 2014 1 commit
  2. 23 Jul, 2014 1 commit
  3. 19 Jul, 2014 1 commit
  4. 16 Jul, 2014 1 commit
  5. 15 Jul, 2014 1 commit
  6. 10 Jul, 2014 2 commits
  7. 07 Jul, 2014 1 commit
  8. 01 Jul, 2014 1 commit
  9. 27 Jun, 2014 1 commit
  10. 17 Jun, 2014 1 commit
  11. 02 Jun, 2014 1 commit
    • Florian Müllner's avatar
      Pass button_rect when opening window menu from button · b64548ee
      Florian Müllner authored
      When opening the window menu without an associated control - e.g.
      by right-clicking the titlebar or by keyboard - using coordinates
      for the menu position is appropriate. However when the menu is
      associated with a window button, the expected behavior in the
      shell can be implemented much easier with the full button geometry:
      the menu will point to the center of the button's bottom edge
      rather than align to the left/right side of the titlebar as it
      does now, and the clickable area where a release event does not
      dismiss the menu will match the actual clickable area in mutter.
      
      So add an additional show_window_menu_for_rect() function and
      use it when opening the menu from a button.
      
      https://bugzilla.gnome.org/show_bug.cgi?id=731058
      b64548ee
  12. 28 May, 2014 1 commit
  13. 27 May, 2014 1 commit
  14. 22 May, 2014 1 commit
    • Jasper St. Pierre's avatar
      Add back coordinates to the window menu · 6513cbb4
      Jasper St. Pierre authored
      It looks weird to have Alt+Space pop up under the cursor instead
      of the top-left corner of the window, and the Wayland request will
      pass through the coordinates as well.
      
      Add it to the compositor interface, and extend the
      _GTK_SHOW_WINDOW_MENU ClientMessage to support it as well.
      6513cbb4
  15. 17 May, 2014 1 commit
  16. 02 May, 2014 1 commit
  17. 24 Apr, 2014 3 commits
  18. 23 Apr, 2014 4 commits
  19. 22 Apr, 2014 2 commits
  20. 07 Apr, 2014 1 commit
  21. 27 Mar, 2014 2 commits
  22. 26 Mar, 2014 3 commits
    • Jasper St. Pierre's avatar
      compositor: Kill off MetaCompScreen · cd905a34
      Jasper St. Pierre authored
      Compositors haven't been able to manage more than one screen for
      quite a while. Merge MetaCompScreen into MetaCompositor, and update
      the API to match.
      
      We still keep MetaScreen in the public compositor API for compatibility
      purposes.
      cd905a34
    • 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
  23. 20 Mar, 2014 4 commits
  24. 19 Mar, 2014 2 commits
  25. 18 Mar, 2014 2 commits