We are pretty good at batching commands now, and we can easily
produce batches that exceed the maximum number of elements per
draw call that the hw can handle. Query that number, and respect
it when merging batches.
This fixes the rendering of the overview map in GtkSourceView.
Claim the gesture when we are activating a list item.
Otherwise we end up with double activations in
columnviews: first GtkColumnViewCell handles
the event, and then GtkListItemWidget handles
it again.
Fixes: #4015
We were not handling the case right in which we
want to use underlines, but not use markup. Since
we are now using pango_parse_markup for this case,
we need to escape the xml markup.
Fixes: #4041
We don't want to overdraw when dragging a narrow column
around, and we also need the clipping to avoid picking
the wrong column, when a later column button overlaps
an earlier one.
Fixes: #4045
If we are undergoing a surface move, just apply the next_layout anyways,
even if we are not moving a toplevel surface.
Update the way how we obtain the x and y coordinates of a surface, if it
is a toplevel, apply the x and y coordinates from the results from we
obtained the underlying Win32 HWND, as we did before. But if it is a
popup, use gdk_win32_surface_get_geometry() to obtain the correct x and
y coordinates to place our popup surface.
Also correct how we compute the shadow dimensions, and the final popup
rectangle as we attempt to layout the popup surface, since GDK-Win32
keeps track of the shadow dimensions in system (unscaled) units, not GDK
units.
Fixes issue #3793.
The swipe gesture forces values in the spin button that are
"impossible" according to the adjustment. This can break things
in creative ways.
Ensure the steps provided are always multiples of the adjustment
step value, and keep the remainder for further interaction.
In the GTK3 days, the spin button was an entry, with buttons on
top, and the swipe gesture affected the input on the entry bits.
Now the spin button is a container, so this gesture in the capture
phase applies to all contained children (incl. buttons).
Attach this gesture to the entry itself, so the buttons are left
outside this business. The gesture is still in the capture phase
in order to prevent text selection/edition/etc to happen.
Fixes: https://gitlab.gnome.org/GNOME/gtk/-/issues/4008
The releasing of grabs while a button is pressed (e.g. after starting dnd, or
dragging the window, or going to overview with a pressed button, etc...) was
generalized here in https://gitlab.gnome.org/GNOME/gtk/-/merge_requests/1879.
However we shouldn't break all grabs here. In the case of grabbing popups,
compositors will still emit crossing events between client surfaces (e.g.
popping up and selecting a menu item via press-drag-release), breaking all
grabs here means inconsistent client state, that was
https://gitlab.gnome.org/GNOME/gtk/-/issues/2746.
That was fixed in mutter, by essentially making implicit grabs
owner_events=FALSE, however that breaks the mentioned use pattern entirely.
Mutter is changing this behavior back, so GTK should handle these crossing
events.
The grab that we are interested in breaking here is the implicit pointer
one. Popups will be dismissed via other means if the compositor says their
active grab needs breaking. This still leaves dnd/move/resize drags in
one place, while not allowing #2746 to happen with popups.
Visual Studio 2013's linker does not suport `/WHOLEARCHIVE:`, just
explicitly extract the objects from the static libraries that will
form the final GTK DLL.
