If cairo is a subproject, it's not necessarily installed when gtk
is built. In the source tree, cairo's headers are not stored in
a directory called 'cairo'.
GTK traditionally lets you activate keyboard shortcuts
even if they are for a non-active layout. But it is meant
to only activate with a keysym from a non-active layout
when that symbol is not present in the current layout.
That last condition was lost when key event handling
was redone for GTK4. Bring it back.
This makes sure that we don't have cursors disappearing on Windows upon
scrolling because we can't find a cursor that exists on the system during
a scroll, and unlike GTK-3.x, we do not default to the arrow pointer on GTK4.
Just mimic what we have on X11 and Wayland: the trusty standard arrow pointer.
Fixes issue #3581.
We were calling _gdk_surface_update_size() every frame, even if the
window size didn't change. This would cause us to discard all cached
buffers and redraw the whole screen.
This was BAD.
We ought to get the coordinates of where the window menu should be
displayed using gdk_win32_surface_get_root_coords(), instead of rounding
the position that we obtained with gdk_event_get_position().
Also rename items a bit in the same function, and call
gdk_event_get_event_type() for consistency with the other backends.
Fixes issue #3704.
We were leaking buffers. This wasn't caught by valgrind and friends
because it was shared memory (with the compositor), but top(1) would
instantly see memory consumption of the app and the shell go through the
roof.
We were calling _gdk_surface_update_size() every frame, even if the
window size didn't change. This would cause us to discard all cached
buffers and redraw the whole screen.
This was BAD.
guint32 is used as part of the protocol in broadway backend.
Memory size declared with it was mistakenly replaced with size_t type
which does not guarantee being 32bit on all platforms, leading to a crash.
These events don't make sense on physical devices (for starters, they
are relative to the logical pointer position). Use this device for
those events, also happens to be what the upper parts expect of them.
Commit 97b5fad131 was a forward port from a gtk3 patch, but the hunk
was applied on the wrong bits of code.
Ensure the initialization paths also do mark settings read from the
portal as valid, so the checks for optional/newer settings actually have
the expected result. It is also desirable to mark settings as valid
after configuration changes (as that patch did effectively do), but not
enough to fix all situations.
