dfea8c31d9 added a check for portal settings array length but what it really checks is the amount of dbus out arguments.
This commit makes it do what gtk4 does: really check array length.
Fixes: #3838
For GDK_WINDOWING_BROADWAY, GDK_WINDOWING_WIN32 and GDK_WINDOWING_QUARTZ
links open correctly. For example, for GDK_WINDOWING_WIN32 this happens
via gspawn-win32-helper.exe / gspawn-win32-helper-console.exe. If these
helpers are missing, a corresponding error message is displayed, see
e.g. gtk3-demo.exe => Links. So there are already other error messages
if something goes wrong. For gtk4 the behavior also occurs without
warning. In my view this warning is more confusing than helpful.
When drag-and-dropping a file from Nautilus to for example Firefox, this
does not work if the file is from a GVFS mounted source. The retrieved
URI with `g_file_get_uri()` still contains the protocol.
Instead, we can use `g_filename_to_uri()`, which resolves to the local
`file://...` URI instead.
A similar fix was applied to GTK4 on the sending side in commit
ea056d26.
The Wayland protocols around outputs are truly a disaster.
This is a backport of 854e40c60c0d32 from main in the hope
of getting monitor geometry to work across compositors.
Fixes: #6939
If a `GtkMessageDialog` has a non-empty title set, use
that for the accessible name instead of a generic name
indicating the type of the message dialog, as the
window title is generally more informative, if set.
It also better matches the information presented
visually on screen (in the window title, task switchers,...)
and is in line with the handling for non-message-dialog
windows.
This can easily be tested with the "Dialogs and
Message Boxes" sample from gtk3-demo when setting
a title for the message dialog in there like this:
diff --git a/demos/gtk-demo/dialog.c b/demos/gtk-demo/dialog.c
index 0eb1c62397..53fb7f8b0e 100644
--- a/demos/gtk-demo/dialog.c
+++ b/demos/gtk-demo/dialog.c
@@ -25,6 +25,8 @@ message_dialog_clicked (GtkButton *button,
"number of times:");
gtk_message_dialog_format_secondary_text (GTK_MESSAGE_DIALOG (dialog),
"%d", i);
+ gtk_window_set_title (GTK_WINDOW (dialog), "Some informative title");
+
gtk_dialog_run (GTK_DIALOG (dialog));
gtk_widget_destroy (dialog);
i++;
Extract the existing logic to set an accessible name for the
`GtkMessageDialog` based on the message type from `setup_type`
to a new helper function `update_accessible_name`.
That helper function will be reused and extended in a follow-up
commit.
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>
Context IDs are dependant on the display - both because displays can use
different backends, but also because changing the GtkSetting is a
per-display operation.
So just remove the cache.
If it turns out we need a per-display cache, we can add one to
GtkSettings.
(cherry picked from commit 16d4ce4d0301b7af2a67703e792efdcf27b1d397
with slight changes to use priv->client_window instead of
priv->client_widget)
