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.
Add accessors for range->range_rect, range->slider_range,
range->slider_size_fixed and range->min_slider_size. Didn't add
properties for any of them because thir purpose is mostly to enable
proper subclassing.
This is exposed by overshooting in a HildonPannableArea. Leaking
a GtkTreeRowReference also means leaking the whole model, since
the GtkTreeModel reference count is increased for each row
reference.
Fixes bug #607770 - Leak in GtkTreeView with HildonPannableArea
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
We need to do this because otherwise the implicit button grab for this
(native) window will not deliver the button events not selected for
by this window. This is a problem because non-native child windows may
select using a wider event mask, and we can't emulate these events if we
don't get the native events.
Fixes bug #607508
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.
