This function makes a better replacement for
gdk_display_get_core_pointer(), wherever it might yet be needed, for
XI2 resorts to XIGetClientPointer(), for the others return the only
core pointer.
https://bugzilla.gnome.org/show_bug.cgi?id=621685
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.
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.
These have been introduced in Leopard and default to int and unsigned int.
In 64-bit Snow Leopard they are long and unsigned long. This caused issues
with the getRectsBeingDrawn message which needs a pointer to a NSInteger
(long on 64-bit!) but we passed in an integer. Surprisingly this problem
was visible when compiling with -O0 (segfault), but *not* when compiling
with -O1. Other messages were NSInteger is now needed have also been
adapted.
Since NSInteger and NSUInteger are not available on Tiger, a define
has been added to add typedefs for these when they have not been defined
by the system headers.
Either g_type_register_static_simple (used by G_DEFINE_TYPE_EXTENDED)
and G_IMPLEMENT_INTERFACE use automatic variables for GTypeInfo and
GInterfaceInfo structs, while tutorials and source code often use
static variables. This commit consistently adopts the former method.
https://bugzilla.gnome.org/show_bug.cgi?id=600158
We have to do this, especially after the screen containing the menubar
has changed. Such more larger changes in monitor geometry will cause
changes to how monitors are laid out in the root window. The position
coordinates of the windows will have to be updated to reflect their
position in the new layout.
The Quartz port now supports arbitrary multiple monitor layouts instead
of only monitors are were laid out horizontally. This builds on the
reworked coordinate translation done in a previous commit.
The root window contains all the monitors attached to a Mac. The
coordinate transformation now both translates the x and y coordinate,
translating it from the Cocoa monitor coordinate space to the GDK
coordinate space. How monitors are laid out in the root window differs
between Cocoa and GDK, which is why it is important to translate based
on the root window to get multi monitor setups to work properly.
We have replaced the old y coordinate transformation function with
new functions that translate both the x and y coordinate.
When creating new toplevels, we have to determine the Cocoa screen on
which the toplevel should appear and translate the coordinates according
to that screen.
This change also fixes event handling in case there is a monitor left
of the screen containing the menu bar. In such a case all coordinates
on the left monitor are negative. Event handling broke, because of
_gdk_quartz_window_find_child() checking bounds. Now that coordinates
are always properly translated to GDK coordinate space, in which negative
coordinates do never occur, the checks here will work properly.
Using this we can update our internal monitor/screen layout state
and emit the GdkScreen::size-changed signal. Work has not
completely finished on this yet, see bug 596238.
