From 9260319e7411ff8281700a532caa436f40120ec4 Mon Sep 17 00:00:00 2001 From: Christian Krinitsin Date: Fri, 30 May 2025 16:52:07 +0200 Subject: gitlab scraper: download in toml and text format --- gitlab/issues_text/target_missing/host_missing/accel_missing/2676 | 7 +++++++ 1 file changed, 7 insertions(+) create mode 100644 gitlab/issues_text/target_missing/host_missing/accel_missing/2676 (limited to 'gitlab/issues_text/target_missing/host_missing/accel_missing/2676') diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2676 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2676 new file mode 100644 index 000000000..0155be972 --- /dev/null +++ b/gitlab/issues_text/target_missing/host_missing/accel_missing/2676 @@ -0,0 +1,7 @@ +GTK+ UI has serious problems on macOS hosts +Description of problem: +The GTK+ UI simply does not work on macOS at this stage. One major reason is that there does not appear to be any regular polling of the (macOS) UI event loop. The Cocoa back-end for GTK [sets a custom event polling function in GLib's event handler](https://gitlab.gnome.org/GNOME/gtk/-/blob/main/gdk/macos/gdkmacoseventsource.c?ref_type=heads#L1089) but Qemu never actually calls GLib/GTK's event polling. + +Thanks to @bonzini for discovering this as part of a [discussion on a patch generalising runloop event handling on macOS](https://patchew.org/QEMU/20241113142343.40832-1-phil@philjordan.eu/20241113142343.40832-2-phil@philjordan.eu/#CABgObfat1JwiBFNKHK6wwMkW5kgaqZfKJa=rW._5F9VvEdMWJR75A@mail.gmail.com). + +There is also a reasonable chance that QEMU might not reliably call GTK+ functions from the main thread (thread 0), which causes problems when GTK then calls through to the native Cocoa APIs which must be called from thread 0. -- cgit 1.4.1