1. 29 Sep, 2022 3 commits
  2. 26 Sep, 2022 2 commits
  3. 23 Sep, 2022 2 commits
  4. 20 Sep, 2022 1 commit
  5. 18 Sep, 2022 2 commits
  6. 17 Sep, 2022 1 commit
    • neldredge's avatar
      Recognize "stylus" devices as GDK_SOURCE_PEN · 8984b13d
      neldredge authored and Luca Bacci's avatar Luca Bacci committed
      Add "stylus" to the list of substrings in a device name that cause it to be recognized
      as a GDK_SOURCE_PEN device (previously "wacom", "pen" and "eraser").  Some devices
      just use "stylus" in their name, and are otherwise recognized as
      GDK_SOURCE_TOUCHSCREEN instead.
      
      Fixes #4394.
      8984b13d
  7. 14 Sep, 2022 1 commit
  8. 13 Sep, 2022 2 commits
  9. 11 Sep, 2022 1 commit
  10. 10 Sep, 2022 1 commit
  11. 09 Sep, 2022 1 commit
  12. 28 Aug, 2022 2 commits
  13. 26 Aug, 2022 1 commit
  14. 25 Aug, 2022 1 commit
  15. 22 Aug, 2022 1 commit
    • John Ralls's avatar
      [quartz] find_toplevel_under_pointer should not return _gdk_root · 7a56fa27
      John Ralls authored
      The macOS WM has no root window. We fake one with a 1x1 window at the
      origin that has no associated NSWindow. If the pointer is not on a
      realized GdkWindow the hierarchical search will place it in the root
      window even if it's nowhere near it. That's not valid, but returning it
      from find_toplevel_under_pointer prevents Gdk from discovering when the
      pointer is really over a GdkWindow. Return NULL instead so that the window
      discovery is re-performed.
      7a56fa27
  16. 21 Aug, 2022 1 commit
  17. 20 Aug, 2022 1 commit
  18. 18 Aug, 2022 1 commit
  19. 17 Aug, 2022 1 commit
  20. 16 Aug, 2022 1 commit
  21. 15 Aug, 2022 3 commits
    • Jordi Mas's avatar
      Update Catalan translation · 187093f2
      Jordi Mas authored
      187093f2
    • Rastersoft's avatar
      Remove unneeded unblock · 02ea88bb
      Rastersoft authored
      When a signal handler is disconnected, it doesn't matter if it
      was blocked or not, so there's no need to unlock it before
      disconnection.
      02ea88bb
    • Rastersoft's avatar
      Unblock signal on update_relative_to in Gtk.Popover · c9a3b427
      Rastersoft authored
      When a Gtk.Popover loses the focus, it blocks the grab_notify
      signal from the associated widget, and it unblocks it when it
      regains the focus. To know whether the signal is or not blocked,
      it uses the priv->grab_notify_blocked flag.
      
      On the other hand, when the method update_relative_to() is
      called, all the signals connected to the old associated widget
      are disconnected, and connected to the new widget.
      
      Unfortunately, the priv->grab_notify_blocked flag isn't updated,
      which means that if update_relative_to() is called while the
      Gtk.Popover doesn't have the focus (for example, because the
      user switched into another application), when the focus is
      regained, the code in window_focus_in() will see that
      priv->grab_notify_blocked is TRUE and will unblock the handler;
      but that handler wasn't blocked because the one that was blocked
      was disconnected when update_relative_to() was called. This
      shows a WARNING in the console:
      
      GLib-GObject-WARNING **: ../../../gobject/gsignal.c:2692: handler '5146' of instance '0x556912f84f40' is not blocked
      
      This patch fixes this.
      
      Fix GNOME/gtk#4777
      c9a3b427
  22. 12 Aug, 2022 1 commit
  23. 11 Aug, 2022 1 commit
  24. 08 Aug, 2022 5 commits
  25. 05 Aug, 2022 3 commits