gtk issueshttps://gitlab.gnome.org/GNOME/gtk/-/issues2024-03-28T10:22:26Zhttps://gitlab.gnome.org/GNOME/gtk/-/issues/6558auto-started gtk4 app cannot resize window in GNOME on Xorg2024-03-28T10:22:26ZMilan Crhaauto-started gtk4 app cannot resize window in GNOME on XorgThis is an interesting problem, from my point of view. I have an up-to-date to-be Fedora 40 machine with:
```
gtk4-4.13.9-1.fc40.x86_64
gnome-software-46.0-1.fc40.x86_64
```
When I set "GNOME on Xorg" in login and then restart the machi...This is an interesting problem, from my point of view. I have an up-to-date to-be Fedora 40 machine with:
```
gtk4-4.13.9-1.fc40.x86_64
gnome-software-46.0-1.fc40.x86_64
```
When I set "GNOME on Xorg" in login and then restart the machine (it's required to restart when switching from Wayland to Xorg) and log in for that user, then running the gnome-software either from terminal or from the Applications (it only shows a window of the already started app), the window cannot be resized by mouse. It can be maximized by double-clicking the header bar, but not by dragging the window edge.
When I run from a terminal `gnome-software --quit` and then start it again, either from the terminal or from the Applications, the window can be properly resized.
I cannot reproduce it under Wayland.
I noticed a glitch, the round edge of the window is not transparent when this misbehavior happens:
![img](/uploads/11bd26088d6d218eb93ac16ec49865af/img.jpg)
_The image also illustrates how hard it is to recognize where the window edge ends, because, well, there is no visual window edge now (`libadwaita-1.5~beta-1.fc40.x86_64`, if it matters), but it's only a side note. This bug is about something else._https://gitlab.gnome.org/GNOME/gtk/-/issues/6536Drop target highlight remains visible on Xorg2024-03-22T17:09:42ZBalló GyörgyDrop target highlight remains visible on XorgWhen I drag and drop a file from Files to Console, the blue highlight that shows the drop target remains visible after I dropped the file into the console. It happens only on Xorg. On Wayland it works as expected, and the blue highlight ...When I drag and drop a file from Files to Console, the blue highlight that shows the drop target remains visible after I dropped the file into the console. It happens only on Xorg. On Wayland it works as expected, and the blue highlight disappears.
Package versions:
- gnome-console 45.0 and 46rc
- vte4 0.74.2 and 0.75.92
- gtk4 4.12.5 and 4.13.9
- glib2 2.78.4 and 2.80.0
Distribution:
Arch Linux
![kgx-drop-target-highlight](/uploads/911967b588475c0211afe8226d9ec672/kgx-drop-target-highlight.png)https://gitlab.gnome.org/GNOME/gtk/-/issues/6166GTK3: gtk_window_popup_at_widget() places popup at the wrong position if widg...2023-10-19T10:50:16ZColomban WendlingGTK3: gtk_window_popup_at_widget() places popup at the wrong position if widget has window## Steps to reproduce
1. Create a widget which has its own window, e.g. a `GtkDrawingArea`
2. Place that widget in a container somewhere not at 0,0 (e.g. place it under another one in a grid)
3. Call `gtk_widget_popup_at_widget()` on th...## Steps to reproduce
1. Create a widget which has its own window, e.g. a `GtkDrawingArea`
2. Place that widget in a container somewhere not at 0,0 (e.g. place it under another one in a grid)
3. Call `gtk_widget_popup_at_widget()` on that widget.
<details>
<summary>Sample program reproducing the issue</summary>
```c
#include <stdio.h>
#include <gtk/gtk.h>
static void
item_activated (GtkMenuItem *item,
gpointer data G_GNUC_UNUSED)
{
fprintf (stderr, "Item %s activated\n", gtk_menu_item_get_label (item));
}
/* pops up a random menu using gtk_menu_popup_at_widget() */
static gboolean
popup_menu (GtkWidget *widget,
gpointer data G_GNUC_UNUSED)
{
GtkWidget *menu = gtk_menu_new ();
GtkWidget *item = gtk_menu_item_new_with_label ("Item");
g_signal_connect (item, "activate", G_CALLBACK (item_activated), NULL);
gtk_menu_shell_append (GTK_MENU_SHELL (menu), item);
gtk_widget_show_all (menu);
gtk_menu_popup_at_widget (GTK_MENU (menu), widget, GDK_GRAVITY_SOUTH_WEST,
GDK_GRAVITY_NORTH_WEST, NULL);
return TRUE;
}
/* just draw focus on the given widget */
static void
draw_area (GtkWidget *widget,
cairo_t *cr,
gpointer data G_GNUC_UNUSED)
{
if (gtk_widget_has_focus (widget))
{
gtk_render_focus (gtk_widget_get_style_context (widget), cr, 0, 0,
gtk_widget_get_allocated_width (widget),
gtk_widget_get_allocated_height (widget));
}
}
int
main (int argc,
char **argv)
{
gtk_init (&argc, &argv);
GtkWidget *window = gtk_window_new (GTK_WINDOW_TOPLEVEL);
g_signal_connect (window, "destroy", G_CALLBACK (gtk_main_quit), NULL);
GtkWidget *grid = gtk_grid_new ();
GtkWidget *label = gtk_label_new("gtk_menu_popup_at_widget() test");
g_signal_connect (label, "draw", G_CALLBACK (draw_area), NULL);
gtk_grid_attach (GTK_GRID (grid), label, 0, 0, 1, 1);
GtkWidget *dw = gtk_drawing_area_new ();
/* Uncomment this below to fix the popup positioning */
//gtk_widget_set_has_window (dw, FALSE);
gtk_widget_set_can_focus (dw, TRUE);
gtk_widget_set_size_request (dw, 20, 20);
g_signal_connect (dw, "draw", G_CALLBACK (draw_area), NULL);
g_signal_connect (dw, "popup-menu", G_CALLBACK (popup_menu), NULL);
gtk_grid_attach (GTK_GRID (grid), dw, 0, 1, 1, 1);
gtk_container_add (GTK_CONTAINER (window), grid);
gtk_widget_show_all (window);
gtk_main ();
return 0;
}
```
</details>
## Current behavior
* Under X11, the popup appears too far below/to the right. Effectively, the popup appears offset by its window's offset in its parent (e.g. it's origin).
* Under Wayland, the popup doesn't even pop up at all (it's not that you don't see it: focus is still in the main window, and keyboard interaction does not work as it would in the popup).
## Expected outcome
The popup appears right next to the widget, following the given gravities.
## Version information
3.24.38
## Additional information
In the example code, uncommenting `gtk_widget_set_has_window (dw, FALSE)` makes the popup appear correctly on both X11 and Wayland.https://gitlab.gnome.org/GNOME/gtk/-/issues/6086DropTargetAsync doesn't clear DROP_ACTIVE styling from widgets on drop finish2023-09-16T10:56:48ZThomas SzymanskiDropTargetAsync doesn't clear DROP_ACTIVE styling from widgets on drop finish<!--
Please, read the CONTRIBUTING.md guide on how to file a new issue.
https://gitlab.gnome.org/GNOME/gtk/-/blob/main/CONTRIBUTING.md
-->
## Steps to reproduce
1. Use DropTargetAsync on a widget
2. Accept a drop and finish it
He...<!--
Please, read the CONTRIBUTING.md guide on how to file a new issue.
https://gitlab.gnome.org/GNOME/gtk/-/blob/main/CONTRIBUTING.md
-->
## Steps to reproduce
1. Use DropTargetAsync on a widget
2. Accept a drop and finish it
Here is a patch for the Drag-and-Drop demo in gtk-demo that shows the issue. To reproduce, open the demo and drag one of the colours from the bottom onto one of the item rectangles. The drop will finish but the green outline will remain on the item until another drag is started.
[drop_target_async.patch](/uploads/cea85c7a294a29456caec7bb15bb004a/drop_target_async.patch)
## Current behavior
The active drop styling remains on the final element without being cleared.
## Expected outcome
The styling should clear itself when the drop is finished.
## Version information
4.10.5 and git head
## Additional information
While this patch doesn't actually read the contents of the GdkDrop, the real code does and it makes no difference.
Screenshot after trying a drop:
![2023-09-05_19-54-25](/uploads/609dbf4653b9c778e9d357e2ae07949f/2023-09-05_19-54-25.png)https://gitlab.gnome.org/GNOME/gtk/-/issues/5984Possible SEGV (null pointer deref) in init_randr15() from gdkscreen-x11.c2024-01-29T01:31:37ZGregory DuckPossible SEGV (null pointer deref) in init_randr15() from gdkscreen-x11.c<!--
Please, read the CONTRIBUTING.md guide on how to file a new issue.
https://gitlab.gnome.org/GNOME/gtk/-/blob/main/CONTRIBUTING.md
-->
There is a possible SEGV (null pointer deref) in `init_randr15()` from `gdkscreen-x11.c` (se...<!--
Please, read the CONTRIBUTING.md guide on how to file a new issue.
https://gitlab.gnome.org/GNOME/gtk/-/blob/main/CONTRIBUTING.md
-->
There is a possible SEGV (null pointer deref) in `init_randr15()` from `gdkscreen-x11.c` (see [here](https://gitlab.gnome.org/GNOME/gtk/-/blob/f0f7613adb4cb90826d65f60258c5cd1b529dc77/gdk/x11/gdkscreen-x11.c#L510)). The relevant snippet is:
```
static gboolean
init_randr15 (GdkX11Screen *x11_screen)
{
...
crtc = XRRGetCrtcInfo (x11_screen->xdisplay, resources, // XRRGetCrtcInfo() may return NULL
output_info->crtc);
...
for (j = 0; j < resources->nmode; j++)
{
if (xmode->id == crtc->mode) // <---- Possible NULL pointer deref
{
...
}
}
}
```
The problem is that the `XRRGetCrtcInfo()` function may return `NULL` under some rare conditions (see [here](https://gitlab.freedesktop.org/xorg/lib/libxrandr/-/blob/7181160b2c32b1bb804792990783fa25c1122bae/src/XrrCrtc.c#L37)). If this occurs, then a null pointer derefence will result. The `init_randr13()` function is also likely affected.
## Steps to reproduce
<!--
Please, explain the sequence of actions necessary to reproduce the
crash
-->
This is difficult to reproduce. One way is to send a corrupt X11 message that will cause `XRRGetCrtcInfo()` to fail. It is unlikely this SEGV would occur with "normal" usage.
<!--
You should try and reproduce with the demos applications available
under the `demos` directory, or the test programs in the `tests` directory.
Alternatively, please attach a *small and self-contained* example that
exhibits the issue.
-->
## Version information
<!--
- Which version of GTK you are using
- What operating system and version
- for Linux, which distribution
- If you built GTK yourself, the list of options used to configure the build
-->
Checked on Ubuntu 23.04 (shipped libs) and the latest git head.
## Backtrace
<!--
- Attaching a stack trace obtained using GDB is appreciated; follow the
instructions on the wiki:
https://wiki.gnome.org/Community/GettingInTouch/Bugzilla/GettingTraces
-->
```
Thread 1 "gedit" received signal SIGSEGV, Segmentation fault.
init_randr15.constprop.0 (screen=screen@entry=0x5555555bb350, changed=changed@entry=0x7fffffffd550)
at ../../../gdk/x11/gdkscreen-x11.c:586
586 if (xmode->id == crtc->mode)
(gdb) bt
#0 init_randr15.constprop.0 (screen=screen@entry=0x5555555bb350, changed=changed@entry=0x7fffffffd550)
at ../../../gdk/x11/gdkscreen-x11.c:586
#1 0x00007ffde859e669 in init_multihead (screen=0x5555555bb350) at ../../../gdk/x11/gdkscreen-x11.c:1035
#2 _gdk_x11_screen_new (display=<optimized out>, screen_number=0) at ../../../gdk/x11/gdkscreen-x11.c:1101
#3 0x00007ffde858eee5 in _gdk_x11_display_open (display_name=<optimized out>) at ../../../gdk/x11/gdkdisplay-x11.c:1606
#4 0x00007ffde853c9a7 in gdk_display_manager_open_display (manager=<optimized out>, name=0x0)
at ../../../gdk/gdkdisplaymanager.c:462
#5 0x00007ffde88d2aa5 in gtk_init_check (argc=0x0, argv=0x0) at ../../../gtk/gtkmain.c:1110
#6 0x00007ffde88d2af5 in gtk_init (argc=0x0, argv=0x0) at ../../../gtk/gtkmain.c:1167
#7 0x00007ffde86dbd17 in gtk_application_startup (g_application=0x555555583200) at ../../../gtk/gtkapplication.c:304
#8 0x00007ffff7f50074 in gedit_app_startup (application=0x555555583200) at ../gedit/gedit-app.c:667
#9 0x00007ffff7ec2010 in g_closure_invoke
(closure=0x55555557eb20, return_value=0x0, n_param_values=1, param_values=0x7fffffffd9d0, invocation_hint=0x7fffffffd950) at ../../../gobject/gclosure.c:832
#10 0x00007ffff7eef08d in signal_emit_unlocked_R.isra.0
(node=node@entry=0x55555557eb50, detail=detail@entry=0, instance=instance@entry=0x555555583200, emission_return=emission_return@entry=0x0, instance_and_params=instance_and_params@entry=0x7fffffffd9d0) at ../../../gobject/gsignal.c:3732
#11 0x00007ffff7edf69a in g_signal_emit_valist
(instance=<optimized out>, signal_id=<optimized out>, detail=<optimized out>, var_args=var_args@entry=0x7fffffffdb70)
at ../../../gobject/gsignal.c:3555
#12 0x00007ffff7edf923 in g_signal_emit (instance=<optimized out>, signal_id=<optimized out>, detail=<optimized out>)
at ../../../gobject/gsignal.c:3612
#13 0x00007ffde913013f in g_application_register (application=0x555555583200, cancellable=0x0, error=0x7fffffffdce0)
at ../../../gio/gapplication.c:2213
#14 0x00007ffde912e00f in g_application_real_local_command_line
(application=0x555555583200, arguments=0x7fffffffdd80, exit_status=0x7fffffffdd70) at ../../../gio/gapplication.c:1115
#15 0x00007ffde86dbeb4 in gtk_application_local_command_line
(application=0x555555583200, arguments=0x7fffffffdd80, exit_status=0x7fffffffdd70)
at ../../../gtk/gtkapplication.c:343
#16 0x00007ffde91308f9 in g_application_run (application=0x555555583200, argc=2, argv=0x7fffffffdf28)
at ../../../gio/gapplication.c:2542
#17 0x0000555555555400 in main (argc=2, argv=0x7fffffffdf28) at ../gedit/gedit.c:175
```https://gitlab.gnome.org/GNOME/gtk/-/issues/5983Possible SEGV (null pointer deref) in parse_settings() from xsettings-client.c2024-01-29T01:33:29ZGregory DuckPossible SEGV (null pointer deref) in parse_settings() from xsettings-client.c<!--
Please, read the CONTRIBUTING.md guide on how to file a new issue.
https://gitlab.gnome.org/GNOME/gtk/-/blob/main/CONTRIBUTING.md
-->
There seems to be a possible SEGV (null pointer deref) in `parse_settings()` from `xsettings...<!--
Please, read the CONTRIBUTING.md guide on how to file a new issue.
https://gitlab.gnome.org/GNOME/gtk/-/blob/main/CONTRIBUTING.md
-->
There seems to be a possible SEGV (null pointer deref) in `parse_settings()` from `xsettings-client.c` (see [here](https://gitlab.gnome.org/GNOME/gtk/-/blob/f0f7613adb4cb90826d65f60258c5cd1b529dc77/gdk/x11/xsettings-client.c#L359)). The relevant code snippet is:
```
static GHashTable *
parse_settings (unsigned char *data,
size_t len)
{
GValue *value = NULL;
...
switch (type)
{
...
default: // If "default", then value remains NULL
...
break;
}
...
if (gdk_name == NULL)
{
...
free_value (value); // <---- SEGV if value==NULL
}
...
}
```
## Steps to reproduce
This is difficult to reproduce. It is possible to do so by sending a corrupt X11 message such that `type` does not match any case in the `switch` statement, and `x_name` to be a value not recognised by `gdk_from_xsettings_name()`. If this occurs, then `value==NULL` and `gdk_name==NULL` at the crash location.
<!--
You should try and reproduce with the demos applications available
under the `demos` directory, or the test programs in the `tests` directory.
Alternatively, please attach a *small and self-contained* example that
exhibits the issue.
-->
## Version information
<!--
- Which version of GTK you are using
- What operating system and version
- for Linux, which distribution
- If you built GTK yourself, the list of options used to configure the build
-->
Checked on Ubuntu 23.04 (shipped libs) and the latest git head.
## Backtrace
<!--
- Attaching a stack trace obtained using GDB is appreciated; follow the
instructions on the wiki:
https://wiki.gnome.org/Community/GettingInTouch/Bugzilla/GettingTraces
-->
```
Thread 1 "gedit" received signal SIGSEGV, Segmentation fault.
0x00007ffff7eeb038 in g_value_unset (value=value@entry=0x0) at ../../../gobject/gvalue.c:304
304 if (value->g_type == 0)
...
#0 0x00007ffff7eeb038 in g_value_unset (value=value@entry=0x0) at ../../../gobject/gvalue.c:304
#1 0x00007ffde85a9784 in free_value (data=0x0) at ../../../gdk/x11/xsettings-client.c:243
#2 parse_settings (len=<optimized out>, data=<optimized out>) at ../../../gdk/x11/xsettings-client.c:363
#3 read_settings (x11_screen=0x5555555bb030, do_notify=0) at ../../../gdk/x11/xsettings-client.c:444
#4 0x00007ffde858ef13 in _gdk_x11_xsettings_init (x11_screen=0x5555555bb030) at ../../../gdk/x11/xsettings-client.c:618
#5 _gdk_x11_display_open (display_name=<optimized out>) at ../../../gdk/x11/gdkdisplay-x11.c:1611
#6 0x00007ffde853c9a7 in gdk_display_manager_open_display (manager=<optimized out>, name=0x0)
at ../../../gdk/gdkdisplaymanager.c:462
#7 0x00007ffde88d2aa5 in gtk_init_check (argc=0x0, argv=0x0) at ../../../gtk/gtkmain.c:1110
#8 0x00007ffde88d2af5 in gtk_init (argc=0x0, argv=0x0) at ../../../gtk/gtkmain.c:1167
#9 0x00007ffde86dbd17 in gtk_application_startup (g_application=0x555555583200) at ../../../gtk/gtkapplication.c:304
#10 0x00007ffff7f50074 in gedit_app_startup (application=0x555555583200) at ../gedit/gedit-app.c:667
#11 0x00007ffff7ec2010 in g_closure_invoke
(closure=0x55555557eb20, return_value=0x0, n_param_values=1, param_values=0x7fffffffd9f0, invocation_hint=0x7fffffffd970) at ../../../gobject/gclosure.c:832
#12 0x00007ffff7eef08d in signal_emit_unlocked_R.isra.0
(node=node@entry=0x55555557eb50, detail=detail@entry=0, instance=instance@entry=0x555555583200, emission_return=emission_return@entry=0x0, instance_and_params=instance_and_params@entry=0x7fffffffd9f0) at ../../../gobject/gsignal.c:3732
#13 0x00007ffff7edf69a in g_signal_emit_valist
(instance=<optimized out>, signal_id=<optimized out>, detail=<optimized out>, var_args=var_args@entry=0x7fffffffdb90)
at ../../../gobject/gsignal.c:3555
#14 0x00007ffff7edf923 in g_signal_emit (instance=<optimized out>, signal_id=<optimized out>, detail=<optimized out>)
at ../../../gobject/gsignal.c:3612
#15 0x00007ffde913013f in g_application_register (application=0x555555583200, cancellable=0x0, error=0x7fffffffdd00)
at ../../../gio/gapplication.c:2213
#16 0x00007ffde912e00f in g_application_real_local_command_line
(application=0x555555583200, arguments=0x7fffffffdda0, exit_status=0x7fffffffdd90) at ../../../gio/gapplication.c:1115
#17 0x00007ffde86dbeb4 in gtk_application_local_command_line
(application=0x555555583200, arguments=0x7fffffffdda0, exit_status=0x7fffffffdd90)
at ../../../gtk/gtkapplication.c:343
#18 0x00007ffde91308f9 in g_application_run (application=0x555555583200, argc=1, argv=0x7fffffffdf48)
at ../../../gio/gapplication.c:2542
#19 0x0000555555555400 in main (argc=1, argv=0x7fffffffdf48) at ../gedit/gedit.c:175
```https://gitlab.gnome.org/GNOME/gtk/-/issues/5962Possible SEGV (null pointer deref) with libxi API issue2024-01-29T01:42:36ZGregory DuckPossible SEGV (null pointer deref) with libxi API issue<!--
Please, read the CONTRIBUTING.md guide on how to file a new issue.
https://gitlab.gnome.org/GNOME/gtk/-/blob/main/CONTRIBUTING.md
-->
## Description
The `XIQueryDevice()` function can return `NULL` if an error condition occur...<!--
Please, read the CONTRIBUTING.md guide on how to file a new issue.
https://gitlab.gnome.org/GNOME/gtk/-/blob/main/CONTRIBUTING.md
-->
## Description
The `XIQueryDevice()` function can return `NULL` if an error condition occurs. However:
* The `gdk_x11_device_manager_xi2_constructed()` function (from `gdkdevicemanager-xi2.c`) does not do any `NULL` check on the returned value before passing it to `XIFreeDeviceInfo()`.
* The argument to `XIFreeDeviceInfo()` must be non-`NULL` (see `libxi` source code) or else it will crash (null pointer deref). This seems to be an API misuse error.
Relevant code snippet:
static void
gdk_x11_device_manager_xi2_constructed (GObject *object)
{
...
info = XIQueryDevice (xdisplay, XIAllDevices, &ndevices); /* info can be NULL */
... /* No NULL check */
XIFreeDeviceInfo (info); /* SEGV if info==NULL */
...
}
Relevant code location:
* https://gitlab.gnome.org/GNOME/gtk/-/blob/2e6b7b5b78fddab1cd86d73419c70610594e882d/gdk/x11/gdkdevicemanager-xi2.c#L772
## Steps to reproduce
<!--
Please, explain the sequence of actions necessary to reproduce the
crash
-->
This is somewhat difficult to reproduce, since it involves coaxing `XIQueryDevice()` to fail with `NULL`. Nevertheless, the bug is evident from inspecting the source code.
<!--
You should try and reproduce with the demos applications available
under the `demos` directory, or the test programs in the `tests` directory.
Alternatively, please attach a *small and self-contained* example that
exhibits the issue.
-->
## Version information
<!--
- Which version of GTK you are using
- What operating system and version
- for Linux, which distribution
- If you built GTK yourself, the list of options used to configure the build
-->
Checked on Ubuntu 23.04 (shipped libs) and the latest git head.
## Backtrace
<!--
- Attaching a stack trace obtained using GDB is appreciated; follow the
instructions on the wiki:
https://wiki.gnome.org/Community/GettingInTouch/Bugzilla/GettingTraces
-->
```
Thread 1 "gnome-mines" received signal SIGSEGV, Segmentation fault.
0x00007ffde827275d in XIFreeDeviceInfo (info=info@entry=0x0) at ../../src/XIQueryDevice.c:153
#0 0x00007ffde827275d in XIFreeDeviceInfo (info=info@entry=0x0) at ../../src/XIQueryDevice.c:153
#1 0x00007ffde8b8787a in gdk_x11_device_manager_xi2_constructed (object=0x5555555d29f0)
at ../../../gdk/x11/gdkdevicemanager-xi2.c:747
#2 0x00007ffff7e2a2e6 in g_object_new_internal
(class=class@entry=0x5555555d2660, params=params@entry=0x7fffffffd4a0, n_params=n_params@entry=4)
at ../../../gobject/gobject.c:2297
#3 0x00007ffff7e2bee3 in g_object_new_valist
(object_type=<optimized out>, first_property_name=first_property_name@entry=0x7ffde8bad6b2 "display", var_args=var_args@entry=0x7fffffffd770) at ../../../gobject/gobject.c:2585
#4 0x00007ffff7e2c53d in g_object_new
(object_type=<optimized out>, first_property_name=first_property_name@entry=0x7ffde8bad6b2 "display")
at ../../../gobject/gobject.c:2058
#5 0x00007ffde8b8f684 in _gdk_x11_device_manager_new (display=0x5555555bacb0)
at ../../../gdk/x11/gdkdevicemanager-x11.c:61
#6 _gdk_x11_display_open (display_name=<optimized out>) at ../../../gdk/x11/gdkdisplay-x11.c:1613
#7 0x00007ffde8b3c9a7 in gdk_display_manager_open_display (manager=<optimized out>, name=0x0)
at ../../../gdk/gdkdisplaymanager.c:462
#8 0x00007ffde8df4728 in gtk_init_check (argc=<optimized out>, argv=<optimized out>)
at ../../../gtk/gtkmain.c:1110
#9 gtk_init_check (argc=<optimized out>, argv=<optimized out>) at ../../../gtk/gtkmain.c:1102
#10 0x00007ffde8df5d2d in gtk_init (argc=<optimized out>, argv=<optimized out>)
at ../../../gtk/gtkmain.c:1167
#11 0x00007ffde8cbaeec in gtk_application_startup (g_application=0x55555558ba10)
at ../../../gtk/gtkapplication.c:304
#12 0x000055555556062c in mines_real_startup (base=0x55555558ba10) at src/gnome-mines.p/gnome-mines.c:1096
#13 0x00007ffff7e3783c in _g_closure_invoke_va
(param_types=<optimized out>, n_params=<optimized out>, args=0x7fffffffdc50, instance=<optimized out>, return_value=<optimized out>, closure=0x555555588320) at ../../../gobject/gclosure.c:895
#14 g_signal_emit_valist
(instance=<optimized out>, signal_id=<optimized out>, detail=<optimized out>, var_args=var_args@entry=0x7fffffffdc50) at ../../../gobject/gsignal.c:3462
#15 0x00007ffff7e37923 in g_signal_emit
(instance=instance@entry=0x55555558ba10, signal_id=<optimized out>, detail=detail@entry=0)
at ../../../gobject/gsignal.c:3612
#16 0x00007ffde8a100a6 in g_application_register
(application=application@entry=0x55555558ba10, cancellable=cancellable@entry=0x0, error=error@entry=0x7fffffffddc0) at ../../../gio/gapplication.c:2213
#17 0x00007ffde8a107fe in g_application_real_local_command_line
(application=0x55555558ba10, arguments=0x7fffffffde18, exit_status=0x7fffffffde14)
at ../../../gio/gapplication.c:1115
#18 0x00007ffde8a10bc8 in g_application_run
(application=application@entry=0x55555558ba10, argc=argc@entry=1, argv=argv@entry=0x7fffffffdf88)
at ../../../gio/gapplication.c:2542
#19 0x000055555555ae67 in mines_main (args_length1=1, args=0x7fffffffdf88)
at src/gnome-mines.p/gnome-mines.c:3216
#20 main (argc=1, argv=0x7fffffffdf88) at src/gnome-mines.p/gnome-mines.c:3225
```https://gitlab.gnome.org/GNOME/gtk/-/issues/5954Tooltips severely impact scrolling performance in gridview and columnview2023-11-19T18:21:04ZThomas SzymanskiTooltips severely impact scrolling performance in gridview and columnview<!--
Please, read the CONTRIBUTING.md guide on how to file a new issue.
https://gitlab.gnome.org/GNOME/gtk/-/blob/main/CONTRIBUTING.md
-->
## Steps to reproduce
1. Have a big list - thousands of items - containing many labels/inscri...<!--
Please, read the CONTRIBUTING.md guide on how to file a new issue.
https://gitlab.gnome.org/GNOME/gtk/-/blob/main/CONTRIBUTING.md
-->
## Steps to reproduce
1. Have a big list - thousands of items - containing many labels/inscriptions with tooltips (longer tooltips seem worse)
2. Scroll, especially near the middle of a very large list.
Here is a [small patch](/uploads/2e5e06e687cfc5405251805afd7c9fbf/characters.patch) that simply adds tooltips to the Lists > Characters demo in gtk4-demo that should at least help demonstrate that there is an issue.
The performance impact is also visible in nautilus in directories with many files with long filenames. Compare scrolling performance in directories seeded with these two scripts:
```
for ((i=1; i <= 50000; i++)); do
touch "$i"
done
```
and
```
for ((i=1; i <= 50000; i++)); do
touch "aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa$i"
done
```
## Current behavior
Performance is awful with tooltips, dropping to 1-2fps or even less. Scrolling in the same conditions without tooltips present is completely smooth. Near the top or bottom edges the impact isn't large, but as you get closer to the center performance gets worse. I've even seen what appear to be lockups like https://gitlab.gnome.org/GNOME/gtk/-/issues/5086 mentions but only in my own application, which uses a gridview and seems unusually heavily impacted.
## Expected outcome
The presence of tooltips shouldn't have a huge impact on performance when scrolling and not interacting with them.
## Version information
Fedora 38, 4.10.4, i3/X11
Also git head with gtk4-demo
## Additional information
No warnings or errors, even when my application appears to freeze.https://gitlab.gnome.org/GNOME/gtk/-/issues/5919`Gtk.Window.set_default_size()` / `:default-(width|height)` does not work to ...2024-02-20T01:20:58ZDaniel Boles`Gtk.Window.set_default_size()` / `:default-(width|height)` does not work to resize window / restore natural size on X11 (does on Wayland)[Per the docs](https://docs.gtk.org/gtk4/method.Window.set_default_size.html):
> Setting the default size to a value <= 0 will cause it to be ignored and the natural size request will be used instead. It is possible to do this while the...[Per the docs](https://docs.gtk.org/gtk4/method.Window.set_default_size.html):
> Setting the default size to a value <= 0 will cause it to be ignored and the natural size request will be used instead. It is possible to do this while the window is showing to “reset” it to its initial size.
This works on Wayland, but **not** on X.org (not a typo, despite most things being the other way around)
On X, the default size appears to be ignored, at least once the window is presented. Same for size > 0. Resizing the window manually updates the properties, _but_ setting them appears to do nothing at all.
Test case: Expand the window beyond its natural size, then click the button. On Wayland, it shrinks back down, as required. On X11, it does nothing.
I presume this is supposed to work on both? It is pretty important to be able to restore natural size, or otherwise update the size while the window is visible.
```c
#include <gtk/gtk.h>
static void
on_button_clicked (GtkButton *button, void *user_data)
{
GtkWindow *window = GTK_WINDOW (user_data);
gtk_window_set_default_size (window, -1, -1);
}
static void
activate (GtkApplication *app,
gpointer user_data)
{
GtkWidget *window = gtk_application_window_new (app);
GtkWidget *button = gtk_button_new_with_label ("Reset default sizes");
g_signal_connect (button, "clicked", G_CALLBACK (on_button_clicked), window);
gtk_window_set_child (GTK_WINDOW (window), button);
gtk_window_present (GTK_WINDOW (window));
}
int
main (int argc,
char **argv)
{
GtkApplication *app;
int status;
app = gtk_application_new ("org.gtk.example", G_APPLICATION_DEFAULT_FLAGS);
g_signal_connect (app, "activate", G_CALLBACK (activate), NULL);
status = g_application_run (G_APPLICATION (app), argc, argv);
g_object_unref (app);
return status;
}
```https://gitlab.gnome.org/GNOME/gtk/-/issues/5890X11 drag-and-drop failure not communicated to source, unlike Wayland2023-06-19T09:27:30ZAndrew GierthX11 drag-and-drop failure not communicated to source, unlike Wayland<!--
Please, read the CONTRIBUTING.md guide on how to file a new issue.
https://gitlab.gnome.org/GNOME/gtk/-/blob/main/CONTRIBUTING.md
-->
## Steps to reproduce
<!--
Please, explain the sequence of actions necessary to reproduce t...<!--
Please, read the CONTRIBUTING.md guide on how to file a new issue.
https://gitlab.gnome.org/GNOME/gtk/-/blob/main/CONTRIBUTING.md
-->
## Steps to reproduce
<!--
Please, explain the sequence of actions necessary to reproduce the
bug
-->
1. Ensure you are using X11 backend and not Wayland
2. Open gtk4-demo and select "Peg Solitaire"
3. Drag one of the "peg" squares either away from and then back to its original spot, or drag it to a position that is not a legal move (e.g. drag a peg adjacent to the center into the center).
4. Observe that the peg disappears, contrary to the game logic.
5. Repeat under Wayland (if available) to observe how it's supposed to work.
<!--
You should try and reproduce with the demos applications available
under the `demos` directory, or the test programs in the `tests` directory.
Alternatively, please attach a *small and self-contained* example
*written in C* that exhibits the issue.
-->
## Current behavior
<!--
Please describe the current behaviour
-->
The peg disappears under X11 because the "drop" signal is called in the GtkDragSource with parameter `delete_data` true, in spite of the fact that the "drop" signal in the GtkDropTarget returned a false result.
## Expected outcome
<!--
Please describe the expected outcome
-->
Since this is supposed to be a "move"-type operation, then surely it is a dangerous condition for `delete_data` to be true when the destination of the drop actually failed. Clearly the logic of the demo is not expecting the X11 behavior here.
## Version information
<!--
- Which version of GTK you are using
- What operating system and version
- For Linux, which distribution
- If you built GTK yourself, the list of options used to configure the build
-->
Tested by me on Gtk 4.10.3 on FreeBSD 13.2-stable (built from FreeBSD ports) and (by other people) on various Linux distributions (sorry, I don't have exact details). Everyone who has tested this for me has reported that the demo works on Wayland and misbehaves on X11, regardless of distro.
## Additional information
<!--
- Screenshots or screen recordings are useful for visual errors
- Attaching a screenshot or a video without explaining the current
behavior and the actions necessary to reproduce the bug will lead
to the bug being closed
- Please report any warning or message printed on the terminal
-->
My analysis of the issue is:
At the gtk level, the gtkdragsource emits the "drag-end" signal with delete_data == true if it gets the "dnd-finished" signal from gdk, and the x11 and wayland versions have _completely_ different logic over whether/when they emit that signal.
X11 emits it in gdk_x11_drag_handle_finished _regardless_ of whether the drop failed or succeeded, wayland emits it in response to a "finished" call on the data source.
If the drop target rejects the drop before the "drop" signal, then the `_finished` method is not called so the drag source doesn't see a successful drop. But this demo is checking for legal/illegal moves inside the "drop" signal and relying on a true/false return being communicated back to the drag source to keep the game state consistent.https://gitlab.gnome.org/GNOME/gtk/-/issues/5762FileChooser extremely slow to display search results in its ListView widget i...2023-11-19T17:16:46ZJeff FortinFileChooser extremely slow to display search results in its ListView widget in realtimeI've been testing the FileChooser's search performance with GTK 4.10.1 as provided by Fedora 38, and there are some highly visible performance problems remaining on my computers.
## Context
@carlosg's nice !5611 seems to provide better...I've been testing the FileChooser's search performance with GTK 4.10.1 as provided by Fedora 38, and there are some highly visible performance problems remaining on my computers.
## Context
@carlosg's nice !5611 seems to provide better / more complete results than before, and is meant to provide huge search backend performance improvements (i.e. instantaneous search results) due to the way it structures its queries.
However, in practice I am still seeing the very slow performance symptoms I had reported before as part of issue #4133. i.e., "I have to wait one second between each character I type while the whole thing freezes up" kind of slow (otherwise the [IBus character jumbling bug](https://github.com/ibus/ibus/issues/2486) comes mess with it even more).
Now that the search backend itself is fast, short of doing the performance hack I was suggesting with a longer SearchEntry `search-delay`, maybe there is something that can be optimized in `ListView`, which is the widget being used by the FileChooser if I am not mistaken.
## Methodology
On a fresh boot, after letting Tracker (especially tracker-miner-fs) settle, I opened Epiphany 44.1 (package from Fedora 38, not the flatpak version) and opened the file chooser with `Ctrl+O`, then selected the Home folder, activated the search field, and ran various search queries, trying to progressively type "journal de bord" at the speed I am allowed to do it without encountering the ibus bug.
## Profiling output
For the sake of these measurements, I have turned SELinux off entirely, rebooted the machine, and tested both on Xorg (where the issue is most visible) and Wayland.
* [GTK 4.10.1 filechooser search slow on workstation Xorg sysprof syscap.tar.xz](/uploads/a215262816eb33a75dc7cec8d24d01e1/GTK_4.10.1_filechooser_search_slow_on_workstation_xorg_sysprof_syscap.tar.xz)
* [GTK 4.10.1 filechooser search slow on workstation Wayland sysprof syscap.tar.xz](/uploads/d77df66a0f1ea7279207ef39ab362f07/GTK_4.10.1_filechooser_search_slow_on_workstation_wayland_sysprof_syscap.tar.xz)
The Wayland version is _much_ faster (and apparently less likely to trigger the IBus / mainloop blocking bug), but some sluggishness can still be felt, it's not 100% smooth. That said, using a patched version of Mutter with the infamous dynamic triple-buffering code under Wayland, the issue becomes even harder to observe (that doesn't mean the performance issue doesn't exist though ;)
Here are some screenshots of the above recordings.
Under Xorg:
![GTK_4.10.1_filechooser_search_slow_on_workstation_xorg_sysprof_screenshot_1](/uploads/7ab35b4d49b155d58024f597d4be3c58/GTK_4.10.1_filechooser_search_slow_on_workstation_xorg_sysprof_screenshot_1.png){width=45%} ![GTK_4.10.1_filechooser_search_slow_on_workstation_xorg_sysprof_screenshot_2](/uploads/c0fffbe11dacb73b9a5f3e919e2aaacc/GTK_4.10.1_filechooser_search_slow_on_workstation_xorg_sysprof_screenshot_2.png){width=45%}
Under Wayland (not using triple-buffering):
![GTK_4.10.1_filechooser_search_slow_on_workstation_wayland_sysprof_screenshot](/uploads/78f23dc9435a2cc20e365aed44272cbc/GTK_4.10.1_filechooser_search_slow_on_workstation_wayland_sysprof_screenshot.png)
## Additional information
Hardware:
* AMD Radeon "Pitcairn" R7/R9 270 graphics card, running on the open source drivers that come with Fedora by default
* Intel® Xeon® W3520 × 8 CPU
* 24 GB of RAM
* The majority of my files are on a conventional (non-SSD) 2TB hard drive, though performance-critical ones (such as dev folders, flatpak caches, thumbnails and tracker directories, etc.) are symlinked to a location on a separate SSD.
With that said, the HDD does not seem to be the problem here: if you look at the Wayland sysprof output (I forgot to record disk IO in sysprof for the Xorg test), we can see there is pretty much no disk IO going on, so it seems to be purely a graphics stack performance optimization in GTK.
On this machine, Nautilus 44.0 is able to return results much faster than Gtk FileChooser, although it uses the same widgets (ListView) and a slower search backend (its tracker backend is not yet revamped in the main branch, and it also has its own fallback "simple search", so it _should_ be slower), and the only difference I know is that it doesn't spam the graphics stack / listview, due to the same performance trick I had proposed in #4133, so this indicates to me that the issue in FileChooser's search results performance is probably related to the view rather than the backend.https://gitlab.gnome.org/GNOME/gtk/-/issues/5742sync_counter_for_end_frame: assertion failed: (impl->toplevel->extended_updat...2023-04-12T19:30:58ZThiago Bellini Ribeirosync_counter_for_end_frame: assertion failed: (impl->toplevel->extended_update_counter != None)I'm experiencing this on Debian Sid. Having this issue since it started migrating apps that use gtk4.
For example, I sometimes experience this when closing a tab on gnome-console (kgx). I also got this when trying to `shift+del` a selec...I'm experiencing this on Debian Sid. Having this issue since it started migrating apps that use gtk4.
For example, I sometimes experience this when closing a tab on gnome-console (kgx). I also got this when trying to `shift+del` a selection of files on nautilus. In both cases the whole app will crash and close.
It is really random, but since I work in my terminal a lot I usually get 1 or 2 crashes per day.
Just had a situation here in kgx and got this on syslog:
```
2023-04-11T13:44:37.203800-03:00 behemoth org.gnome.Console[3584]: Gdk:ERROR:../../../gdk/x11/gdksurface-x11.c:606:sync_counter_for_end_frame: assertion failed: (impl->toplevel->extended_update_counter != None)
2023-04-11T13:44:37.203843-03:00 behemoth org.gnome.Console[3584]: Bail out! Gdk:ERROR:../../../gdk/x11/gdksurface-x11.c:606:sync_counter_for_end_frame: assertion failed: (impl->toplevel->extended_update_counter != None)
```
Regarding my machine:
- Debian Unstable using the latest packages available (I run `apt dist-upgrade` daily on it)
- Running graphics card is this one: `VGA compatible controller: NVIDIA Corporation GP107M [GeForce GTX 1050 3 GB Max-Q] (rev a1)`
- Using x11 (would love to use wayland, but that option is disabled for me because this is an hybrid laptop) with the latest proprietary nvidia driver from the debian's unstable repositoryhttps://gitlab.gnome.org/GNOME/gtk/-/issues/5715Various title bar glitches with X11 / Mutter 442023-04-14T09:26:18ZSam LaneVarious title bar glitches with X11 / Mutter 44<!--
Please read https://wiki.gnome.org/Community/GettingInTouch/BugReportingGuidelines
first to ensure that you create a clear and specific issue.
-->
### Affected version
* Ubuntu Budgie 23.04
* Mutter 44.0
* XOrg
* Gtk 4.10.1
### ...<!--
Please read https://wiki.gnome.org/Community/GettingInTouch/BugReportingGuidelines
first to ensure that you create a clear and specific issue.
-->
### Affected version
* Ubuntu Budgie 23.04
* Mutter 44.0
* XOrg
* Gtk 4.10.1
### Bug summary
Various visual glitches on what seems primarily to be non CSD window title bars. Glitches involve the title bar missing completely, just seeing the window title or controls, and the parts of the title bar disappearing when resizing windows horizontally. The glitches are mostly visual as windows can still be dragged by the missing parts, and the buttons become visible on mouse hover.
### Steps to reproduce
1. Open an affected program (nemo, sol, atril in this instance)
2. A lot of the time, the title bar has visual glitches.
### What happened
Various appearance glitches
### What did you expect to happen
Windows to draw correctly
### Relevant logs, screenshots, screencasts etc.
![titlebar](/uploads/d7397ac9bad83456ec4e4ec84e5dc106/titlebar.png)
![i2](/uploads/0d3f2f2521b43f38c0a2e0d4d1f80124/i2.png)
![i3](/uploads/975bc66daee9e967cd1338ea75691e95/i3.mp4)
As suggested in another issue (mutter#2725), I did set the environment variable:
`GSK_RENDERER=cairo`
and as best I can tell, the issue does NOT occur when this is set.
<!-- Do not remove the following line. -->https://gitlab.gnome.org/GNOME/gtk/-/issues/5712Context menus in KGX and g-t-e fail to activate actions on X112023-10-09T11:32:10ZZander Brownzbrown@gnome.orgContext menus in KGX and g-t-e fail to activate actions on X11Unclear what is happening, but it seems that multiple people (i.e. @tekstryder, @ltenwolde) are affected by this
The actions are successfully activated via keyboard shortcuts, so presumably are being registered correctly, thus I'm guess...Unclear what is happening, but it seems that multiple people (i.e. @tekstryder, @ltenwolde) are affected by this
The actions are successfully activated via keyboard shortcuts, so presumably are being registered correctly, thus I'm guessing GtkPopover is failing to propagate something?
I can repoduce this on GNOME OS (via `GDK_BACKEND=x11 kgx --gapplication-app-id org.freedesktop.SuperTerm`), the issue doesn't occur with the wayland backend
Originally reported as https://gitlab.gnome.org/GNOME/console/-/issues/279, Possibly related to https://gitlab.gnome.org/GNOME/gtk/-/issues/4563https://gitlab.gnome.org/GNOME/gtk/-/issues/5610Unable to move windows by dragging the title bar on GTK4 Xorg with touchscreens2023-11-28T04:18:43ZThe Official GManUnable to move windows by dragging the title bar on GTK4 Xorg with touchscreens## Steps to reproduce
1. Install any application using the GTK4 backend (like most system apps on GNOME 43 and 44)
2. Use Xorg (bug does not exist in wayland)
3. Use a touchscreen and attempt to move a window by dragging on the title...## Steps to reproduce
1. Install any application using the GTK4 backend (like most system apps on GNOME 43 and 44)
2. Use Xorg (bug does not exist in wayland)
3. Use a touchscreen and attempt to move a window by dragging on the title bar. The window does NOT move.
## Current behavior
Unable to move any GTK4 windows with touchscreen on Xorg
## Expected outcome
Drag the window header bar to move a window works with touchscreen on Xorg
## Version information
- GTK4 (multiple versions tested up to 4.8.3 from fedora 37)
- Multiple OSs tested (Ubuntu Bionic with Budgie Xorg, Ubuntu Jammy with GNOME xorg, Ubuntu Noble Development with GNOME xorg, Fedora 37 with default GNOME, Pop!_OS 22.04) both system apps and apps under Flatpak
## Additional information
No issues with GTK2/GTK3 or QT5/6 applications on the same systems.https://gitlab.gnome.org/GNOME/gtk/-/issues/5600Gtk3 view flickers when GtkHeaderBar isn't shown or is drawn via Server-Side-...2023-02-20T22:22:37ZHenry RiehlGtk3 view flickers when GtkHeaderBar isn't shown or is drawn via Server-Side-Decorations.Hey!
Repro code can be found here: https://github.com/jpnurmi/oh-my-corners
Gtk3 windows flicker when using gtk_widget_queue_draw() to update the window. The flickering becomes a lot more apparent when swiping up and down with 2 finger...Hey!
Repro code can be found here: https://github.com/jpnurmi/oh-my-corners
Gtk3 windows flicker when using gtk_widget_queue_draw() to update the window. The flickering becomes a lot more apparent when swiping up and down with 2 fingers in the view, although the issue also sometimes occurs when the cursor enters or leaves the window. Swiping up and down in other windows also causes the flicker to happen.
This only happens on X11 systems. I tested this on Fedora 37 running Gnome, but others have reported the same issue on recent Ubuntu versions. People who are affected by the issue are NVIDIA/INTEL users, using both nouveau and the proprietary NVIDIA drivers, though it seems that AMD users are unaffected.
In the repro code, when commenting out ```gtk_widget_show(GTK_WIDGET(header_bar));``` the flickering only occurs in the top left and top right corner. For some reason the screen recording shows the entire window flickering even though I could only see the top left and right corners flicker.
![Screencast_from_2023-02-17_09-04-38](/uploads/e79dc77d1dfb073db7d0156d3df5c3fd/Screencast_from_2023-02-17_09-04-38.webm)
When we don't let GTK create a headerbar for us and use SSD by removing the following piece of code:
```
GtkWidget* header_bar = gtk_header_bar_new();
gtk_widget_show(GTK_WIDGET(header_bar));
gtk_window_set_titlebar(GTK_WINDOW(window), GTK_WIDGET(header_bar));
```
the flickering occurs on the entire window. It's worth noting that that bigger the window is, the more it flickers and the longer those black frames are present.
![Screencast_from_2023-02-17_09-05-32](/uploads/3c05beeb3f4447d42726751ad13031ea/Screencast_from_2023-02-17_09-05-32.webm)
I was able to remove all kinds of flickering by forcing Vsync on my device (https://askubuntu.com/questions/1066722/intel-screen-tearing-ubuntu-18-04), although at a massive performance cost.
Edit:
After some further testing, this also happens when GTK draws a HeaderBar itself and doesn't hide it.
Some food for thought: Since the flickering only ever happens when scrolling or entering and leaving the window, maybe the Gdk window listens to pointer events at a much faster rate than what the current refresh rate it, leading to multiple overlapping draw calls?https://gitlab.gnome.org/GNOME/gtk/-/issues/6046[X11] Buggy client sent a _NET_ACTIVE_WINDOW message2023-12-25T20:30:41Ztekstryder[X11] Buggy client sent a _NET_ACTIVE_WINDOW message<!--
Please read https://wiki.gnome.org/Community/GettingInTouch/BugReportingGuidelines
first to ensure that you create a clear and specific issue.
-->
### Affected Version
* Arch Linux kernel 6.0.8
* X11 / nVidia
* gnome/mutter 43.1
...<!--
Please read https://wiki.gnome.org/Community/GettingInTouch/BugReportingGuidelines
first to ensure that you create a clear and specific issue.
-->
### Affected Version
* Arch Linux kernel 6.0.8
* X11 / nVidia
* gnome/mutter 43.1
### Bug summary
Error emitted upon launch of application regardless of whether extensions are enabled or not.
### Steps to reproduce
1. Launch gnome-extensions-app via cli or shell launcher
2. Observer error output in system journal
### What happened
```
Nov 14 14:37:08 gnome-shell[323957]: Window manager warning: Buggy client sent a _NET_ACTIVE_WINDOW message with a timestamp of 0 for 0x1a00004
Nov 14 14:37:08 gnome-shell[323957]: Window manager warning: Buggy client sent a _NET_ACTIVE_WINDOW message with a timestamp of 0 for 0x1a00004
```
### What did you expect to happen
Application should launch without triggering errors
<!-- Do not remove the following line. -->https://gitlab.gnome.org/GNOME/gtk/-/issues/5223Tooltips displaced with 200% scaling (Windows, X11)2022-11-09T01:00:26ZNathan LeeTooltips displaced with 200% scaling (Windows, X11)## Steps to reproduce
1. Have 200% scaling enabled on your only monitor via Windows 11 resolution settings or Gnome on Xorg settings. (not an issue with Gnome on wayland)
2. Open gtk3-demo or gtk4-demo
3. run Cursors demo
3. hover o...## Steps to reproduce
1. Have 200% scaling enabled on your only monitor via Windows 11 resolution settings or Gnome on Xorg settings. (not an issue with Gnome on wayland)
2. Open gtk3-demo or gtk4-demo
3. run Cursors demo
3. hover over an icon button
Alternatively, try Inkscape with the tools to the left (issue originally reported in https://gitlab.com/inkscape/inbox/-/issues/7663)
## Current behavior
The tooltips are displaced downwards a bit too much (see screenshots below)
## Expected outcome
Similar behavior to just using GDK_SCALE=2 (where the tooltip is closer to the mouse).
- gtk3 on Windows, gtk3/gtk4 on X11 looks displaced.
- gtk3/gtk4 on Wayland and gtk4-demo on Windows look correct.
## Version information
- gtk3 1:3.24.34+r156+g812b3930d0-1
- Arch OS (VM), GNOME 42.4
- gtk4 1:4.8.1-1
- Arch OS (VM), GNOME 42.4
- Inkscape 1.2.1, gtk3 3.24.34; Inkscape 1.1.2, gtk3 3.24.31
- Windows 11 21H2 10.0.22000 N/A Build 22000 (also was originally reported in https://gitlab.com/inkscape/inkscape/-/issues/3858 on Windows 10)
- mingw-w64-x86_64-gtk3 3.24.34+r156+g812b3930d0-1, gtk4 equivalent is 4.8.1-1
- same Windows 11 (21H2 10.0.22000 N/A Build 22000)
## Additional information
gtk3-demo, hovering over the bottom right of the button on Arch (Gnome on X11)
| 200% scaling in settings | 100% scaling, but GDK_SCALE=2 |
| --- | --- |
| ![image](https://gitlab.com/inkscape/inbox/uploads/324940b5c11d58d39e3413b42bbf7fd7/image.png) | ![image](https://gitlab.com/inkscape/inbox/uploads/23ba93a32892d450df7a8e3930936ac7/image.png) |
same but with gtk4-demo (note that the bottom-right-most point that generates the tooltip is actually further inside the button)
| 200% scaling in settings | 100% scaling, but GDK_SCALE=2 |
| --- | --- |
| ![image](https://gitlab.com/inkscape/inbox/uploads/6dd7c8fee3acdc69dec11d8e923dff30/image.png) | ![image](https://gitlab.com/inkscape/inbox/uploads/647d33cbd870697ed67dfadfc4f2d56c/image.png) |
Originally reported in https://gitlab.com/inkscape/inkscape/-/issues/3858https://gitlab.gnome.org/GNOME/gtk/-/issues/5165Frame rate drop on X11 vs Wayland2023-07-09T16:10:08ZAndrew MarshallFrame rate drop on X11 vs WaylandSeeing typically only 40 FPS on a simple GTK application under X11 that updates on a tick callback.
## Steps to Reproduce
1. Start an X11 session
2. Run the "Frames" demo application
3. Observe the frame rate after a few seconds
...Seeing typically only 40 FPS on a simple GTK application under X11 that updates on a tick callback.
## Steps to Reproduce
1. Start an X11 session
2. Run the "Frames" demo application
3. Observe the frame rate after a few seconds
4. Drag and/or resize the window
## Current behavior
* Frame rate is typically ~40 FPS on a 60Hz monitor
* When dragging and resizing the window, frame rate increases to ~60 FPS
## Expected outcome
* Frame rate should stay consistently at the monitor's refresh rate (in my case 60 Hz)
## Version information
- GTK from current main (e7501185)
- Built with default options and `-D media-gstreamer=disabled`
- Ubuntu 22.04 LTS
- Nvidia driver version 510.85.02
## Additional information
Under a Wayland session application performs as expected (consistent ~60 FPS)https://gitlab.gnome.org/GNOME/gtk/-/issues/5096Window unresponsive after touch input on a Button2023-02-16T22:00:20ZFelipe A. HernandezWindow unresponsive after touch input on a ButtonAfter touch input on a GtkButton child under ActionRow (activatable=FALSE) the whole PreferencesGroup becomes unresponsive to both mouse and touch activation of activatable siblings.
Siblings can still be activated via keyboard input
O...After touch input on a GtkButton child under ActionRow (activatable=FALSE) the whole PreferencesGroup becomes unresponsive to both mouse and touch activation of activatable siblings.
Siblings can still be activated via keyboard input
Other PreferencesGroup in the PreferencesPage aren't affected and still receive activation.
Touch-specific, this issue does not happen after mouse or keyboard input.
I created a simple demo with the issue (touch required, prints to stdout): [demo.py](/uploads/b63c3849f8a9a512943b4e53f939373e/demo.py)
Adw 1.1.4
Gtk 4.6.6
pygobject 3.42.2
Reproduced on KDE Plasma (Wayland) and XFCE (X11).
Maybe an upstream issue, but the whole concept of using ListRow for preferences is Adwaita-specific.