When I change my cursor theme, the previous cursor is still active in many parts of my system/programs. Some menu bars and window decorations, for example, shows the previous cursor on mouseover until plasma session is restarted. I use Plasma 5.10.4 on Arch.
Is this still happening?
yes, it's still happening on X11. Wayland session requires relogin to apply a new cursor theme. On X11 changing the cursor theme only takes effect immediately on plasma panel, widgets placed on panel/desktop, apps launcher and window decorations. If you hover over the files list of Dolphin or the text area of Kate, for example, you see the previous cursor until relogin. Operating System: KDE neon Unstable Edition KDE Plasma Version: 5.16.80 KDE Frameworks Version: 5.61.0 Qt Version: 5.12.3
Information was provided with comment #2; changing status.
Changing cursor size also is not immediately applied to the whole system. I see the cursor of the previous size on mouseover my wallpaper until plasma session is restarted. Operating System: Arch Linux KDE Plasma Version: 5.17.1 KDE Frameworks Version: 5.63.0 Qt Version: 5.13.2
Looks like restarting just KWin is enough actually. Moving to KWin.
*** Bug 371059 has been marked as a duplicate of this bug. ***
*** Bug 347471 has been marked as a duplicate of this bug. ***
For me changing cursors only affects applications running while it is changed. Newly started applications use the old cursor theme. kcminputrc shows the new cursor theme though
*** Bug 414109 has been marked as a duplicate of this bug. ***
Created attachment 125613 [details] Cursors KCM on Wayland Watch the following screen recording please. https://www.youtube.com/watch?v=_EI4kxS63Ko I change from red cursor theme to the yellow one. Cursor is still in red when I hover over the following areas: - wallpaper - the header of Cursors kcm - "hard disk i/o monitor", "network monitor" and "thermal monitor" widgets - any part of "weather report" and "hard disk space usage" widgets but their blue bars Then I restart kwin and the cursor becomes correct (yellow) when I hover over the areas mentioned above. But newly started apps Dolphin and Kinfocenter are still showing the previous red cursor when I hover over any part of them but their window decoration. As we can see in my screen recording, restart kwin is not enough. Relogin is the only way to apply another cursor theme to the whole system on X11. If it's hard to solve this ancient and annoying bug, I think that Cursor kcm could definitely stop trying to apply the cursor theme without relogin and adopt the same behavior that already occurs on Wayland. On Wayland, Cursors kcm shows a warning saying that relogin is required for the cursor theme change to take effect, as we can see in the attached screenshot. Operating System: Arch Linux KDE Plasma Version: 5.17.90 KDE Frameworks Version: 5.66.0 Qt Version: 5.14.1
I can confirm the same bug on the same Plasma version. This workaround: https://wiki.archlinux.org/index.php/KDE#Plasma_cursor_sometimes_shown_incorrectly solves the problem for me, but it's that, a workaround. An end user shouldn't be expected to do this.
*** Bug 423074 has been marked as a duplicate of this bug. ***
Can still reproduce. The Plasma desktop, panel, and applets seem to not notice the new cursor until plasmashell is restarted.
*** Bug 425451 has been marked as a duplicate of this bug. ***
*** Bug 404383 has been marked as a duplicate of this bug. ***
I think I figured out what causes this! According to wbauer on this page: https://phabricator.kde.org/D17187 The 'startkde' (which is now 'startplasma-x11' or 'startplasma-wayland') program sets the XCURSOR_THEME environment variable, and applications will always use the value of that environment variable until they're told otherwise. When you switch themes while logged in, you're telling existing applications to use another theme on the fly, and most will do so! But launch a new application, and it'll use the old original theme! The XCURSOR_THEME environment variable is meant to be used to override all other settings temporarily, when starting an application. The fix should simply be to remove the line(s) of code from 'startplasma-x11' that sets that environment variable.
It looks like the code was ported to C++ from a bash script. The relevant code is here: https://invent.kde.org/plasma/plasma-workspace/-/blob/master/startkde/startplasma.cpp This was done in this commit: https://invent.kde.org/plasma/plasma-workspace/-/commit/5df9f0bcc9259e595d97d0e55399753325f7a010#31c42a873c0b74c54dc71f1f4a2ca9a6f7643718 And the code was just copied mostly without changing what it actually did, which is why the behavior didn't only start happening in 2019. For that, I had to dig REALLY far back... And eventually found this in the old SVN repository: https://websvn.kde.org/?view=revision&revision=396433 And in particular, here: https://websvn.kde.org/trunk/KDE/kdebase/startkde?r1=396411&r2=396433&pathrev=528175 Way back on March 10th, 2005. It looks like the reason the environment variable was set back then was for kded and ksmserver. Is this still the case today? It seems like code that old working around problems in other packages (albeit other KDE packages) might not even be relevant anymore, and so safe to pull out. Additionally, I don't have KDE's source code installed on my drive, so I can't actually try changing this, compiling, and testing... Hence just talking on this bug report instead. It could be that this isn't at all related to the bug we're experiencing, and I just went on a wild goose chase for nothing. Still, it would explain the current behavior for the most part.
Interesting observations, Colin. Please feel free to try compiling and testing your proposed fix. You don't need all KDE repos, just plasma-workspace. Here's the documentation: https://community.kde.org/Get_Involved/development
*** Bug 429947 has been marked as a duplicate of this bug. ***
Can still reproduce for the desktop and empty areas of the panel too--though not actual panel applets, interestingly enough. Since restarting plasmashell seems to fix it, this appears to be a matter of the panel and desktop only checking for cursor size on launch, not watching for size changes in real time.
*** Bug 435682 has been marked as a duplicate of this bug. ***
*** Bug 439126 has been marked as a duplicate of this bug. ***
*** Bug 439439 has been marked as a duplicate of this bug. ***
How to reproduce on X11: - log in to KDE Plasma (I happen to have 5.23.5 with Frameworks 5.90) - alt-space, type "cursor", pick from the "System Settings" category "Cursors" - click on, say, "Oxygen Blue" and then from the size drop-down, pick 48. - click "Apply" - mouse cursor is now big and blue over every application window, but not the background wallpaper. Cursor is also big and blue over **nearly** all of the Plasma panel, but there's a strip about 2px tall (I have a vertically-arranged panel) between the system-tray part and the clock. Perhaps that is an "empty area" on the panel and the rest of my panel is occupied with "things". There's a much simpler way to reproduce, though, using the `plasma-apply-cursortheme` executable (I don't know if that is installed everywhere though), - `plasma-apply-cursortheme redglass` (applies redglass, notice that everything gets it except the wallpaper and bits of the panel) - `plasma-apply-cursortheme breeze_cursors` (applies the standard Breeze theme)
Related MR (it adds some things to the CLI tool, doesn't fix any of the actual issues): https://invent.kde.org/plasma/plasma-workspace/-/merge_requests/1483 Workaround to get plasma to set new cursors on the wallpaper (but not on the "occupied" areas of the panel, which now get a plain cursor not related to any of my recent cursor-theme-selections): - `plasma-apply-cursortheme redglass` - `qdbus org.kde.plasmashell /PlasmaShell refreshCurrentShell` This is a very "heavyweight" way to tell Plasma to reload things. Related to XCURSOR_THEME: if I alt-space "xterm" to run Xterm, it has XCURSOR_THEME set to "KDE_Classic", which was true when I logged in. The CLI tool creates a `UpdateLaunchEnvJob` which is documented to update the launch environment, but doesn't seem to do anything.
Experimenting with environment variable XCURSOR_THEME. - Log into KDE Plasma, start Konsole - `echo $XCURSOR_THEME` shows me `KDE_Classic` (which was my cursor theme when I started) - From that konsole, `konsole &` and in that (new) konsole, `echo $XCURSOR_THEME` shows `KDE_Classic` (this is expected, environment passed on from the shell in konsole). Notice that mousing over the new konsole shows the KDE Classic cursor theme. - From that konsole, `XCURSOR_THEME=redglass konsole &` and in that konsole notice it shows redglass. Together this shows that starting Konsole from the command-line makes it obey the XCURSOR_THEME environment variable. - Use dbus to get KLauncher to launch a new konsole: `qdbus-qt5 org.kde.klauncher5 /KLauncher exec_blind konsole ""` .. notice that Konsole has XCURSOR_THEME set to `KDE_Classic` (because that's what I had when I logged in) - Use dbus to tell Klauncher to use a different environment: `qdbus-qt5 org.kde.klauncher5 /KLauncher setLaunchEnv XCURSOR_THEME Oxygen_Yellow` - Then use dbus to launch a new konsole again (same command) and notice it comes up with Oxygen Yellow as cursor theme and has XCURSOR_THEME set as expected. - Then use KRunner to start Konsole, e.g. alt-space, type "konsole". Notice it has KDE_Classic. - Then use the K-Menu to start Konsole. It too has KDE_Classic. So far, we've seen that Konsole follows the XCURSOR_THEME set in the environment when it is started. Also that KLauncher can modify the environment it uses to launch applications. Also that KRunner is not KLauncher, and uses some **other** notion of environment. (This can be similarly demonstrated by starting kwrite, changing the theme, then starting another kwrite which gets the old theme).
*** Bug 457771 has been marked as a duplicate of this bug. ***
For some time (2 weeks maybe, I'm not sure) I face similar issue. Sometimes displayed cursor is not the one I set in system settings. It happens in a few places: - when I put mouse cursor on screen edge that has action defined, - when I right click in Firefox, - when I middle click in Firefox, those are just from the top of my head. It is not related to cursor theme change. I tried to change theme and it is stable until next start of plasma. After restart problem returns. It happens for both KDE-installed themes and 3rd parties. Workaround from https://wiki.archlinux.org/index.php/KDE#Plasma_cursor_sometimes_shown_incorrectly helps. If you consider this a separate bug just let me know and I'll create a new report. I use fully updated Arch Linux which means plasma 5.25.5.
A possibly relevant merge request was started @ https://invent.kde.org/plasma/plasma-workspace/-/merge_requests/2671
A possibly relevant merge request was started @ https://invent.kde.org/plasma/plasma-workspace/-/merge_requests/2672
Still an issue in Plasma 6.
As of today's git master in Plasma 6, I can confirm that this is now fixed!