Bug 328016

Selecting cursor theme manually fixed the problem.  I guess something went wrong with the theme selecting program.

I'm unable to reproduce the crash or the apparently subsequent bug.  The segfault makes this nominally critical, but without a stack trace, I'm not sure we'll ever know what was responsible for the crash unless someone can reproduce it.

Any chance you can install debuginfo packages (control-center2-debuginfo, glib2-debuginfo, gtk2-debuginfo, gnome-vfs2-debuginfo), reproduce the crash (that may be the tricky part), and get a stack trace? bug-buddy should actually be useful if you have those packages installed.

Unfortunately, I can't reproduce the problem anymore.  Something is screwed up with theming tho.  Whenever I change to a different theme, the cursor goes back to the X default (you know, the old ugly ones).  If I enter the 'customize' menu, the current selection is still 'industrial'.  If I choose another cursor theme and go back to industrial, pretty cursors come back.

I can't see the crash either, but I can see the cursor switch to X when going to chlorphyll.  

Also by default my theme seems to be "custom".  Perhaps the "Default Pointer" selection is not pointing to the right spot?

I don't see the crash or the pointer going to X. My theme is "custom" by default, but I think that's because I've customized it previously.

Ok, I've unraveled this now. Restating the problem as I've understood it:

When you select a pre-defined theme, the mouse pointer set ("cursor theme") is set to the default X internal set of pointers, which is ugly. We want to use the Industrial pointer set (or another nice pointer set) instead.

Here's how it works:

When gnome-appearance-properties loads the themes, it looks in each theme's index.theme file ($PREFIX/share/themes/$THEME_NAME/index.theme), in the section [X-GNOME-Metatheme] for two key/value pairs - "CursorTheme=%s" and "CursorSize=%d". These are theme names and sizes, like the ones you can configure in the mouse pointer specific configurator.

When the theme is chosen in gnome-appearance-properties, it sets a gconf key /apps/desktop/gnome/peripherals/mouse/cursor_theme to the value of the theme's CursorTheme, or "default" if the theme didn't specify any. There's another key in the same path, called cursor_size, which corresponds to CursorSize (it too has a fallback default if the theme doesn't specify any).

The gnome-settings-daemon daemon picks up the gconf key changes and sets X properties corresponding to the keys - the properties are called "Gtk/CursorThemeName" and "Gtk/CursorThemeSize". These are then picked up by GTK and used to tell X what cursors to display. I'm not sure, but the actual cursor set loading seems to happen in X, prompted by XcursorSetTheme() and XcursorSetDefaultSize() calls in GDK.

The cursor theme is loaded from files in $PREFIX/share/icons/$CURSOR_THEME_NAME/cursors/. If the cursors are not found there, X will fall back to its default ugly set. As mentioned earlier, if the theme's index.theme does not specify a CursorName, gnome-appearance-properties will just set the gconf key to "default". This value ultimately ends up as $CURSOR_THEME_NAME in the path above. The resulting path does not exist.

And now, the problem:

None of our themes seem to specify CursorTheme and CursorSize in their index.theme, so when you pick a theme, you always get the defaults and the missing path.

There are three potential solutions that I see:

1) Patch gnome-appearance-properties to use one of our cursor themes instead of "default" as the default value. E.g. "Industrial".

2) Softlink /usr/share/icons/default to e.g. /usr/share/icons/Industrial.

3) Add the missing entries to our themes.

I think 3) is the cleanest, but also the most work. 2) has some potential for unintended side effects, but is easy to do. 1) is nasty, and the "default" string has to be updated in more places than you'd think.

Answering the additional question: Why are we getting the Industrial cursor theme in GDM and up until running the appearance applet?

In new environments, the gconf key is there, but it's not set to any value, so no particular cursor theme is requested by GTK. However, the env var XCURSOR_THEME=Industrial is set in the user's session, and libXcursor has code that looks for this env var and sets the theme accordingly as a default.

The XCURSOR_THEME env var is set prior to running the display manager from the /etc/init.d/xdm script, by sourcing /etc/profile.d/desktop-data.sh where it lives. desktop-data.sh in turn sources /etc/sysconfig/windowmanager and sets XCURSOR_THEME to whatever its X_MOUSE_CURSOR var is set to. As shipped, X_MOUSE_CURSOR=Industrial.

When the gconf key is set to "default", this makes GTK request the theme "default", and apparently, Xcursor falls back to the core X cursors instead of XCURSOR_THEME.

