Port `gail_focus_notify` from using the deprecated
`atk_focus_tracker_notify` to notify about the new
focus object. Notify of a state of the focused state
instead, as suggested in the
`atk_focus_tracker_notify` doc [1].
Using the deprecated function e.g. resulted in
the Orca screen reader no longer announcing
initial focus on editable comboboxes in
LibreOffice Writer's toolbars after Orca dropped
support for the deprecated "focus" AT-SPI event
in this commit [2]:
commit 9e2902dd46c7e583a097e235dfd7e3c50b016383
Author: Joanmarie Diggs <jdiggs@igalia.com>
Date: Wed May 1 12:14:07 2024 +0200
Remove the on_focus handler for the LibreOffice script
The "focus:" event was deprecated many years ago. If the expected
"object:state-changed:focused" event is absent, that bug should
be fixed.
This commit makes the announcement work again.
It also fixes the scenario described in [3].
[1] https://docs.gtk.org/atk/func.focus_tracker_notify.html
[2] 9e2902dd46
[3] https://gitlab.gnome.org/GNOME/gtk/-/issues/454#note_2099344Fixes: #454
Again on massive filesystems, the very first character
is likely to bring a likewise massive amount of search
results that we need to maybe query info for, then create
icons and widgets for. While it's impressive we can do
that, it's also expensive and likely pointless, for the
first character.
Typing a second character is however very likely to
considerably reduce the amount of items to categorize and
show. So start actually searching from there.
Testing on a filesystem with 1434099 files indexed, trying 5
semi-random 1 character searches (n, h, t, i, o) returns on
average 168K items (min. 78771, max. 331471), trying 5
semi-random 2 character searches (no, he, th, in, on)
returns on average 34K items (min. 11133, max. 94961),
which is a more approachable set.
Doing this is enough that typing on a filechooser search
entry feels completely fluid.
The search provider should make it sure there are some
specific GFileInfo fields set. Fix the mimetype extraction
from the query, and use that to fill in the missing gaps
the best we can.
When starting a search over a very populated filesystem, it
is possible that typing the first chars will return a too
high number of results. Even though iterating through the
cursor is in itself very fast, extracting the GIO information
from those many files at once is not going to be as fast.
In order to increase interactivity (i.e. not make things
possibly sluggish) iterate the cursor in an idle function
and add search results to the filechooser model little by little.
If the user keeps typing (as it is likely will happen), there
will be better chances to cancel and proceed to the next
query timely. If not, the results will be there soon enough.
As fancy as property paths are, recursive resolution of files
to a location increases the big O complexity enough that it's
not a great option on large homedirs with many indexed files.
Ensure the files are from the right location through a URI
prefix match, which does hits an index. This may dramatically
improve performance on large indexed trees.
Testing this query in an isolated testcase with a total
1434099 indexed files shows that it can run more than 1500 times
per second in this computer (an average of 15200 queries in
several 10 second runs), which presumably is a tad faster than
anyone can type.
Closes: https://gitlab.gnome.org/GNOME/gtk/-/issues/4133
The GtkFileChooserEntry widget creates a file filter instance, but never
sinks its floating reference. Newer versions of GLib correctly warn if
an instance with a floating reference gets finalized.
Fixes: #6527
It is at least theoretically possible that gtk_entry_get_pixel_ranges
will return no ranges, and we should handle that without an
out-of-bounds access or segfault.
Based on the locales that are at least 85% translated in Damned Lies:
https://l10n.gnome.org/releases/gnome-41/
Limited by the locales available in emojibase
Closes#4568
(cherry picked from commit d8c79e91a21b831580ea890b7cf146934877fbb7)
gtk_widget_translate_coordinates() uses int argument and thus cuts off
any decimal parts. This can leads to reduces accuracy when e.g.
measuring the distance of a drag.
GTK4 is not affected as the translations is done differently.
Our webdav server has a root which is davs://mynextcloud/remote.php/webdav
When once creates a GFile out of or out of a subdirectory, and one call
g_file_get_parent(), it recurses too far up and try to query
davs://mynextcloud/remote.php which fails, resulting in a broken pathbar.
To fix that, before querying the metadata of each element of the path,
I query the "enclosing mount", then use it's root to compare the GFile
against.
This is a backport of !5830 to 3.24
On X11, gdk_window_move_to_rect() uses the position of the window to
calculate how it should be moved. However, any pending resizes that will
be executed on show() are not taken into account, resulting in
incorrectly positioned tooltips in case a tooltip window is re-used
often. This is not solved by gtk_widget_realize(), as this will do
nothing if the window is already realized.
Let's add a call to the private gtk_window_move_resize() function, so
that the size is always recalculated before the window is sent to
gdk_window_move_to_rect().
This exact fix was also needed in GtkMenu (7298e73c), with similar
reasoning.
Fixes#2142Fixes#2227
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.
