1. 12 Jan, 2018 2 commits
  2. 07 Jan, 2018 1 commit
  3. 02 Jan, 2018 1 commit
  4. 25 Nov, 2017 1 commit
  5. 09 Nov, 2017 1 commit
  6. 27 Oct, 2017 1 commit
  7. 26 Oct, 2017 1 commit
  8. 04 Oct, 2017 1 commit
  9. 03 Oct, 2017 2 commits
  10. 18 Sep, 2017 1 commit
  11. 31 Aug, 2017 1 commit
  12. 03 Aug, 2017 1 commit
  13. 22 May, 2017 1 commit
  14. 09 May, 2017 1 commit
    • Jonas Ådahl's avatar
      GtkWindow: Don't double free export user data · d8bb3858
      Jonas Ådahl authored
      The user data passed when exporting a Wayland window was supposed to be
      freed using the destroy_func, as is commonly done. This was previously
      broken, as the user data was just NULL:ed when exported, and only
      actually destroyed when unexporting before having exported.
      While e016d9a5 fixed this, it introduced
      a regression, as GtkWindow was nice enough to free the memory anyway
      after having received the exported handle, causing it now to double
  15. 25 Apr, 2017 1 commit
  16. 20 Oct, 2016 2 commits
  17. 28 Sep, 2016 1 commit
    • Olivier Fourdan's avatar
      wayland: Avoid negative size constraints · dbd0923b
      Olivier Fourdan authored
      Setting the shadow width earlier as done with commit 4cb1b964 to address
      bug 771561 proved to cause unexpected side effects on size_allocate
      signal propagation.
      As the window is sized correctly earlier, the size_allocate signal is
      not emitted again in gtk_widget_size_allocate_with_baseline() which
      prevents clutter-gtk from relocating its child widget correctly.
      To avoid this issue, revert commit 4cb1b964 but make sure the values
      passed as min and max size is never negative in Wayland as this is a
      protocol error.
      With this, the min/max size will be wrong for a short amount of time,
      during the state transition, until the shadow width is updated from
      This approach is much safer and less intrusive than changing the
      size_allocate logic in gtk.
      This reverts commit 4cb1b964.
      Bugzilla: https://bugzilla.gnome.org/show_bug.cgi?id=771915
  18. 22 Sep, 2016 1 commit
  19. 19 Sep, 2016 1 commit
  20. 17 Sep, 2016 1 commit
    • Emmanuele Bassi's avatar
      docs: Update gtk_window_get_size() · 08e443e0
      Emmanuele Bassi authored
      The main corpus of the documentation for gtk_window_get_size() is still
      full of X11-isms, so we should port it to something that is more
      backend-agnostic. Additionally, having some examples would be nice for
      application authors looking at a way to appropriately use this function.
  21. 29 Aug, 2016 3 commits
  22. 24 Aug, 2016 1 commit
  23. 02 Aug, 2016 1 commit
  24. 28 Jul, 2016 1 commit
    • Matthias Clasen's avatar
      Put window exporting behind a display protocol agnostic API · 18aa0511
      Matthias Clasen authored
      Introduce a private API meant for abstracting how to get a handle
      of a window that can be shared with other processes. The API is
      async, since some implementations will require that. Currently,
      only X11 is supported, which doesn't.
      Based on a patch by Jonas Adahl.
  25. 25 Jul, 2016 1 commit
  26. 19 Jul, 2016 1 commit
  27. 06 Jul, 2016 1 commit
  28. 28 Jun, 2016 1 commit
    • Timm Bäder's avatar
      GtkWindow: Check for GtkWidget-window-dragging in multipress gesture · 92de947d
      Timm Bäder authored
      This partly reverts 9f5b9c0e, which
      removed the check for GtkWidget-window-dragging in the multipress
      gesture. This check is still needed for widgets which have this style
      property set (e.g. menubars and toolbars) can maximize the window on
      double click -- but those widgets which have it set to FALSE shouldn't
      maximize the window.
  29. 27 Jun, 2016 1 commit
  30. 01 Jun, 2016 1 commit
    • Olivier Fourdan's avatar
      headerbar: do not show buttons for modals/transients · 7c397c62
      Olivier Fourdan authored
      GtkHeadeBar checks the window type hint to determine if the regular
      buttons such as menu, maximize or iconify should be visible in the
      header bar.
      However, an application may very well use a "normal" toplevel window and
      set it transient and modal afterwards. In such a case, the iconify
      button would remain visible, and the user can hide the window, but being
      a modal, the parent window would remain insensitive.
      Check for the window type, modality and transient relationship to decide
      whether or not the regular toplevel buttons should be visible in the
      header bar.
  31. 24 May, 2016 1 commit
  32. 28 Apr, 2016 3 commits
  33. 22 Apr, 2016 1 commit