CI and downstream packagers have been using the Meson build for a while
now, and we checked that it's idempotent to the Autotools build.
Having two build systems in tree doesn't make maintaining and releasing
GTK any easier, even if it's the stable/frozen branch.
Arrange for double-click-followed-by-drag to do
select by words, not select-and-dnd. This matches
the behavior in GtkTextView better and feels
intuitive.
Fixes: #2024
mouse_location can be set to NULL in gtk_range_update_mouse_location(). This
causes a match with stepper_?_gadget in gtk_range_multipress_gesture_pressed(),
as both are NULL. This leads to a grab being added internally and as well, a
critical error message, and a subsequent rejection of touch inputs. Returning
early when mouse_location is NULL prevents this.
Closes#4947
GtkSettings/X11 takes the values as provided by
XSettings. Unlike other backends, the values of
XSettings are in physical size (that's because
X11 doesn't support mixed-DPI setups anyway).
Take that in account when retrieving the cursor
size in gtk_tooltip_position ().
Note that this discrepancy between the X11 and
other backends has been fixed in GTK4.
Fixes https://gitlab.gnome.org/GNOME/gtk/-/issues/5223
Doing reset() on the text widgets after commit and delete_surrounding
is still too eager for some IMs (e.g. those that expect being able
to commit text while keeping a preedit buffer shown).
However, reset() is more of a "synchronize state" action on Wayland,
and it is still desirable to do that after changes that do come from
the IM (e.g. requesting the new surrounding text and cursor/anchor
positions). Notably here, the text_input protocol may still come up
with a preedit string after this state synchronization happens.
Shuffle the code so that the text widgets do not reset() the IM
context after text is deleted or committed, but the Wayland IM does
apply its practical effects after these actions happen. This keeps
the Wayland IM fully up-to-date wrt text widget state, while not
altering the ::commit and ::delete-surrounding-text behavior for
other IM context implementations.
When the IM commands the GtkText to delete text, the cursor position
would change, and so would the surrounding text. Reset the IM context
so that these updates are properly picked up by the IM.
Fixes backspace key behavior in the GNOME Shell OSK, since that relies
on the surrounding text being properly updated for the next iteration.
When the IM commands the GtkText to delete text, the cursor position
would change, and so would the surrounding text. Reset the IM context
so that these updates are properly picked up by the IM.
Fixes backspace key behavior in the GNOME Shell OSK, since that relies
on the surrounding text being properly updated for the next iteration.
Resetting the IM on IM updates is too eager and indeed the simple
IM context doesn't like that this happens in the middle of dead
key handling.
We however want to reset the IM after actual text buffer changes
(say, a committed string) moved the cursor position, altered the
surrounding text, etc. So that the IM implementation does know to
update its state.
Since there is going to be an actual IM reset anyways, it does
no longer make sense to try to preserve the old priv->need_im_reset
status during commit handling.
Resetting the IM on IM updates is too eager and indeed the simple
IM context doesn't like that this happens in the middle of dead
key handling.
We however want to reset the IM after actual text buffer changes
(say, a committed string) moved the cursor position, altered the
surrounding text, etc. So that the IM implementation does know to
update its state.
During entry widget manipulation (inserting or deleting text via keyboard)
the IM context is reset somewhat early, before the actual change took place.
This makes IM lag behind in terms of surrounding text and cursor position.
Shuffle these IM reset calls so that they happen after the changes, and
ensure that the IM is actually reset, since that is currently toggled on
a pretty narrow set of circumstances.
During text widget manipulation (inserting or deleting text via keyboard)
the IM context is reset somewhat early, before the actual change took place.
This makes IM lag behind in terms of surrounding text and cursor position.
Shuffle these IM reset calls so that they happen after the changes, and
ensure that the IM is actually reset, since that is currently toggled on
a pretty narrow set of circumstances.
Also, fix a bug during GtkEventControllerKey::im-update where the condition
on cursor position editability to reset the IM context was inverted.
This adds a private GDK API that GTK calls using GDK_PRIVATE_CALL(). It
is more or less a copy of the GdkSurface::titlebar_gesture() API, and
achieves the same. If the backend or compositor doesn't support titlebar
gestures, the existing path is used as a fallback.
Recent changes in GTK default input method
makes ~ char to start as dead key, that's
why filechooser stopped detecting it for the
keybinding to open location entry.
We also make sure '~' appears in the location
entry (instead of being emtpy).
Fixes#4911 for GTK3
When a Gtk.Popover loses the focus, it blocks the grab_notify
signal from the associated widget, and it unblocks it when it
regains the focus. To know whether the signal is or not blocked,
it uses the priv->grab_notify_blocked flag.
On the other hand, when the method update_relative_to() is
called, all the signals connected to the old associated widget
are disconnected, and connected to the new widget.
Unfortunately, the priv->grab_notify_blocked flag isn't updated,
which means that if update_relative_to() is called while the
Gtk.Popover doesn't have the focus (for example, because the
user switched into another application), when the focus is
regained, the code in window_focus_in() will see that
priv->grab_notify_blocked is TRUE and will unblock the handler;
but that handler wasn't blocked because the one that was blocked
was disconnected when update_relative_to() was called. This
shows a WARNING in the console:
GLib-GObject-WARNING **: ../../../gobject/gsignal.c:2692: handler '5146' of instance '0x556912f84f40' is not blocked
This patch fixes this.
Fix https://gitlab.gnome.org/GNOME/gtk/-/issues/4777
When using this function in GtkSourceView (for GTK 3), there was a
mistake for retrieving a GdkRGBA value.
So, better document the function to avoid further mistakes.
The 1px shadow was showing up on adjacent monitors when a SSD window was
maximized. Additionally this was causing mutter to skip direct scanout
of these windows, because they extend beyond the screen.
Related: https://gitlab.gnome.org/GNOME/mutter/-/issues/2304
In case of an offscreen window find its onscreen embedder, and NULL
any GdkWindowImpl that's not quartz, checking all return values.
This replaces 16ded683, removing its unnecessary search_for_nearest
functions.
Any unchecked cast of a GdkWindowImpl to GdkWindowImplQuartz risks at
least getting an invalid member reference, not just the ones in
gdk_quartz_window_get_foo, and all calls to gdk_quartz_window_get_foo need
to be checked, not just Gtk's internal calls. The motivation was that
transient_for was getting set on a Gimp offscreen window and that caused a
crash in raise_transient.
We no longer use the autotools 'dist-hook' to generate the items that we
need to build introspection with the Visual Studio projects, so drop the
autotools files and bits that we had to support this. So, for
introspection on Visual Studio via the project files, it is purely via
NMake at this point.
We already generate some of the sources for all builds, so extend this
to the other generated sources as well, since the Visual Studio projects
added support for generating these sources too.
Similarly, uses casts in `gtk_image_definition_unref()`. Compilation
succeeds without them, unlike in `gtk_image_definition_ref()`, because
`gtk_image_definition_unref()` is not called internally, unlike
`gtk_image_definition_ref()`. But the build would fail if some function
defined in the module were changed in the future to call
`gtk_image_definition_unref()`, and we can future-proof it now. This
also removes an inconsistency in how we access the members of the union.
`jhbuild build gtk+-3` with GCC 12 fails with:
```
In function ‘gtk_image_definition_ref’,
inlined from ‘gtk_image_definition_new_empty’
at ../../../../jhbuild/checkout/gtk+-3/gtk/gtkimagedefinition.c:107:10:
../../../../jhbuild/checkout/gtk+-3/gtk/gtkimagedefinition.c:241:13: error:
array subscript ‘GtkImageDefinition {aka union _GtkImageDefinition}[0]’
is partly outside array bounds of ‘GtkImageDefinitionEmpty[1]’
{aka ‘struct _GtkImageDefinitionEmpty[1]’} [-Werror=array-bounds]
241 | def->empty.ref_count++;
| ~~~~~~~~~~^~~~~~~~~~
../../../../jhbuild/checkout/gtk+-3/gtk/gtkimagedefinition.c:
In function ‘gtk_image_definition_new_empty’:
../../../../jhbuild/checkout/gtk+-3/gtk/gtkimagedefinition.c:105:34: note:
object ‘empty’ of size 8
105 | static GtkImageDefinitionEmpty empty = { GTK_IMAGE_EMPTY, 1 };
| ^~~~~
```
and many similar errors.
Fix it by casting `GtkImageDefinition` to `GtkImageDefinitionEmpty` or
similar, as appropriate.
Essentially backports 4dcd02e85315f487310e2e01fe9412706a77dc35 from main to gtk-3-24.
