This was basically done copying the gtk4 version and keeping the changes
that weren't gtk4 specific.
Fixes#6224 (the chooser doesn't close but we don't crash or such)
Table (cell) row and column indices both start at 0, so
an index of 0 is valid.
Adapt the check accordingly and check for non-negative
indices instead of positive ones.
(`gtk_cell_accessible_parent_get_cell_position` sets -1
in the fallback case, so that's still handled as it used
to be.)
This fixes reporting the position of the table cell at
index (0,0) via AT-SPI.
Fixes: #5161
There is no need to include gdkquartz.h there,
which was making it impossible to include this header file
without also adding gdk/ as an include directory when compiling.
This patch moves the include to the only location where it is actually needed.
Clarify that we zero out the widget coords and only keep its dimensions.
If we have no widget to fall-back to, memset to 0 the output @rect since
we return FALSE whether or not we have widget, so protect users from not
knowing if there was a widget and possibly accessing uninitialised ints.
Fixes https://gitlab.gnome.org/GNOME/gtk/-/issues/893#note_1766079
I observed the following nautilus crash below after trying to access an SMB
share and mistyping my password (it also happens if mounting the SMB share
fails for other reasons after entering a password). The crash happens when
the password entry window pops up the second time, in this code path, at
the 7th element of priv->user_widgets:
458 pw_dialog_anonymous_toggled (GtkWidget *widget,
459 GtkMountOperation *operation)
460 {
...
472 for (l = priv->user_widgets; l != NULL; l = l->next)
473 {
474 gtk_widget_set_sensitive (GTK_WIDGET (l->data), !priv->anonymous);
475 }
The broken element had l->data = 0xaaaaaaaaaaaa, which means the pointer had
been freed.
The broken list entries were at the of the list because when
gtk_mount_operation_ask_password_do_gtk() constucts the pop-up the 2nd time,
it prepends new widgets:
gtk_mount_operation_ask_password_do_gtk()
table_add_entry
operation->priv->user_widgets = g_list_prepend (operation->priv->user_widgets, entry);
The problem is that in pw_dialog_got_response(), the widget is destroyed,
which also destroys all child widgets, but the priv->user_widgets list is
neither freed nor set to NULL.
Fix it.
1. According to the UTF-8 spec, ASCII character's charcode is from
0 to 127 inclusively.
2. Any charcode which is greater than or equal to 128 will be
a multi-byte character.
1. The data with type of char is signed by default.
2. The byte value of UTF-8 is signless by default.
3. So, if a UTF-8 charcode is stored in a char array, we should cast the
type of its value from char to unsigned char.
check_dir_mtime() is called by ftw() and is given
the real stat struct, not its glib version (which may
or may not be the same as "struct stat").
This is irrelevant for MSVC (it has no ftw()) and
works correctly for MinGW-w64 (which declares stat
structures correctly). If mingw.org complains, add
a special ifdef for it later.
This adds a new row to the Global/Information section which displays the
GTK im-module that is likely to be in use unless changed by an application.
It responds to updates of GtkSettings:gtk-im-module unless the
GTK_IM_MODULE environment variable is set.
Fixes#4512
(cherry picked from commit 6be352f4468b4dbbb1d71f427948dda154b9a658)
Starting from GLib 2.76, the standard attribute getters in the GFileInfo
object will warn if the attribute is unset, instead of silently bailing
out and returning a default value.
Fixes Evince showing a dark caret when using
dark theme, which makes it almost invisible.
This is in css node "textview text" of Evince
annotation window (a GtkScrolledWindow).
We create a new $caret_color var based on
$text_color and use it accordingly.
Fixes evince#1842
The iter may be invalid, so we may not read from it.
testsuite/gtk/treemodel tests this and valgrind is shouting about it,
but it never crashed until I just ran it...
This bug is from 2004 and the test is from 2007. I guess invalid memory
accesses don't get caught by CI much.
When activating a window, avoid the "old" gdk_notify_startup_complete*()
API that does not fallback into xdg_activation on wayland (as this is still
deferred here until show vs present happens on the surface). This was
mistakenly changed wrt the original commit backported from GTK4.
Fixes: a067938589 ("gtkwindow: Minor refactor")
Failure is allowed by nature of GInitable, and this avoids unnecessary
crashing of programs running with G_DEBUG=fatal-criticals.
(cherry picked from commit 6215b38e645f5047d52e625562efccc1e4f85867)
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 3526d8b299becb7cd1e970ea5228a141eae20257)
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 e8adfa2a889cd45ee0ce0727d7eae0a61fdb7dce)
Move the handling of the startup ID to a separate function, since
this will be called from several places.
(cherry-picked from commit 6f01f846dc66a6359a1524ace13377536821dbb0)
This was causing animation and transition to stop randomly and reset
their state to initial state.
This issue has existed since commit
7b68bdb831.
Closes#4426
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 4040f76529bbf6d3310a71df2d37c9d95af83892 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: 7928532bc5c33b2c6a10bae138ebc6dca1843cb0
(cherry picked from commit 89c816a614db4083e80862b631f4b3e44aa17eae)