So maybe the bug is actually in libXcursor (part of xorg-x11-libs). It would make sense to have it fall back to what's set in XCURSOR_THEME when it can't find the requested theme.

I've discovered that libXcursor does fall back, to the hardcoded theme called "default", which would reside in /usr/share/icons/default/. So maybe the softlink proposal I made as option 2) in comment #7 is right after all.

The question is, which package should own this symlink? desktop-data-SuSE, perhaps? It installs the theme /usr/share/icons/DMZ/, which is a cursor-only theme (actually the cursor looks like Industrial's).

Possibly related bug in Debian's bugzilla (note that it's pretty old):

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=362766

Their solution was a symlink.

@Stefan: Since this is somewhat X-related, JP suggested that I ask for your input on this. Does the /usr/share/icons/default -> DMZ symlink look like a good solution to you?

Yes, let's do the symlink.

CC'ing KDE team to vet the symlink solution as well.

I've had a change to look at the latest Ubuntu build (2007-10-02) now, and they use the symlink approach as well, albeit with more sophistication. On Ubuntu, /usr/share/icons/default/index.theme is a symlink to /etc/alternatives/x-cursor-theme, which is a symlink to /usr/share/icons/DMZ-White/cursor.theme, which contains one directive meaning "inherit from the DMZ-White theme". libXcursor will thus end up getting its cursors from /usr/share/icons/DMZ-White/cursors/.

Their "alternatives" approach is for configuration purposes. If we use a fixed symlink, we will essentially be setting a system-wide default. In a perfect world, the X_MOUSE_CURSOR variable in /etc/sysconfig/windowmanager should control where this symlink points to.

JPR wants some feedback from kde-maintainers on this one before it goes in, just to make sure we don't break any of your stuff.

[16:57] <dirk_> jpr: what is the proposed solution? add the symlink?
[16:57] <dirk_> jpr: add it to which package?
[16:57] <dirk_> jpr: I don't see why we can't use the update-alternatives for it like ubuntu does
[16:58] <dirk_> jpr: and what does the syncing of the sysconfig setting to the symlink?
[16:58] <dirk_> it doesn't make sense that you default to "default" if default doesn't exist, and default is configured via sysconfig and not via a default symlink

I'd like to add the symlink linking /usr/share/icons/default -> DMZ. The
alternatives stuff is something to think about for the future, but probably not
something we'd want to do for 10.3 at this point. The symlink will live in
desktop-data-SuSE.

@coolo: Can I get a SWAMP ID for submission to 10.3?

@ast: Can I get a SWAMP ID for submission to 10.3?

Can someone please explain me why this bug report is (still) critical? I wouldn't rate it higher than minor (also considering that there is an easy work-around available) and it doesn't justify an online update imo.

If you really think that you have to patch this for the released product I would suggest to go with 1) and do 3) as the long-term proper fix.

I set this bug to Critical because the original report specified that something was segfaulting, as I stated in Comment #2.  Then again, nobody has subsequently been able to reproduce the crash, and I'm not sure from hpj's analysis above whether the problem he found explains the originally reported crash.  Perhaps he can clarify the circumstances in which a crash might be expected.

Based on all the comments, moving to 11.0.
HPJ, please close the bug if it's been fixed.

This bug is no longer about the crash, but deals with the default cursor selection. I'm not sure if it's still valid on 11.0, will check.

This still happens for 110 b1.

Confirmed.

Since the default system-wide cursor theme is settable in Yast (see desktop-data-openSUSE.fillup, which specifies the X_MOUSE_CURSOR setting), I think it should be Yast's responsibility to create the /usr/share/icons/default symlink and link it to whatever icon theme is specified by X_MOUSE_CURSOR.

If we don't want to modify files in /usr, we could do something like this:

/usr/share/icons/default -> /etc/sysconfig/cursor-theme
/etc/sysconfig/cyrsor-theme -> /usr/share/icons/$X_MOUSE_CURSOR

The former symlink would be static and owned by desktop-data-openSUSE, while the latter would be maintained by Yast scripts.

Setting component to YaST2. YaST2 team: Does this sound ok to you? Where do I make the change to set the symlink?

YaST2 maintainers: Ping.

yast2-maintainers@suse.de is a mailing list. Setting NEEDINFO to that list is a sure way to bury a bug. If there is no specific person to answer a question, nobody will ever answer.

We don't do anything with cursor themes. We leave that kind of details to X11 and Qt.

yast2 sysconfig can edit any setting, not just X_MOUSE_CURSOR

Ok, I'll just install a symlink then.

Updated desktop-data-openSUSE with symlink submitted to STABLE.