1. 09 Mar, 2010 1 commit
  2. 23 Feb, 2010 9 commits
  3. 22 Feb, 2010 2 commits
  4. 19 Feb, 2010 1 commit
  5. 16 Feb, 2010 1 commit
  6. 12 Feb, 2010 1 commit
    • Matthias Clasen's avatar
      Fix a compatibility problem · 13d69e55
      Matthias Clasen authored
      It turns out that my attempt at handling Super, Hyper and Meta better
      is causing problems, mostly because Alt and Meta are commonly colocated
      in the modmap, and apps do a check for the Alt modifier regularly.
      
      See e.g bug 607697.
      13d69e55
  7. 09 Feb, 2010 1 commit
  8. 07 Feb, 2010 5 commits
  9. 05 Feb, 2010 1 commit
  10. 30 Jan, 2010 1 commit
    • Kristian Rietveld's avatar
      Improve enter/motion notify semantics · 66207cf1
      Kristian Rietveld authored
      On X11 we receive enter notify and motion notify events for a window
      regardless of its focus state.  On Mac OS X this is not the case.  This
      commit improves the semantics to overcome this difference.  It improves
      on my earlier patch that sent a motion notify event when a window became
      main.
      
      Instead of sending a motion notify when a window becomes main, we now
      send one when a window becomes key, which comes closest to a window
      getting focus in X11.  This motion notify is needed because Mac OS X does
      not send motion events when an application is inactive (none of its
      windows have focus), these events are sent in X11.  This dummy motion
      notify event (with current coordinates of the mouse cursor) allows an
      application to get its prelight and other state right when it gets focus
      and thus user attention.
      
      Another change is to send an enter notify event when updating the
      tracking rectangle of a GdkQuartView and the mouse cursor is currently in
      this rectangle.  This rectangle is at least updated on window creation.
      This enter notify event is important for the case where a new window
      appears right below the mouse cursor.  The window has to receive an enter
      notify event for the subsequent events to be processed correctly.  Mac
      OS X does not send one in this case, so we generate it ourselves.
      
      Both of these synthesized events have to go through
      _gdk_windowing_got_event() for updating statekeeping, etc.
      append_event() has a boolean flag now to make this convenient.
      66207cf1
  11. 26 Jan, 2010 1 commit
  12. 22 Jan, 2010 1 commit
    • Alexander Larsson's avatar
      Avoid integer overflow in gdk_rectangle_intersect · 3c618f2f
      Alexander Larsson authored
      If e.g. the right edge of the leftmost rectangle is near MIN_INT, and
      the left edge of the rightmost rectangle is large then subtracting these
      can lead to an integer overflow, making the resultant "width" falsely
      positive, thus returning a very wide result instead of the expected
      no-intersection result.
      
      We avoid the overflow by not doing the subtraction unless we know the
      result will be positive. There are still risks for overflow if x + width
      or y + width is larger than MAXINT, but we won't ever overflow for valid
      rects now.
      
      This may fix #607687
      3c618f2f
  13. 20 Jan, 2010 1 commit
  14. 19 Jan, 2010 3 commits
    • Alexander Larsson's avatar
      Drop outstanding cairo surfaces when window is made native · e31a6d1f
      Alexander Larsson authored
      Any old cairo_surface referencing the old impl window will be wrong
      when we make a window native, so drop it.
      
      This fixes bug #599511
      e31a6d1f
    • Alexander Larsson's avatar
      Move common gdkwindow.c code into function gdk_window_drop_cairo_surface · 46d25437
      Alexander Larsson authored
      This code is duplicated in several places, and more to come, so put
      it all in one place.
      46d25437
    • Alexander Larsson's avatar
      Track direct window cairo access and avoid tricks when used · 841fa477
      Alexander Larsson authored
      When a cairo surface is requested for direct window access (i.e. not
      when double-buffering) we can't really track when the actual drawing happens
      as cairo drawing is not virtualized. This means we can't properly flush
      any outstanding window moves or implicit paints.
      
      This actually causes problems with e.g. abiword (bug #606009) where they
      draw without double-buffering. If you press down it scrolls the window
      and then draws the caret, but the caret drawing does not flush the
      outstanding move from the scroll, so the caret gets drawn on the wrong
      screen.
      
      We fix this by never allowing either implicit paints or outstanding window
      moves on impl-windows where any windows related to it has an outstanding
      direct cairo surface. Luckily this is not very common so in practice this
      doesn't matter much.
      841fa477
  15. 15 Jan, 2010 1 commit
  16. 11 Jan, 2010 2 commits
  17. 03 Jan, 2010 2 commits
  18. 31 Dec, 2009 3 commits
  19. 30 Dec, 2009 3 commits