1. 22 Jan, 2018 1 commit
  2. 21 Jan, 2018 1 commit
  3. 18 Jan, 2018 13 commits
  4. 17 Jan, 2018 1 commit
  5. 16 Jan, 2018 1 commit
  6. 15 Jan, 2018 1 commit
  7. 12 Jan, 2018 2 commits
  8. 11 Jan, 2018 4 commits
    • Olivier Fourdan's avatar
      wayland: update location prior to maximize · 5f05112b
      Olivier Fourdan authored
      When maximizing a window, the previous location is saved so that
      un-maximize would restore the same original window location.
      
      However, if a Wayland client starts with a window maximized, the
      previous location will be 0x0, so if we have to force placement in
      xdg_toplevel_set_maximized(), we should update the location as well so
      that the window is placed on the right monitor when un-maximizing.
      
      For that purpose, add a new flag to force the update of the window
      location, and use that flag from xdg_toplevel_set_maximized().
      
      https://bugzilla.gnome.org/show_bug.cgi?id=783901
      5f05112b
    • Olivier Fourdan's avatar
      wayland: Do not enforce a size on un-maximize · 6cf7d2d4
      Olivier Fourdan authored
      When un-maximizing, use a zero size to pass to the client so that it can
      use the right un-maximized size that fits.
      
      https://bugzilla.gnome.org/show_bug.cgi?id=783901
      6cf7d2d4
    • Olivier Fourdan's avatar
      core: Add new unmaximize flag · 1139ace2
      Olivier Fourdan authored
      Wayland clients know their size better, so for Wayland we'd rather not
      try to resize the client on un-maximize, but for this to work we need a
      new MetaMoveResizeFlags.
      
      https://bugzilla.gnome.org/show_bug.cgi?id=783901
      1139ace2
    • Olivier Fourdan's avatar
      window: Defer stack placement without a buffer · bd9a3008
      Olivier Fourdan authored
      When closing a window and showing a new one, the new one may not be
      granted input focus until it gets a buffer on Wayland.
      
      If another window is chosen to receive focus and raised on top of stack,
      the newly mapped window is focused but placed underneath that other
      window.
      
      Meaning that for Wayland surfaces, we need to defer adding the window to
      the stack until we actually get to show it, once we have a buffer
      attached.
      
      Rather that checking the windowing backend prior to decide if a window
      is stackable or not, introduce a new vfunc is_stackable() which tells
      if a window should be added to the stack regardless of the underlying
      windowing system.
      
      Also add meta_window_is_in_stack() API rather than checking the stack
      position directly (replacing the define WINDOW_IN_STACK only available
      in stack.c) and remove a window from the stack only if it is present
      in the stack, so that the test in meta_stack_remote() becomes
      irrelevant.
      
      https://bugzilla.gnome.org/show_bug.cgi?id=780820
      bd9a3008
  9. 09 Jan, 2018 3 commits
  10. 25 Dec, 2017 9 commits
  11. 24 Dec, 2017 1 commit
  12. 21 Dec, 2017 2 commits
  13. 20 Dec, 2017 1 commit