Bug 213615 - Some cursors are loaded from the default theme instead of the selected one
Summary: Some cursors are loaded from the default theme instead of the selected one
Status: RESOLVED WORKSFORME
Alias: None
Product: systemsettings
Classification: Applications
Component: kcm_cursortheme (show other bugs)
Version: unspecified
Platform: Debian testing Unspecified
: NOR normal
Target Milestone: ---
Assignee: Marie Loise Nolden
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2009-11-08 00:13 UTC by Guy Shapiro
Modified: 2020-02-10 04:33 UTC (History)
8 users (show)

See Also:
Latest Commit:
Version Fixed In:
Sentry Crash Report:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Guy Shapiro 2009-11-08 00:13:23 UTC
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)
Comment 1 Paulo Dias 2010-01-25 20:17:33 UTC
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.
Comment 2 Paulo Dias 2010-01-25 20:29:44 UTC
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?
Comment 3 EkriirkE 2015-07-24 06:44:15 UTC
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.
Comment 4 Gregor Mi 2018-02-04 09:10:19 UTC
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.
Comment 5 Gregor Mi 2018-02-04 09:16:32 UTC
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.
Comment 6 Christoph Feck 2018-02-05 18:55:44 UTC
Reassigned back. We have several other tickets for the mouse cursor assigned here. Historically, both modules were part of the same KCM code.
Comment 7 Nate Graham 2020-01-11 19:23:11 UTC
Can confirm today with current code as of git master.
Comment 8 Nate Graham 2020-01-11 19:37:03 UTC
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?
Comment 9 Bug Janitor Service 2020-01-26 04:33:12 UTC
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!
Comment 10 Bug Janitor Service 2020-02-10 04:33:15 UTC
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!