1. 24 Jul, 2014 1 commit
  2. 23 Jul, 2014 1 commit
  3. 14 Jul, 2014 6 commits
  4. 10 Jul, 2014 1 commit
  5. 08 Jul, 2014 3 commits
  6. 07 Jul, 2014 1 commit
    • Jasper St. Pierre's avatar
      window: Only update the unconstrained rect when we actually moved/resized · c2abe43e
      Jasper St. Pierre authored
      Since Wayland configures are more of a hint to the client than anything,
      we don't want to save the unconstrained rect when we're just hinting to
      the client that it should resize, since it could ignore us. This would
      get us stuck in a loop, since meta_window_move_resize_now would use the
      unconstrained_rect to resize, and we don't remove the resize from the
      queue if we have an outstanding request like that.
      This fixes a bunch of traffic / CPU usage when trying to resize
  7. 01 Jul, 2014 3 commits
  8. 27 Jun, 2014 1 commit
  9. 26 Jun, 2014 4 commits
  10. 24 Jun, 2014 4 commits
    • Florian Müllner's avatar
      window: Add user_op parameter to update_monitor() · 967b6c33
      Florian Müllner authored
      When workspaces-only-on-primary is set and a window is moved back to the
      primary, we also move it to the active workspace to avoid the confusion
      of a visible window suddenly disappearing when crossing the monitor border.
      However when the window is not actually moved by the user, preserving the
      workspace makes more sense - we already do this in some cases (e.g. when
      moving between primary monitors), but miss others (unplugging the previous
      monitor); just add an explicit user_op parameter as used elsewhere to cover
      all exceptions.
    • Florian Müllner's avatar
      window: Keep track of preferred output · 00c7a277
      Florian Müllner authored
      Remember the last monitor a window was moved to by user action and
      try to move it back on monitor changes; this should match user
      expectations much better when a monitor is unplugged temporarily.
    • Florian Müllner's avatar
      window: Don't make windows on non-primaries sticky on restart · 048ba353
      Florian Müllner authored
      When workspaces-only-on-primary is set, a window can be on all
      workspaces either because it is on a non-primary workspace, or
      because it was explicitly made sticky. Only the latter is reflected
      in _NET_WM_STATE, but both will result in a "magic" _NET_WM_DESKTOP,
      which we (and probably other WMs) use to set the initial sticky state.
      So to avoid confusing other WMs (or ourselves), make sure to only
      have _NET_WM_STATE_STICKY reflected in _NET_WM_DESKTOP when unmanaging.
    • Florian Müllner's avatar
      Revert "window: Move placement code from the constraints path" · 555e2f6d
      Florian Müllner authored
      Window state like maximization and minimization should be preserved
      over restarts - in a patch review, this would qualify as "needs-work",
      so revert the cleanup until the issues are fixed.
      This reverts commit dc6decef.
  11. 17 Jun, 2014 3 commits
    • Jasper St. Pierre's avatar
      window: Move placement code from the constraints path · dc6decef
      Jasper St. Pierre authored
      This way, it's implemented as a special case in move_resize_internal,
      which makes it a lot easier to manage.
    • Jasper St. Pierre's avatar
      window: Save the buffer_rect internally · b0b8f372
      Jasper St. Pierre authored
      Rather than calculate it speculatively with the current properties
      which may be too new or too out of date, make sure it always fits
      with the proper definition. We update it when we update the toplevel
      window for X11, and when a Wayland surface is committed with a newly
      attached buffer.
    • Jasper St. Pierre's avatar
      window: Rename get_input_rect to get_buffer_rect · 188e4e1b
      Jasper St. Pierre authored
      With get_input_region existing, get_input_rect is a misnomer. Really,
      it's about the geometry of the output surface, and it's only used that
      way in the compositor code.
      Way back when in GNOME 3.2, get_input_rect was added when we added
      invisible borders. get_outer_rect was always synonymous with server-side
      geometry of the toplevel. get_outer_rect was used for both user-side
      policy (the "frame rect") and to get the geometry of the window.
      Invisible borders were meant to extend the input region of the frame
      window silently. Since most users of get_outer_rect cared about the
      frame rect, we kept that the same and added a new method, get_input_rect
      to get the full rect of the framed window with all invisible borders for
      input kept on.
      As time went on and CSD and Wayland became a reality, the relationship
      between the server-side geometry and the "frame rect" became more
      complicated, as can be evidenced by the recent commits. Since clients
      don't tend to be framed anymore, they set their own input region.
      get_buffer_rect is also sort of a poor name, since X11 doesn't really
      have buffers, but we don't really have many other alternatives.
      This doesn't change any of the code, nor the meaning. It will always
      refer to the rectangle where the toplevel should be placed.
  12. 16 Jun, 2014 2 commits
    • Jasper St. Pierre's avatar
      window: Fix get_input_rect in a hacky way · 9d5273bb
      Jasper St. Pierre authored
      All of the users of get_input_rect don't actually want a synthesized
      input rect based off of the current margins. What they really want is
      the last-configured size of the toplevel window.
      Since we don't properly track this anymore in the generic MetaWindow,
      use XGetWindowAttributes to fetch a server-side rectangle. This is a
      bad layer violation, but since the window geometry code will have to
      be rewritten anyway for the Wayland set_window_geometry, let's just
      push a hacky fix for now.
    • Jasper St. Pierre's avatar
  13. 12 Jun, 2014 2 commits
  14. 02 Jun, 2014 2 commits
    • 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.
    • Jasper St. Pierre's avatar
      window: Make sure not to respond to input events on OR windows · 53425fa7
      Jasper St. Pierre authored
      This can happen since we select for events on the root window, and
      clients themselves might not select for input, meaning the X server
      will bubble up. Just do nothing and ignore the event in this case.
      This should hopefully fix some of the
      Window manager warning: Log level 8: meta_window_raise: assertion '!window->override_redirect' failed
      Window manager warning: Log level 8: meta_window_focus: assertion '!window->override_redirect' failed
      spam that people have been seeing.
  15. 29 May, 2014 1 commit
    • Jasper St. Pierre's avatar
      window: Fix placement not actually placing windows · b32c837d
      Jasper St. Pierre authored
      Since we often call meta_window_move_resize_now immediately after
      mapping a window, we need to make sure that the placed coordinates
      are saved in the unconstrained_rect. Ideally, placement positions
      wouldn't be part of the constraints system, but instead are just
      done inside meta_window_move_resize_internal as part of a special
      We're still working out the kinks of one large-scale refactor, so
      it's best not to do another one while the first is going on. This
      would be a great future cleanup, though: untangling constraints
      and placement, alongside the force_placement state machine and
  16. 28 May, 2014 2 commits
  17. 27 May, 2014 3 commits
    • Jasper St. Pierre's avatar
      window: Refactor all move/resize operations to be in frame rect space · 6e06648f
      Jasper St. Pierre authored
      For Wayland, we want to have everything possible in terms of the frame
      rect, or "window geometry" as the Wayland protocol calls it, in order
      to properly eliminate some flashing when changing states to fullscreen
      or similar.
      For this, we need to heavily refactor how the code is structured, and
      make it so that meta_window_move_resize_internal is specified in terms
      of the frame rect coordinate space, and transforming all entry points
      to meta_window_move_resize_internal.
      This is a big commit that's hard to tear apart. I tried to split it
      as best I can, but there's still just a large amount of changes that
      need to happen at once.
      Expect some regressions from this. Sorry for any temporary regression
      that this might cause.
    • Jasper St. Pierre's avatar
      window: Correct the anchoring of drag moving / resizing · 4acb9024
      Jasper St. Pierre authored
      Now that meta_window_move_resize and friends act in frame rect
      coordinates, we need to convert the initial grab_anchor_window_pos
      storage to be in frame rect coordinates as well.
    • Jasper St. Pierre's avatar
      window: Remove meta_window_move as well · 626516d1
      Jasper St. Pierre authored
      Move to meta_window_move_frame everywhere...