After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 696428 - gtksettings: Backends should know when to change cursor theme/size
gtksettings: Backends should know when to change cursor theme/size
Status: RESOLVED OBSOLETE
Product: gtk+
Classification: Platform
Component: .General
unspecified
Other Linux
: Normal normal
: ---
Assigned To: gtk-bugs
gtk-bugs
Depends on:
Blocks:
 
 
Reported: 2013-03-22 23:14 UTC by Matthias Clasen
Modified: 2018-04-15 00:04 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Matthias Clasen 2013-03-22 23:14:55 UTC
Something needs to listen for changes to the gtk-cursor-theme-name setting, and load the new cursor theme. This may be a little tricky, since the buffers of themed cursors are owned by the cursor theme.
Comment 1 Matthias Clasen 2013-03-22 23:19:27 UTC
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.
Comment 2 Morten Welinder 2013-08-23 01:12:29 UTC
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?
Comment 3 Rob Bradford 2013-08-27 13:42:02 UTC
Although this could be solved by connecting to GtkSettings::notify - the problem is that this is tricky to do in the *gdk* backends.
Comment 4 Domenico Ferrari 2013-09-05 08:36:26 UTC
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.
Comment 5 Domenico Ferrari 2013-10-01 14:04:16 UTC
(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.
Comment 6 Matthias Clasen 2018-02-10 04:57:34 UTC
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.
Comment 7 Matthias Clasen 2018-04-15 00:04:37 UTC
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