This reverts commit 5aaa373b

This reverts commit 45ba6e93.

This caused regressions in libhandy-using applications.

Fixes: #5389

This should do nothing worthwhile anymore, the X11/Wayland GtkApplication
implementations do already pass the startup ID from the platform_data
via windowing specific APIs, and the application handling the request
via show()/present() should trigger the activation request.

(cherry-picked from commit 3526d8b2)

While this used to be tangential to windows showing or requesting
focus, the xdg-activation Wayland protocol does merge both concepts
together.

But also, for a correct interaction with the compositor, the
toolkit should ideally merge the activation request resulting from
both into the same one, so that the gdk_window_focus() request
replies to the startup token that started the application and
correct focus-stealing prevention/etc happens, instead making up
one just in time for the focus request.

This kind of requires doing things in the right order, a show()
request on the GtkWindow should activate any pending activation
token on the toplevel, a present() request should additionally
create a new token if there was none pending. And
xdg_activation_v1_activate() should happen once on both.

Shuffle the gdk_window_set_startup_id() calls so that this
happens in the right order for Wayland, while making X11 happy
too.

(cherry-picked from commit e8adfa2a)

Move the handling of the startup ID to a separate function, since
this will be called from several places.

(cherry-picked from commit 6f01f846)

Fallback icons loaded were loading at half size (for a 2x scale) and for
cases where it mattered, were being positioned off-center.

Matteo Percivaldi authored Jan 13, 2023 and Matthias Clasen committed Jan 13, 2023

This was causing animation and transition to stop randomly and reset
their state to initial state.

This issue has existed since commit
7b68bdb8.

Closes #4426

Setting the default extension before a filter is selected allows
the IFileDialog to automatically change the extension when the
filter is changed. See:
https://learn.microsoft.com/en-us/windows/win32/api/shobjidl_core/nf-shobjidl_core-ifiledialog-setdefaultextension

The @filename@ directive will use the full path of the file being parsed
for enumeration types; we should use @basename@, instead, as it improves
the reproducibility of the build by using only the file name.

Backport of 4040f765 from main.

The loop sets empty = FALSE when there are emojis but for that
to work we need to initialize the value to TRUE initially.

Fixes: 7928532b
(cherry picked from commit 89c816a6)

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.

Let's avoid complaints from the compiler.

They must match so the introspection scanner can do its job.

It's completely useless, and just generates compiler warnings with
recent GLib versions.

We depend on a new enough version of Meson.

Use get_variable(pkgconfig:...) instead.

Matthias Clasen authored Dec 03, 2022 and Luca Bacci committed Dec 03, 2022

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

`master` doesn't exist anymore and we want to refer to a GTK3 example

hrdl authored May 15, 2022 and hrdl committed Nov 11, 2022

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

When displaying accelerators, differentiate keypad
symbols with a 'KP' prefix. Fixing a 17 year old bug.

Backport of c58d9446.

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 #5223

Carlos Garnacho authored Sep 24, 2022 and msizanoen1 committed Oct 06, 2022

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.

Carlos Garnacho authored Sep 06, 2022 and msizanoen1 committed Oct 06, 2022

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.

Carlos Garnacho authored Sep 06, 2022 and msizanoen1 committed Oct 06, 2022

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.

Carlos Garnacho authored Sep 06, 2022 and msizanoen1 committed Oct 06, 2022

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.

Carlos Garnacho authored Sep 06, 2022 and msizanoen1 committed Oct 06, 2022

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.

Carlos Garnacho authored Aug 18, 2022 and msizanoen1 committed Oct 06, 2022

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.

Carlos Garnacho authored Aug 18, 2022 and msizanoen1 committed Oct 06, 2022

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.

When the level doesn't include the style, we need
to work a bit harder to really get a face object
here.

Fixes: #5173

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 signal handler is disconnected, it doesn't matter if it
was blocked or not, so there's no need to unlock it before
disconnection.

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 #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.