To reproduce: 1. Log into a XFCE session. 2. Log out. 3. Log in again. The cursor theme is reset to X defaults in many places, at least when the mouse hovers on the window border. I have tested the "log in" part in my description with gdm and startx (.xinitrc: exec dbus-launch ck-launch-session startxfce4). In both cases the bug can be reproduced.
Possible duplicate of bug 6854
I can confirm this bug when using mdm for login (Linux Mint 13). The cursor theme seems to be the default when hovering over the desktop at least. When hovering over some applications (Opera for instance) the right theme is still shown. The bug seems to occur not after every login. When switching my theme again it is somethign like 50:50 that it is remembered after reboot. The bug occured after some update in the last weeks (xubuntu-dev/xfce-4.10 PPA active). There was no problem with cursor themes before (running this system since July).
This is an issue with the root cursor. This is fixed in lightdm-gtk-greeter 1.9.0 and can be addressed similarly in other applications (gdm, mdm, etc) with this (either in the code or adding to ENV) https://bazaar.launchpad.net/~thad-fisch/lightdm-gtk-greeter/lp-1024482/revision/284 If you run Ubuntu, this fix can be tested in Utopic.
I can reproduce this issue which appears to be the result of a race condition. The first session start after a fresh boot is usually slower compared to later starts, and therefore does not seem to trigger this issue. Possible workaround: Create a simple wrapper script for xfwm4 to delay its launch (~1sec).
I'm facing this issue, too. The cursor theme is correct on Firefox and others, but in Xfce it stay the X defaults. I have to re-apply the theme to get it working. [thiagoc@ironhide ~]$ xrdb -q output Xft.autohint: 0 Xft.dpi: 96 Xft.lcdfilter: lcddefault Xft.antialias: 1 Xft.hintstyle: hintfull Xft.rgba: none Xcursor.theme: Vanilla-DMZ Xcursor.size: 0 Xcursor.theme_core: 1
I create a symlink to the icon theme on my home and it works: ln -s /usr/share/icons/theme .icons/default
I am also experiencing this issue now. I've never had it before, so the race condition explanation makes sense. (In reply to Thiago Coutinho from comment #6) > I create a symlink to the icon theme on my home and it works: > > ln -s /usr/share/icons/theme .icons/default How come this works?
Can also confirm this bug. I am experiencing the same behaviour as Thiago Coutinho mentioned in Comment 5. I use xfdesktop-4.12.3 but it is the same with 4.12.2.
I'm experiencing this bug on Arch Linux as follows: 1. restart system 2. console login as normal user 3. startx - mouse cursor theme is the default in some places like on the xfdesktop, xfce4-panel, in whisker menu(except its search textbar and hovering on an item in Favorites/Recently used), any window's titlebar and edges; - mouse cursor theme is correct(redglass) within xfce4-terminal window (except titlebar), in whisker menu search textbar and while hovering on items in Favorites/Recently used, anywhere within chromium(gtk theme) 4. logout from xfce 5. startx - mouse cursor theme is correct in all the places! - repeating steps 4&5 doesn't change anything. If ~/.icons/default/index.theme was set to something(other than redglass, let's say whiteglass) then that's the theme that you see in step 3. as being the "default" Comment 4 makes some sense but it kinda doesn't explain this: If as step 6. I remove index.theme then do step 4&5, I get the default theme again(from step 3), until I do step 4&5 again to fix it; after this fiddling with index.theme has no effect regardless of how many times I do step 4&5 - oddly enough. Comment 3 working url: https://bazaar.launchpad.net/~thad-fisch-deactivatedaccount/lightdm-gtk-greeter/lp-1024482/revision/284/src/lightdm-gtk-greeter.c I haven't try to patch it like that yet(I will now but if I don't mention it in the next comment it means it had no effect), but I did put that env var in .bash_rc with an export which means it was set before startx, but this had no effect on the issue. Replacing step 4&6 with re-applying theme(selecting another one temporarily, then selecting the redglass theme), works just like in Comment 5. Comment 6 is a partial workaround for me: the cursor theme is correct but its size is not - it's smaller than usual in those places where it would be the default theme. $ ln -s /usr/share/icons/redglass ~/.icons/default (in ArchLinux) redglass is my selected theme. ( pacman -S xcursor-themes ) local/exo-git 1:0.11.2.r1806.0cf234f-1 (xfce4-git) local/gtk-xfce-engine 2.10.1-1 (xfce4) local/libxfce4ui-devel 4.13.1-1 local/libxfce4util 4.12.1-1 local/xfce4-dev-tools-git 20150313-1 local/xfce4-panel 4.12.1-1 (xfce4) local/xfce4-session-git 4.12.0.r195.g0f1c3bb-1 (xfce4) local/xfce4-settings-git 4.13.0.r62.g4c30b30-1 (xfce4) local/xfce4-terminal 0.8.4-1 (xfce4) local/xfce4-whiskermenu-plugin 1.7.0-1 (xfce4-goodies) local/xfconf-devel 4.12.1-1 (xfce4) local/xfdesktop-devel 4.12.3-1 (xfce4) local/xfwm4 4.12.3-2 (xfce4) local/xfwm4-themes 4.10.0-2 (xfce4) local/xorg-xinit 1.3.4-4 local/xorg-xrdb 1.1.0-2 (xorg-apps xorg) local/xorg-server 1.19.2-1 (xorg) local/libxcursor 1.1.14-2 local/xcursor-themes 1.0.4-1 otherwise up to date Arch Linux x64 (the git and devel packages are what I switched to after first testing normal archlinux ones)
A slight correction, the above Comment 9 is only correct and reproducible that accurately, if ~/.icons/default/index.theme exists, and contains: [icon theme] Inherits=whiteglass otherwise, if the file doesn't exist, actually if the whole "default" dir doesn't exist (because it's renamed to default2 for example) then, the issue happens randomly like in Comment 2. So, simply doing Logout and startx, on and on, I get the issue almost every 2nd time. But not when ~/.icons/default/index.theme exists as above - then it's quite reproducible using the steps in the previous comment. Don't know where to apply patch from Comment 3 though - I'm not using lightdm or similar. (assuming the .bash_rc thing didn't have the same effect for some reason) Will not post any more until have fix:)
tl;dr: no fix yet; just more info. (In reply to Thaddaeus Tintenfisch from comment #4) > I can reproduce this issue which appears to be the result of a race > condition. If I remove xfsettingsd sudo pacman -R xfce4-settings-git then the theme is the default, whiteglass in my case, because ~/.icons/default/index.theme gets applied by something. So the race is between whatever applies index.theme (libxcursor?) and xfsettingsd trying to apply my redglass one. > > The first session start after a fresh boot is usually slower compared to > later starts, and therefore does not seem to trigger this issue. For me it's the opposite, the issue triggers only on the first startx and later on only if I fiddle with index.theme and even then only once apparently. I also tried the export GDK_CORE_DEVICE_EVENTS=1 (see Comment 3 ) in ~/.xinitrc before the line: exec dbus-launch xfce4-session >/tmp/.xfce4-session.log 2>&1 but this has no effect on the issue, and I checked it was set to 1 in xfce4-terminal. Note: xfsettingsd is in that list in Session and Startup -> Application Autostart and cannot be edited, unless directly editing the file itself: /etc/xdg/autostart/xfsettingsd.desktop Actually something else still starts xfsettingsd because I can remove it from that autostart list, even clear any saved sessions(or try to set it to Never start - it's always set to Immediately) and it still gets started by something. This way I cannot insert a nice 1 sec delay... Any ideas?
There are two other places that are starting xfsettingsd: /etc/xdg/xfce4/xfconf/xfce-perchannel-xml/xfce4-session.xml /etc/xdg/xfce4/xinitrc after neutralizing those, rebooted OS, confirmed xfsettingsd wasn't started by observing the lack of icons and the default mouse theme, then manually ran xfsettingsd from within xfce4-terminal and the theme was set correctly to redglass. So I restored the first place: /etc/xdg/autostart/xfsettingsd.desktop placed the 1 sec delay: Exec=sh -c 'sleep 1;xfsettingsd' and rebooted system, the issue is gone. Even better, removed the delay and the issue is gone! So, all these 3 places might be causing the race or something... Now that there's only one - no race. I'll check further tomorrow. 'night!
I stand corrected: it's not those 3 places causing the race. I rebooted OS again and even with only the autostart place I still got the issue (but it doesn't happen all the time, like it did in Comment 9 ). So I'm back to the 1 sec delay, workaround.
Created attachment 7043 the 1 sec delay start of xfsettingsd what I said above, in patches (it's only a temporary workaround that I'm currently using)
*** Bug 13382 has been marked as a duplicate of this bug. ***
-- GitLab Migration Automatic Message -- This bug has been migrated to xfce.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.xfce.org/xfce/xfce4-settings/-/issues/4. Please create an account or use an existing account on one of our supported OAuth providers. If you want to fork to submit patches and merge requests please continue reading here: https://docs.xfce.org/contribute/dev/git/start#gitlab_forks_and_merge_requests Also feel free to reach out to us on the mailing list https://mail.xfce.org/mailman/listinfo/xfce4-dev