Currently the cursor theme is not set by anything, so it's Adwaita by default.
Details
New user account has "Breeze" as cursor theme in kde-gtk-config.
Diff Detail
- Repository
- R98 Breeze for Gtk
- Lint
Automatic diff as part of commit; lint not applicable. - Unit
Automatic diff as part of commit; unit tests not applicable.
Oh gosh, so this is where that bug comes from. I've seen new users get really confused by this the first time they open up Firefox. +1
Actually, if the cursor theme is not set to anything, GTK would just use the session's default. I.e. this patch should not be necessary in the first place.
But at least in openSUSE, the cursor theme is explicitly set to Adwaita in the system-wide GTK config, /etc/gtk-3.0/settings.ini . That is what caused GTK3 applications to use Adwaita by default.
If it is set though, the default is different for GTK and Qt in a Plasma session, which can be surprising and this patch explicitly avoids that.
But at least in openSUSE, the cursor theme is explicitly set to Adwaita in the system-wide GTK config, /etc/gtk-3.0/settings.ini . That is what caused GTK3 applications to use Adwaita by default.
That should really be changed IMO. Plasma can unfortunately not rely on sane GTK configs/packaging :-/
OTOH, this patch actually causes a mismatch if one changes the cursor theme in Plasma's cursor theme KCM. (it won't affect GTK applications, they will continue to use breeze...)
The same happens already if one uses the GTK KCM though, as it will always write a cursor theme entry too.
Plasma can unfortunately not rely on sane GTK configs/packaging :-/
Agreed.
TBH, I don't see a point at all to configure the mouse cursor theme in the toolkit's settings, but that's not our decision anyway.
OTOH, this patch actually causes a mismatch if one changes the cursor theme in Plasma's cursor theme KCM. (it won't affect GTK applications, they will continue to use breeze...)
There is no sync in any direction of icon themes, cursor themes and application themes, which makes it all a bit cumbersome.
The same happens already if one uses the GTK KCM though, as it will always write a cursor theme entry too.
Yes, that can be unexpected - even by not changing the cursor theme explicitly, it can make a difference. In that way this patch makes it more predictable.
That's a pre-existing bug: https://bugs.kde.org/show_bug.cgi?id=401507
(See also https://bugs.kde.org/show_bug.cgi?id=138866 and https://bugs.kde.org/show_bug.cgi?id=400101)
Ideally we wouldn't need a GTK KCM at all because the other KCMs would change the appropriate GTK settings at the same time as the KDE settings.
That's not the full truth though.
The cursor theme KCM will affect the default theme of the whole session.
I.e. it actually will affect non-KDE applications too, unless they explicitly use a different one.
startkde (or startplasmacompositor on Wayland) reads the setting and sets the corresponding environment variable (XCURSOR_THEME)
Ideally we wouldn't need a GTK KCM at all because the other KCMs would change the appropriate GTK settings at the same time as the KDE settings.
I'm not sure that's a good idea in every case though.
E.g. there likely won't be the same widget styles installed for Qt5, GTK2, and GTK3... Especially since GTK3 dropped support for theme engines like Oxygen or QtCurve.
Anyway, I mainly wanted to point out where the wrong cursor theme in GTK3 applications actually comes from. Explicitly setting it in the default GTK configs should normally not be necessary at all, unless there's a system-wide config that sets it already. As we cannot influence the latter, it's probably better to do it anyway though.
Regarding this, I'd probably add a "Default" entry that is pre-selected when no cursor theme is set in the config, and would not write a gtk-cursor-theme-name line when saving.
Btw, It seems the gtk-cursor-theme-name option actually has no influence on GTK2 applications, so it probably wouldn't need to be written to the GTK2 config here.
But then, the KCM does save it to the GTK2 config as well...
I just noticed that this change is missing again in 5.15.
Apparently it was reverted (by mistake?) in R98:e1f97ce5 ...
I cherry-picked and pushed it again, it doesn't look like anything else got missing fortunately. I checked a few commits around the lost one and all of those changes were in 5.15.