Bug Description: In a GTK+ application with a menu bar, clicking the
menu item displays a dialog. However, when the user opens this dialog
and drags the parent window's menu bar with the cursor, the dialog
gets moved.
Issue: When _gtk_gesture_update_point calls the _update_widget_coordinates
function, the local variables x and y are not explicitly initialized, leading
to arbitrary values. For instance, in my case, x was 32767 and y was
-145750164 . These values are used in the subsequent call to
gtk_widget_translate_coordinates. In gtk_widget_translate_coordinates,
if ancestor is NULL, the function returns FALSE, and dest_x and dest_y
are not updated. The incorrect values of x and y cause data->widget_x
and data->widget_y to be incorrect, ultimately leading to abnormal
x and y values in the gtk_gesture_drag_update function.
To avoid this, we should set x and y to values clearly outside the widget.
Signed-off-by: Li Kai <likai@kylinos.cn>
This is a backport from the GTK-4.x update, so that we can aim to
support gtkglsink in gst-plugins-good even on Windows, beyond using
just Cairo in gstsink for rendering.
From the commit message in GTK-4.x, in commit 627ee674:
We might be dealing with GL contexts from different threads, which have more
gotchas when we are using libepoxy, so in case the function pointers for
these are invalidated by wglMakeCurrent() calls outside of GTK/GDK, such as
in GstGL, we want to use these functions that are directly linked to
opengl32.dll provided by the system/ICD, by linking to opengl32.lib.
This will ensure that we will indeed call the "correct" wgl* functions that
we need.
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
I'm unable to compile gtk+-3 on Fedora 40 with profiler support
"-Dprofiler=true" because it looks for sysprof-capture-3 while
Fedora 40 only provides sysprof-capture-4.
GTK4 for the same build option only looks for sysprof-capture-4.
It's mandatory to reply to a xdg_surface.configure with a
xdg_surface.ack_configure, as well as a wl_surface.commit to have the
ack_configure to have any effect. We failed to do that if the new
configuration didn't cause any actual anything to change, meaning we'd
just ack_configure, but potentially never commit.
Fix this by requesting a 'after-paint' frame clock phase, while setting
the pending commit state to true. If we were already to paint, the new
requested phase would happen anyway, but to avoid double
wl_surface.commit when also using eglSwapBuffers*(), also avoid
performing the commit if we know the swap buffers will happen.
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.
