| Patch | Description | Author | Forwarded | Bugs | Origin | Last update |
|---|---|---|---|---|---|---|
| 016_no_offscreen_widgets_grabbing.patch | Don't let offscreen widget do grabbing | Cody Russell <bratsche@gnome.org> | yes | upstream | 2011-11-30 | |
| 017_no_offscreen_device_grabbing.patch | Do not allow devices in an offscreen hierarchy to take grabs. | Robert Carr <racarr@canonical.com> | yes | upstream | 2011-11-30 | |
| 060_ignore-random-icons.patch | Don't list images from unknown directories in icon cache After GTK 2.12.0, gtk-update-icon-cache fails if there is a PNG file placed directly in /usr/share/icons/hicolor (not in a correct subdirectory like 48x48/apps). this change is no longer necessary: "I believe a slightly different fix that I did some time ago fixes this too." --Matthias Clasen, 2008-02-16 04:43:10 UTC |
Loic Minier <lool@dooz.org> | yes | debian upstream | 2007-10-21 | |
| reftest_compare_surfaces-Report-how-much-the-images-diffe.patch | reftest_compare_surfaces: Report how much the images differ In unattended/non-interactive/autobuilder environments where the images are not trivially accessible, this provides a way to distinguish between totally different rendering and more subtle issues. |
Simon McVittie <smcv@debian.org> | yes | 2021-02-13 | ||
| reftests-Allow-minor-differences-to-be-tolerated.patch | reftests: Allow minor differences to be tolerated Based on an earlier patch by Michael Biebl, with additional inspiration from librsvg's reftests. Each .ui or .node reftest can have an accompanying .keyfile file like this: [reftest] tolerated-diff-level=20 tolerated-diff-pixels=1000 If the image differs, but the number of pixels that differ is no more than tolerated-diff-pixels and the differences are no more than tolerated-diff-level, then we treat it as a success with warnings, save the .diff.png for analysis, and use g_test_incomplete() to record the test-case as "TODO". |
Simon McVittie <smcv@debian.org> | yes | 2021-02-13 | ||
| immulticontext-Don-t-have-a-global_context_id.patch | immulticontext: Don't have a global_context_id 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) (cherry picked from commit 39345212e8190aefa55a5266c123b2a7afc5c75f) |
Benjamin Otte <otte@redhat.com> | no | upstream gtk-3-24 branch, after 3.24.43 | 2019-01-08 | |
| Ensure-the-staging_cairo_surface-is-destroyed-before-re-a.patch | Ensure the staging_cairo_surface is destroyed before re-assigning it Without doing so, memory regions allocated may not be freed in some cases. Closes 6675. (cherry picked from commit b237989bb3a795360e272f22f6edc23ca8f73f7e) |
yangyingchao <yang.yingchao@qq.com> | no | upstream gtk-3-24 branch, after 3.24.43 | 2024-04-30 | |
| gesture-set-widget-x-and-y-if-coordinate-translation-betw.patch | gesture: set widget x and y if coordinate translation between widgets fails 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. 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. (cherry picked from commit a1046a13da52e0b4ad4a552d27a535be2a604f5c) |
likai <likai@kylinos.cn> | no | upstream gtk-3-24 branch, after 3.24.43 | 2024-08-07 | |
| a11y-Extract-helper-function-to-set-GtkMessageDialog-a11y.patch | a11y: Extract helper function to set GtkMessageDialog a11y name 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. (cherry picked from commit 13f55cd3e664b0fa7c14944572f2b41b73d64d16) |
Michael Weghorn <m.weghorn@posteo.de> | no | upstream gtk-3-24 branch, after 3.24.43 | 2024-08-09 | |
| a11y-Use-non-empty-message-dialog-title-as-a11y-name.patch | a11y: Use non-empty message dialog title as a11y name 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++; (cherry picked from commit 939737c3e72c2deaa0094f35838038df92f2a724) |
Michael Weghorn <m.weghorn@posteo.de> | no | upstream gtk-3-24 branch, after 3.24.43 | 2024-08-09 |