1. 14 Jul, 2014 2 commits
  2. 10 Jul, 2014 4 commits
  3. 27 Jun, 2014 1 commit
  4. 24 Jun, 2014 1 commit
    • 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.
  5. 17 Jun, 2014 2 commits
  6. 16 Jun, 2014 1 commit
  7. 09 Jun, 2014 1 commit
  8. 07 Jun, 2014 1 commit
  9. 03 Jun, 2014 2 commits
    • Jasper St. Pierre's avatar
      window-x11: Don't ever send ConfigureNotifies for OR windows · e3622275
      Jasper St. Pierre authored
      There's a race here. If an OR window hides itself, moves, and then shows
      itself, we will send a ConfigureNotify for the old size of the window
      and might receive it after the client moves itself, causing us to show
      the window at the wrong location.
      Simply not sending the ConfigureNotify is the easiest thing to do.
    • Jasper St. Pierre's avatar
      window: Make sure to update client_rect for OR windows too · da311f26
      Jasper St. Pierre authored
      Before we unmanage, we send a ConfigureNotify to clients to let them
      know if their frame is destroyed. We do this for OR windows too, even if
      we really probably shouldn't.
      This is based off of the client_rect. Since we listen to ConfigureNotify
      on OR windows, we'll receive the event. If we don't ever update the
      client_rect when moving or resizing OR windows, then we'll send
      ourselves a ConfigureNotify for a 0x0 size and then think that the
      client chose a new size for itself. Since our get_paint_volume is based
      on that rectangle, but the TFP code inside Cogl uses XGetGeometry
      itself, we get weird flickering artifacts.
  10. 28 May, 2014 2 commits
  11. 27 May, 2014 2 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.
    • Florian Müllner's avatar
      Actually implement opening the app menu · 31db32e8
      Florian Müllner authored
      The last commit added support for the "appmenu" button in decorations,
      but didn't actually implement it. Add a new MetaWindowMenuType parameter
      to the show_window_menu () functions and use it to ask the compositor
      to display the app menu when the new button is activated.
  12. 22 May, 2014 4 commits
  13. 21 May, 2014 6 commits
  14. 20 May, 2014 4 commits
    • Jasper St. Pierre's avatar
    • Jasper St. Pierre's avatar
      window-x11: Make sure to chain up in grab_op_began / ended · ecb4e09e
      Jasper St. Pierre authored
      To make sure shaken_loose gets reset.
    • Jasper St. Pierre's avatar
    • Jasper St. Pierre's avatar
      window: Replace the user_rect with the unconstrained_rect · 2c0ad5be
      Jasper St. Pierre authored
      Realistically, the user rect contains the unconstrained window
      rectangle coordinates that we want to be displaying, in case
      something in the constraints change.
      Rename it to the "unconstrained_rect", and change the code to always
      save it, regardless of current state.
      When metacity was originally being built, the purpose of the user
      rect was a lot less clear. The code only saved it on user actions,
      with various other calls to save_user_window_placement() and a force
      mechanism sprinkled in to avoid windows being snapped back to odd
      places when constraints changed.
      This could lead to odd bugs. For instance, if the user uses some
      extension which automatically tiles windows and didn't pass
      user_action=TRUE, and then the struts changed, the window would be
      placed back at the last place a user moved it to, rather than where
      the window was tiled to.
      The META_IS_USER_ACTION flag is still used in the constraints code
      to determine whether we should allow shoving windows offscreen, so
      we can't remove it completely, but we should think about splitting
      out the constrainment policies it commands for a bit more
      fine-grained control.
  15. 01 May, 2014 6 commits
  16. 29 Apr, 2014 1 commit