... 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.
Add a variant of gdk_drag_begin that takes the start position
in addition to the device. All backend implementation have been
updated to accept (and ignore) the new arguments.
Subsequent commits will make use of the data in some backends.
gdkcursor-quartz.c uses the instancetype keyword, which doesn't seem to
be supported in the version of Objective C that Snow Leopard uses.
Replacing that keyword with the thing it represents makes it build.
Patch by Ryan Hendrickson,
http://bugzilla.gnome.org/show_bug.cgi?id=756770
The shadow will be drawn in the wrong place in those cases so all we can
do is disable it. This fixes double shadows drawn around menus, popups
and tooltips.
https://bugzilla.gnome.org/show_bug.cgi?id=734984
If a drag ends inside a known window, set the dest_window field
in the drag context. This information is needed to implemented
notebook tab dragging.
https://bugzilla.gnome.org/show_bug.cgi?id=752638
So a window can be maximized/zoomed again after being moved away from
its maximized position. This makes the zoom button on non-CSD windows
work as before.
Instead of using the default zoom behaviour use the internal
maximized state for selecting our own zoom target. This makes
zooming work for CSD windows where for some reason the
given default zoom target is the current window frame itself
resulting in a shadowless window of the same size.
While this makes the zoom button behave a bit different as expected
it makes things more consistent with other platforms and fixes CSD
zooming.
Support was added for GDK_HINT_ASPECT in
gdk_quartz_window_set_geometry_hints though with one restriction:
min_aspect and max_aspect have to be equal, which I believe corresponds
to the most common usage. A warning will be printed if this condition is
not met but min_aspect will be used anyway.
Only "wait" and "all-scroll" are not implemented properly. OS X does not
seem to have a proper interface to either cursor. Approximations are used
instead; see the code.
See bug 749178.
GdkKeymap already has support for _get_num_lock_state() and
_get_caps_lock_state(). Adding _get_scroll_lock_state() would be good
for completness and some backends (Windows?) could take advantage of
this.
First, attributes can be NULL (which is always the case when calling
gdk_window_ensure_native) so do not unconditionally dereference it.
Then the window_type should be taken directly from the GdkWindow as
in other backends (such as the X11 one for example).
https://bugzilla.gnome.org/show_bug.cgi?id=744942
Sending backingScaleFactor to a NULL NSWindow will silently give the
value 0 for the scale factor, causing insidious divide-by-zero bugs down
the line. This checks if the NSWindow is NULL first, as seems to happen
throughout the rest of the file.
Note that I don't have a hi-DPI OS X machine to test this on, though.
https://bugzilla.gnome.org/show_bug.cgi?id=738338
It's unused. At the same time, rename "begin_paint_region" to
"begin_paint". This will help us clean up how GDK painting works
in the future to allow more creative use of double-buffering.
It is not possible to successfully build GTK+ on OS X 10.6 and below
since NSFullScreenWindowMask is only available starting with 10.7. Add
ifdef guards around setStyleMask: in order to allow it to build on
earlier OS X releases.
https://bugzilla.gnome.org/show_bug.cgi?id=737561
Remove checks for NULL before g_free() and g_clear_object().
Merge check for NULL, freeing of pointer and its setting
to NULL by g_clear_pointer().
https://bugzilla.gnome.org/show_bug.cgi?id=733157
This implements native fullscreen mode on OS X >= 10.7. This patch
adds tracking of the fullscreen mode if externally modified, as well
as toggling the native fullscreen mode of the window as needed.
gdk_x11_display_set_window_scale() affects the interpretation of the
Xft/DPI XSETTING - it is substituted inside GDK with the value of
Gdk/UnscaledDPI xsetting. However, this change is not propagated to
GTK+ and from GTK+ back to gdk_screen_set_resolution() until the
main loop is run.
Fix this by handling the screen resolution directly in gdk/x11.
This requires duplication of code between GDK and GTK+ since we still
have to handle DPI in GTK+ in the case that GdkSettings:gtk-xft-dpi
is set by the application.
https://bugzilla.gnome.org/show_bug.cgi?id=733076
Previously, each begin_paint_region added to a stack of current paints,
and when end_paint was called, the paint was popped off of the stack and
the surface was composited into the parent paint surface.
However, the code was broken in the case of a backend like Wayland which
didn't keep track of nested calls and simply wiped and returned the
native impl backing surface every time.
Since this feature is flat out unused by GTK+ and we don't want to
really support tricksy things like these for other clients, just remove
the feature. If somebody does call begin_paint_region more than once,
warn and return without doing anything.
Traditionally, the way painting was done in GTK+ was with the
"expose-event" handler, where you'd use GDK methods to do drawing on
your surface. In GTK+ 2.24, we added cairo support with gdk_cairo_create,
so you could paint your graphics with cairo.
Since then, we've added client-side windows, double buffering, the paint
clock, and various other enhancements, and the modern way to do drawing
is to connect to the "draw" signal on GtkWidget, which hands you a
cairo_t. To do double-buffering, the cairo_t we hand you is actually on
a secret surface, not the actual backing store of the window, and when
the draw handler completes we blit it into the main backing store
atomically.
The code to do this is with the APIs gdk_window_begin_paint_region,
which creates the temporary surface, and gdk_window_end_paint which
blits it back into the backing store. GTK+'s implementation of the
"draw" signal uses these APIs.
We've always sort-of supported people calling gdk_cairo_create
"outside" of a begin_paint / end_paint like old times, but then you're
not getting the benefit of double-buffering, and it's harder for GDK to
optimize.
Additionally, newer backends like Mir and Wayland can't actually support
this model, since they're based on double-buffering and swapping buffers
at various points in time. If we hand you a random cairo_t, we have no
idea when is a good time to swap.
Remove support for this.
This is technically a GDK API break: a warning is added in cases where
gdk_cairo_create is called outside of a paint cycle, and the returned
surface is a dummy that won't ever be composited back onto the main
surface. Testing with complex applications like Ardour didn't produce
any warnings.
It seems that some backends implemented get_root_origin wrong
and returned the client window coordinates, not the frame window
coordinates. Since it's possible to implement generically for all
windows, let's do that instead of having a separate impl vfunc.
Instead of destroying the surface in the backend if this is
unable to resize, let the core code do it, and do it properly.
Based on a patch by Benjamin Otte.
https://bugzilla.gnome.org/show_bug.cgi?id=725172
Put dialogs and utility windows in the same level as normal and
toolbar windows so that Gtk can control their stacking instead of
forcing them, rather unnaturally, to be on top of all other windows,
even other application windows, even when another application has
focus.
If a motion event handler (or other handler running from the flush-events
phase of the frame clock) recursed the main loop then flushing wouldn't
complete until after the recursed main loop returned, and various aspects
of the state would get out of sync.
To fix this, change flushing of the event queue to simply mark events as
ready to flush, and let normal event delivery handle the rest.
https://bugzilla.gnome.org/show_bug.cgi?id=705176
We want a surface so we can properly represent the scale factor for it.
All backends are converted to use surfaces and we reimplement the
backwards compat code in the generic code.
We've long had double precision mouse coordinates on wayland (e.g.
when rotating a window) but with the new scaling we even have it on
X (and, its also in Xinput2), so convert all the internal mouse/device
position getters to use doubles and add new accessors for the
public APIs that take doubles instead of ints.
and not on each keystroke, which for some IMs apparently caused a full
update on each keystroke, not just a check for changes. Patch from
Takuro Ashie, bug #698183.
window_type_hint_to_level(): applied patch from Paul Davis which moves
dialogs to NSFloatingWindowLevel. This is not quite the perfect
solution, but it's a pragmatic fix that makes apps which have both
window types much more usable, and prevents dialog from disappearing
under an application's main window.
(cherry picked from commit 59d49e1566)
This is left over from an old effort to bundle gtk and its dependencies
into a Mac OS X Framework. The effort was more or less successful but
proved difficult to maintain and impractical to use because gtk programs
don't use the special Framework include syntax.
Change the visibility handling to be the same way we do it in
GLib now. We pass -fvisibility=hidden to gcc and decorate public
functions with __attribute__((visibility("default"))).
This commit just does this for GDK, GTK+ will follow later.
When events are paused, we should not return TRUE from prepare() or check().
GTK+ handles this for events that are already in the GTK+ queue, but
we also need suppress checks for events that are in the system queue - if we
return TRUE indicating that there are events in the system queue, then we'll
call dispatch(), and do nothing. The event source will spin, and will never
run the other phases of the paint clock.
(Broadway doesn't have a window system queue separate from the GDK event queue,
but we write the function the same way for consistency.)
https://bugzilla.gnome.org/show_bug.cgi?id=694274
Deprecate gdk_window_enable_synchronized_configure() and
gdk_window_configure_done() and make them no-ops. Implement the
handling of _NET_WM_SYNC_REQUEST in terms of the frame cycle -
we know that all processing will be finished in the next frame
cycle after the ConfigureNotify is received.
Activate the "hides on deactivate" behavior for splashscreens,
torn-off menus, utility windows, tooltips and notifications: when
another application is brought to the front, these windows are hidden
so as not to obscure it. This is the expected behavior for
application-specific floating windows on OS X.
(cherry picked from commit 0596f5591f)
so GtkMenu works properly. This is not right, but not more
wrong than always sending GDK_NOTIFY_ANCESTOR either.
(cherry picked from commit 35a9322e45)
Based on a patch from Paul Davis, inject synthetic enter events directly
into the Quartz event stream, instead of trying to synthesize them in GDK.
This seems to magically fix most combo box popup weirdness, I guess
some code is relying on a specfic order of events, or any other state
imposed by the "proper" code path of events coming in the usual way.
The patch also removes _gdk_quartz_events_send_enter_notify_event()
which is now obsolete.
(sortof cherry-pixked from 979e5061a0
but needed manual editing because GdkQuartzWindow.c was renamed
and apparently earlier patches not picked correctly/completely)
so they can appear on top of popup menus. Also, reorder the switch()
statement in window_type_hint_to_level() so it resembles the stacking
order, to avoid confision like this in the future. Fixes bug 688512.
(cherry picked from commit 1a2509a6ab)
Don't try to handle button press events on the window frame, they
have out-of-window coordinates. Also, break grabs on such events
so popup menus go away.
Patch from Kristian Rietveld, fixes bug 684419.
(cherry picked from commit 43e1354b71)
which does not really have a different effect than the previously
used NSPopUpMenuWindowLevel, but is what all code examples I found
are using, and it does make more sense.
(cherry picked from commit 47f0e3f1e1)
Before we used a window's background color, which resulted in corrupted
display in some cases, presumably because we didn't reset the active
pattern. This patch seems to eliminate the observed corruption.
(cherry picked from commit 0e42cf81f1)
The garbage would be visible if any widget enabled the toplevel
NSView's CALayer in order to do custom native rendering.
(cherry picked from commit 92ea94af5f)
Apply patch from Kristian Rietveld which addresses two issues
in gdkeventloop-quartz.c:
This patch moves the autorelease pool drain and introduces protection against
the invalidated ufds. Basically, when we suspect ufds has been invalidated by a
recursive main loop instance, we refrain from calling the collect function.
(cherry picked from commit 79b3326eaa)
get_time_from_ns_event(): apply patch from Michael Hutchinson which
makes sure the returned guint32 wraps correctly on 32 bit machines
when the uptime exceeds 2^32 ms.
Before, right click events were still let through into GDK. In this
case, also middle/right button events with x-coordinates in the range
[-3, 0] are processed, resulting in failures/crashes in the window
finding code because no GdkWindows are present in this range.
In the Quartz backend, there are two methods by which windows are
resized. The first method is fully handled by Quartz and does not appear
in the event stream the application resizes. The second method is when
we resize windows by ourselves. In OS X this happens when a GTK+ resize
grip is used. This resize grip is larger than the Quartz resize grip.
When the resize is started outside the "Quartz area", we have to handle
it by ourselves.
This patch fixes this manual window resizing by ignoring events while we
are in the process of resizing (such that the events actually arrive at
the sendEvent handler of GdkQuartzWindow where this resize is handled).
When the resize has finished we break all grabs such that GDK is not
stuck thinking the cursor is still in the resize window.
NSEvent -scrollingDeltaX and -scrollingDeltaY aren't defined before
10.7, so objc assumes that they return a pointer. Trying to cast to a
float generates a compiler error.
nsevent scrollingDeltaX/Y (available on OSX >= Lion) is used to
provide the smooth scrolling values. In any case, old fashioned
events are still sent, setting _gdk_event_set_pointer_emulated()
if the event contains both smooth and non-smooth values.
The F keys have no unicode mapping, and UCKeyTranslate() returns
a bogus 0x10 as mapping to unicode. Instead of checking for this
random and undocumented return value, simply assign all function
keys explicitly. This patch also splits the ill-named "known_keys"
array into "modifier_keys" and "function_keys" which is much
more obvious.
(cherry picked from commit 55f9e5cbaf)
Move g_return_if_fail() stuff from the backends to the public
functions in gdkscreen.c itself, and some fixes for ugly formatting in
the various gdkscreen-backend.c files.
