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.
The function returns the part of a monitors area that should be
used for positioning popups, menus, etc. The only non-trivial
implementation atm is in the X backend, all the other backends
just return the full monitor area. The X implementation is
currently suboptimal, since it requires roundtrips to collect
the necessary information. It should be changed to monitor
the properties for changes, when XFixes allows to monitor
individual properties.
https://bugzilla.gnome.org/show_bug.cgi?id=641999
Add GDK_MODIFIER_INTENT_SHIFT_GROUP to enum GdkModifierIntent
and handle it in gdk_keymap_get_modifier_mask(). Add an X11
impl of the method and return keymap_x11->group_switch_mask.
Return 0 from the default impl because we don't know.
If the keyboard group shifting modifier is *also* a normal
accelerator modifier, we need to special case it when calling
gdk_keymap_translate_keyboard_state(), so we get the right
key symbol for accelerators (for example we want Option-O,
not Option-Ø displayed in menu items). This patch should only
affect quartz where the Alt key both shifts the group and can
be used as accel modifier, and not X11 or Win32 where AltGr
is not used for accelerators.
- fix quartz' gdk_keymap_translate_keyboard_state() to return
the right consumed_modifiers
- add _gtk_translate_keyboard_accel_state() which does the
special casing
- use it everywhere instead of gdk_keymap_translate_keyboard_state()
Wake up the run loop unconditionally (don't check if it is waiting) because
it might go into waiting state right after we checked for it. Fixes GIMP
startup (which has a lot of GIOChannel I/O but zero NSEvents) from several
minutes to a few seconds.
(cherry picked from commit 0729cdc9a1)
Don't try to remember the current keyboard modifier and mouse button
states from the last event, because that isn't always right, and don't
set event.state = 0 for generated events. Instead, add private functions
to get the current states, and implement them with API that retrieves
these states independently from an event.
Fixes e.g. crashs when dropping from finder.
Turn the "getting_events" boolean into a counter to handle poll_func()
being called recursively, and track the loop depth correctly by
changing its counter before bailing out in run_loop_observer_callback().
This way we reallocate our autorelease pool at the right time, and
don't kill memory that is still in use by outer run loops.
Also drain, not release the pool, just for some defensive forward
compatibility.
(cherry picked from commit ef9a92d225)
When an NSEvent does not have the window field set, we already assumed
the event was not for us and discarded it. But for NSMouseMoved events
we now make an exception, because such events generated after
using/clicking the main menu bar have the window field set to NULL while
the application window still has focus.
We used to experience a loss of motion events after using the menu bar,
this could be seen in buttons that stopped prelighting and first
clicks often being ignored unless you clicked somewhere else first.
These issues are fixed by this patch.
