1. 04 Jan, 2019 1 commit
  2. 26 Oct, 2018 1 commit
  3. 25 Oct, 2018 1 commit
  4. 29 Jun, 2018 1 commit
  5. 30 May, 2018 2 commits
  6. 25 May, 2018 1 commit
  7. 22 May, 2018 1 commit
  8. 21 May, 2018 1 commit
    • Daniel Boles's avatar
      Range: Up should only mean ++ if we are a GtkScale · 4c39e06f
      Daniel Boles authored
      The last round of patches to get the desired direction of value move in
      response to scrolls/keypresses on scales had the inadvertent side effect
      of giving the opposite direction on scrollbars. Seeing as gtkrange.c is
      already a collection of hacks, add another so that fix only holds if the
      instance is a GtkScale, since that is what those patches were aimed at.
      Close #1065
  9. 20 May, 2018 1 commit
  10. 17 May, 2018 2 commits
    • Matthias Clasen's avatar
      Merge branch... · 08f31f8f
      Matthias Clasen authored
      Merge branch '1053-scroll-cursor-gets-left-behind-if-a-child-widget-steals-the-scroll' into 'gtk-3-22'
      Resolve "Scroll cursor gets left behind if a child widget steals the scroll"
      See merge request !134
    • Matthias Clasen's avatar
      textview: Don't scroll for pastes in another view · f2868f5c
      Matthias Clasen authored
      GtkTextView scrolls to the insertion point when the text
      buffer signals a paste is done. This is wrong when there
      are multiple views on the same buffer, and the paste
      happened in another view.
      To fix this, flip the handling of the scroll_after_paste
      boolean to only be TRUE if we know that we want to scroll.
  11. 16 May, 2018 1 commit
  12. 13 May, 2018 4 commits
  13. 12 May, 2018 4 commits
  14. 11 May, 2018 3 commits
  15. 09 May, 2018 3 commits
    • Jonas Ådahl's avatar
      wayland: Fix restarting cursor animation · 7edd465f
      Jonas Ådahl authored
      When an animated cursor was set and the previous cursor animation delay
      happened to be the same, we wouldn't restart the animation timeout and
      just return G_SOURCE_CONTINUE assuming the timer would continue. This
      assumption is however only valid if the function was called from the
      timeout, which is not the case.
      Instead also arm the timer also if there is no previous timer active.
    • Olivier Fourdan's avatar
      wayland: check native window for crossing events · cd5502dd
      Olivier Fourdan authored
      gdk_wayland_*_grab()/ungrab() would emit crossing events which translate
      as focus_in/focus_out events for keyboard.
      However, the ungrab() functions compare the native toplevel as this is
      what gets the Wayland pointer enter/leave events with the grab window,
      so if the grab is issued on a child gdk window, those won't match and we
      would emit more focus_out events than focus_in events.
      This means that a widget such as spice-gtk which issues a keyboard grab
      whenever the pointer enters the window and releases the grab when it
      leaves the window would get uneven numbers of focus_in/focus_out events.
      Also, gdk_wayland_seat_ungrab() would not emit crossing events for
      keyboard devices, whereas gdk_wayland_device_ungrab() does, which adds
      even more potential discrepancies between focus_in/focus_out events.
      To solve this problem, introduce two new helper functions which check
      the relevant native windows to emit crossing events when needed that get
      called evenly from both gdk_wayland_seat_grab()/ungrab() and gdk_Wayland
      _device_grab()/ungrab() APIs.
      Fixes: https://bugzilla.gnome.org/show_bug.cgi?id=780422
      Fixes: #792
    • John Ralls's avatar
      [Quartz] Hardcode screen resolution for text at 96.0. · 828f634d
      John Ralls authored
      It seems that CoreText is internally calibrated for this, see
      https://bugzilla.gnome.org/show_bug.cgi?id=787867 for a detailed
  16. 07 May, 2018 1 commit
  17. 06 May, 2018 3 commits
    • Björn Lindqvist's avatar
      Range: Bin pointless check before emitting signal · 893fc1de
      Björn Lindqvist authored
      In scroll_event(), there is no need to check whether we are realized
      before emitting ::change-value, as we must be when receiving an event.
      Git-formatted/rebased/cleaned up by Daniel Boles <dboles.src@gmail.com>
      Close #292
    • Daniel Boles's avatar
      Menu: cleanups for previous commit and nearby · 96774e8b
      Daniel Boles authored
      • #include <math.h> for the new uses of floor()
      • Move the new ints and popdown_data into the scopes where they are used
      • Don’t pointlessly init other ints to 0 as they always get reassigned
      • Burninate gint
    • Sam Douglas's avatar
      Menu: Fix broken navigation triangle/hysteresis · f443dbe8
      Sam Douglas authored
      This issue was caused when mouse coordinates were changed to floating
      point values in commit e8b38fed.
      This patch floors the event->x_root and event->y_root values when
      setting the navigation region, so the previous behaviour is restored.
  18. 05 May, 2018 1 commit
  19. 04 May, 2018 2 commits
  20. 02 May, 2018 1 commit
  21. 01 May, 2018 2 commits
  22. 30 Apr, 2018 3 commits
    • Benjamin Otte's avatar
      Merge branch '169-gtktextview-accesses-already-disposed-object-3-22' into 'gtk-3-22' · 33bec5a4
      Benjamin Otte authored
      Resolve "GtkTextView accesses already disposed object" in 3.22
      See merge request !110
    • Benjamin Otte's avatar
      Merge branch 'window-activate-grab-3-3' into 'gtk-3-22' · 279d7bb2
      Benjamin Otte authored
      gdk: do not deactivate window on keyboard grabs
      See merge request !127
    • Samuel Thibault's avatar
      gdk: do not deactivate surface on keyboard grabs · c926b28d
      Samuel Thibault authored
      When pressing e.g. a window manager shortcut, which acquires keyboard grab,
      Xorg would send FocusOut NotifyGrab then FocusIn NotifyUngrab.  Currently
      gdk would then deactivate the current surface, which makes accessibility
      screen readers think that we have switched to a non-accessible application
      and came back again, and thus reannounce the application frame etc. which we
      don't want when e.g. just raising volume.
      And actually, receiving FocusOut NotifyGrab does not mean losing the
      X focus, it only means an application aqcuired a grab, i.e. it is
      temporarily stealing keyboard events. On Wayland, this isn't even
      notified actually.
      This commit makes gdk only deactivate surfaces when there was an actual
      focus switch to another window, as determined by has_focus_window (instead
      of just has_focus), which happens either normally through FocusOut with
      NotifyNormal, or during grabs through FocusOut with NotifyWhileGrabbed.
      Fixes #85
      (cherry picked from commit 01455399)