These are meant to always redirect events to the grabbing surface,
even for other surfaces of the same client. We weren't doing that
(instead letting the event go through unmodified), fix this handling
so GTK sees the events consistenty.
If a grab is held on a toplevel surface tree, and events happen on a
different surface tree from another toplevel/window group, we rewrite
these events so they look like generated on the window group that
holds the grab, but it missed that coordinates would fail to be
translated, so these would stay unchanged and "pointing" to random
parts of the toplevel that is holding the grab and handling the events.
Since off-surface coordinates are not specially meaningful, and in
fact impossible to obtain in some backends, just fake the coordinates
making it sure that all rewritten events point outside the surface.
The grabbing window will still handle the events, but the coordinates
in these will be harmlessly moot.
Fixes: https://gitlab.gnome.org/GNOME/gtk/-/issues/4760
The simplify and validate commands can function
without a display connection, only preview absolutely
needs one. Allow this, by using gtk_init_check().
The trickery we do with objcopy and ld to speed up
resource inclusion does not seem to work right on
32bit Arm, so just skip it there.
Fixes: #4757, #4748, #4752
When showing the native file chooser, we need to ensure we clear the
sorted surfaces in the display so that we don't risk delivering events
correctly on the next frame.
We had code to do it and it never actually got used correctly. This ensures
that the popup services are attached to the parents so that they get proper
stacking orders when displayed. Additionally, it fixes popups from being
shown as their own windows in Exposé.
If we are clicking through the shadow of a window, we need to take special
care to not raise the old window on mouseUp. This is normally done by the
display server for us, so we need to use the proper API that is public to
handle this (rather than CGSSetWindowTags()). Doing so requires us to
dispatch the event to the NSView and then cancel the activcation from
the mouseDown: event there.
If we closed a key window in response to events, we need to denote another
window as the new key window. This is easiest to do from an idle so that
we don't clobber notification pairs of "did resign"/"did become" key
window.
We have a sorted set of surfaces by display server stacking, so we can
take the first one we come across that is already mapped and re-show it
to become key/main.
If we have server-side decorations we might need to request a layout in
response to the resize notification. We don't need to do this in other
cases because we already handle that in the process of doing the resize
(and that code is that way because of delayed delivery of NSNotification).
If we are using NSWindow titled windows, we don't end up waking up the
frame clock when the window is resized on the display server. This ensures
that we do that after getting a notification of resize.
Ensure that resolution of the subproject occurs via the dependency
interface, not the "poke at subprojects manually" interface, and make
that actually work via --wrap-mode=forcefallback.
There's no need to mark it as not-required and then manually invoke
subproject(), since fallback should work correctly and it is always
needed.
However, if fallback was performed (or forced) it would error out since
get_variable() was instructed to only use pkg-config while the relevant
variable was exported by the subproject as an internal fallback
dependency.
There are cases we might want to consume a NSEvent without creating a
GdkEvent or passing it along to the NSApplication for processing. This
creates a new value we can use and check against to propagate that without
having to do out parameters at the slightly odd invalid pointer value for
a GdkEvent (similar to how MMAP_FAILED is done).
This can get in the way of how we track changes while events are actively
processing. Instead, we may want to delay this until the next main loop
idle and then check to see if we have a main window as the NSNotification
may have come in right after this.
This seems to be a problem since:
https://gitlab.gnome.org/GNOME/gtk/-/merge_requests/3565
To demo the problem, the video demo in gtk4-demo is currently set to
autoplay, but it doesn't autoplay on load as expected because the
"prepared" notification doesn't fire until the user explicitly presses
play.
Similarly if the demo is tweaked to disable autoplay then on loading a
video (or an audio-only ogg) the duration is not known or shown until
the user presses play.
In LibreOffice we want to know what the size of the video is to position
it before the user can interact with it to set it to play. We can
workaround this to some degree by listening to "invalidate-size" on the
GtkMediaStream object which updates for videos, but that doesn't wor
for audio-only streams.
So restore listening to media-info-updated but ignore -1 (which I see
for audio-only where I get -1 and then a useful value) and 0 of the
original report.
see also:
https://gitlab.gnome.org/GNOME/gtk/-/merge_requests/3550GNOME/gtk!4513
We were looking at GtkWidget:has-focus from
event controller signal handlers here, but
the widget property is only changed after
the event controllers.
