Set the default cursor theme to breeze_cursors
ClosedPublic

Authored by fvogt on Nov 27 2018, 2:49 PM.

Details

Summary

Currently the cursor theme is not set by anything, so it's Adwaita by default.

Test Plan

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.
fvogt created this revision.Nov 27 2018, 2:49 PM
Restricted Application added a project: Plasma. · View Herald TranscriptNov 27 2018, 2:49 PM
fvogt requested review of this revision.Nov 27 2018, 2:49 PM
ngraham accepted this revision.Nov 27 2018, 2:51 PM
ngraham added a subscriber: ngraham.

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

This revision is now accepted and ready to land.Nov 27 2018, 2:51 PM

Can you land this on the stable branch?

This revision was automatically updated to reflect the committed changes.
wbauer added a subscriber: wbauer.EditedNov 27 2018, 9:03 PM

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.

fvogt added a comment.EditedNov 27 2018, 9:15 PM

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.

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 :-/

wbauer added a comment.EditedNov 28 2018, 9:25 AM

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.

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.

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.

fvogt added a comment.Nov 28 2018, 9:40 AM

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.

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...)

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.

wbauer added a comment.EditedNov 28 2018, 4:21 PM

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.

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 ...

fvogt added a comment.Apr 5 2019, 8:26 AM

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.

Thanks Fabian!