Same for the cursor size.

Currently we call into the x11 backend from gtk, when the cursor theme settings change - we may want to move that into the backend and do the update automatically.

The patch for this one causes

+    g_warning ("unsupported GDK backend\n");

to get hit on win32.

Can the backends be taught to handle this themselves instead of having
settings_update_cursor_theme know about all backends?

Although this could be solved by connecting to GtkSettings::notify - the problem is that this is tricky to do in the *gdk* backends.

I'm using win32. How can I debug my application if it always issues a warning?

From the reference manual
"--g-fatal-warnings.  Make GTK+ abort on all warnings. This is useful to stop on the first warning in a debugger, if your application is printing multiple warnings. It's almost always best to start debugging with the first warning that occurs."

Also the message is incorrect. The backend IS supported, it cannot set the cursor theme and maybe the user want the default... I haven't changed the cursor theme or size.
The function settings_update_cursor_theme is called from gtk_settings_get_for_screen when creating the default settings.

If you can't handle it in the backends I think you should call, in settings_update_cursor_theme, the functions
gdk_*_display_set_cursor_theme for every backends actually supported in gdkdisplaymanagers.c:gdk_backends and eventually do nothing in the backend if it cannot do that and ignore silently the request.

(In reply to comment #3)
> Although this could be solved by connecting to GtkSettings::notify - the
> problem is that this is tricky to do in the *gdk* backends.

I'm trying to suppress the warning and, for g_signal_connect, I need the GtkSettings object. I use gtk_settings_get_default before connecting but this issue the warning.

We're moving to gitlab! As part of this move, we are moving bugs to NEEDINFO if they haven't seen activity in more than a year. If this issue is still important to you and still relevant with GTK+ 3.22 or master, please reopen it and we will migrate it to gitlab.

As announced a while ago, we are migrating to gitlab, and bugs that haven't seen activity in the last year or so will be not be migrated, but closed out in bugzilla.

If this bug is still relevant to you, you can open a new issue describing the symptoms and how to reproduce it with gtk 3.22.x or master in gitlab:

https://gitlab.gnome.org/GNOME/gtk/issues/new