We're not currently using this, and dropping it allows us to loose
a bunch of code which leads us towards the goal of having GdkWindow
only for toplevels (and reparenting makes not sense for toplevels).
We can't really support these on e.g. wayland anyway, and we're trying
to get rid of subwindow at totally in the long term, so lets drop this.
It allows us to drop a lot of complexity.
Switch code to use gdk_display_is_composited() instead.
The new code also doesn't use a vfunc to query the property but rather
requires the backend to call set_composited()/set_rgba() to change the
value.
These complicate a lot of GdkWindow internals to implement features
that not a lot of apps use, and will be better achieved using gsk.
So, we just drop it all.
The cursor was set using gdk_window_set_cursor() even in
gdk_window_new().
So instead of having yet another flag, just make the users of that flag
call gdk_window_set_cursor() directly after the window was created.
... and gdk_screen_get_window_stack().
Those functions were originally added in
5afb4f0f11 but do not seem to be used as
they are not implemented anywhere but in X.
As GDK is not meant to fulfill window management functionality I'm going
to remove these functions without replacements.
Always associate a drag context with a GdkDisplay and use that when
getting a cursor for a given action.
If we don't do this, dragging on a window that doesn't use the default
display will make us use cursors from the wrong display.
https://bugzilla.gnome.org/show_bug.cgi?id=765565
Windows save in hardware_keycode an information which is not so low
level and some application require the hardware scancode.
As Windows provides this information save it in GdkEventPrivate
and provide a function to get this information.
For no Windows system the function return the hardware_keycode instead.
Signed-off-by: Frediano Ziglio <fziglio@redhat.com>
https://bugzilla.gnome.org/show_bug.cgi?id=765259
The zoom/rotate change for quartz does not build on 10.7. This change
adds zoom/rotate support in quartz only for 10.8 and following. The
problems is described here:
https://bugzilla.gnome.org/show_bug.cgi?id=760276 and here
https://trac.macports.org/ticket/51052
NSEventPhaseMayBegin was only introduced in 10.8 although documentation
says it is introduced in 10.7. Tests on 10.7 indicate that the phase
property for the Magnify event is not supported at all on 10.7
gtk+ currently depends on the scaling factor and the cairo device scale
of both the backend surfaces and image surfaces to be equal.
Until now we didn't apply a cairo device scale at all and depended on the
automatic scaling of CGContexts. This works when drawing with cairo but
fails in case of image surfaces, which get requested at a too small size.
To make the quartz backend behave more like the X11 one, set the cairo device
scale on the surface in gdk_quartz_ref_cairo_surface(). As this conflicts
with the default scaling done by CGContext (we would get double scaling)
undo the CGContext scaling using CGContextScaleCTM().
This patch is based on the following patches by Brion Vibber:
https://bugzilla.gnome.org/show_bug.cgi?id=740199#c4https://bugs.freedesktop.org/show_bug.cgi?id=69796#c4https://bugzilla.gnome.org/show_bug.cgi?id=763779
MacOS provides the NSEventTypeMagnify which is very similar to the
Gtk ZOOM gesture and NSEventTypeRotate which is very similar to the
Gtk Rotate gesture. Those two event sequences are translated to a
sequence of GDK_TOUCHPAD_PINCH events. This sequence is then detected
in the upper gtk layers as Gtk Zoom/Rotate Gestures.
https://bugzilla.gnome.org/show_bug.cgi?id=760276
gdk_display_list_devices is deprecated and all the backends
implement the same fallback by delegating to the device manager
and caching the list (caching it is needed since the method does
not transfer ownership of the container).
The compat code can be shared among all backends and we can
initialize the list lazily only in the case someone calls the
deprecated method.
https://bugzilla.gnome.org/show_bug.cgi?id=762891
The g_print documentation explicitly says not to do this, since
g_print is meant to be redirected by applications. Instead use
g_message for logging that can be triggered via GTK_DEBUG.
