Version: (using KDE 4.3.2) Installed from: Debian testing/unstable Packages Steps to Reproduce: Cursor themes needed - Whiteglass (Comes with 'xcursor-themes' package in debian and ubuntu), Oxygen (Comes with KDE). Other themes may cause this bug as well. 1. Set the default X cursor theme to Oxygen. (In Debian, `update-alternatives --config x-cursor-theme` can be used, elsewhere edit '/usr/share/icons/default/index.theme') 2. Select whiteglass as your cursor theme using Systemsettings. 3. Notice that some of the cursors are loaded from Oxygen instead of from Whiteglass. E.G. Oxygen's wait cursor is shown instead of Whiteglass' watch cursor. Cause: QT uses some non-standard names for standard cursors. To handle this issue, if XCursorTheme::loadCursor fails to load cursor using given name, it tries to load cursor with matching standard name. The conversion is done in XCursorTheme::findAlternative. The problems start when the default theme contains cursor named in QT convention. When XcursorLibraryLoadImages can't find the requested cursor in the requested theme, it looks for it in the default theme [1]. In our case, the QT named cursor is successfully loaded from the default theme, so loadCursor doesn't even try to load the standard named cursor from the selected theme. Workaround: Set the selected theme as the default them. Solution: I dunno. [1] see XcursorSetTheme man page, section "FUNCTIONAL OVERVIEW"/"THEMES" or xcursor's source code (http://cgit.freedesktop.org/xorg/lib/libXcursor/tree/src/library.c#n293)
I can confirm this bug in Kubuntu Lucid with KDE 4.4 rc2 (it started with rc1), worked ok in beta2 and before. very nasty one and major regression. im attaching a png that ilustrates the problem.
using update-alternatives --config x-cursor-theme to change the theme for something else non-qt , in ex whiteglass fixes systemsettings, since it can now look for the correct names in the selected theme. maybe this bug is an oxygen mouse theme bug?
Recently upgraded to 5.11. Mouse cursor theme was (re)changed to KDE Classic, however it only half-works. Whenever the cursor is over firefox, thunderbird, gedit (GTK apps?) It's always 10x larger as the default Breeze theme provides. I have a high-DPI(4k) screen so the default cursor selected is ginormous. If I change the theme during a session it will work in most places until I log out and in again then its a mishmash again.
I recently tried out other cursor themes (by installing them with Discover) and noticed that I have a similar problem: The cursor theme is changed for the desktop and every window but Mozilla Firefox and Mozilla Thunderbird. For other GTK apps like Gedit or Gparted is works fine. I use openSUSE-Tumbleweed with Plasma 5.11.5.
I reassign the bug to Component "general" because the Mouse Cursor Theme (cursortheme) does not belong to the Mouse KCM and there is no Component for cursortheme.
Reassigned back. We have several other tickets for the mouse cursor assigned here. Historically, both modules were part of the same KCM code.
Can confirm today with current code as of git master.
Actually on further investigation, I was experiencing Bug 382604. For people experiencing this, does the problem go away if you restart KWin, log out and back in again, or restart the computer?
Dear Bug Submitter, This bug has been in NEEDSINFO status with no change for at least 15 days. Please provide the requested information as soon as possible and set the bug status as REPORTED. Due to regular bug tracker maintenance, if the bug is still in NEEDSINFO status with no change in 30 days the bug will be closed as RESOLVED > WORKSFORME due to lack of needed information. For more information about our bug triaging procedures please read the wiki located here: https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging If you have already provided the requested information, please mark the bug as REPORTED so that the KDE team knows that the bug is ready to be confirmed. Thank you for helping us make KDE software even better for everyone!
This bug has been in NEEDSINFO status with no change for at least 30 days. The bug is now closed as RESOLVED > WORKSFORME due to lack of needed information. For more information about our bug triaging procedures please read the wiki located here: https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging Thank you for helping us make KDE software even better for everyone!