-
-
Notifications
You must be signed in to change notification settings - Fork 1.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Detect theme variant for Gnome and KDE #3414
Conversation
- For Gnome, read values from `gsettings` to get the color-scheme (can be prefer-dark, prefer-light or "default" - For KDE, read the kdeglobals file and calculate the brightness if the theme is not the standard one - this method can also be applied for older Gnome version reading GTK themes, but is this useful? - Theme change detection: - Gnome: connect to dbus and wait for theme change - KDE, no idea at this time, but switching from KDE to Gnome has changed the Gnome theme... So maybe KDE is using dbus too.
Would it, by any chance, be possible to stick to only the BDus values mentioned in #2657? It seems less elegant and more prone to error if we should parse files specific to KDE or Gnome. The issue in question mentions a new standard and I think it would be wise to instead only rely on that. This way we reduce the risk of weird issues if the structures of the files we are parsing change in the future |
I would think that this should be the first method tried. As a fallback and due to the large number of old os supported by fyne, we need to still try the files.
The file structure shouldn't massively change as this could also a problem for the application that exist today and use this file. |
I can avoid to use There are 2 possibilities:
As @Bluebugs mentioned, KDE didn't change the structure of the file, and will not for a while. Using only DBus drastically reduces the code size. But KDE will not be supported. And AFAIK, it could be for a long time... KDE is not famous to quickly follow the standards. BTW: KDE is messy, and it changes the Gnome/GTK theme each time I use it – it does this to ensure that GTK apps will match the Breeze theme (or whatever the theme you choose on KDE preferences). That means that each time I switch my session, and I'm back to Gnome, it changed the icon theme, the color theme, add window buttons, and many changes... It's exhausting, annoying, clearly not a behavior I appreciate. So, my opinion now: I personally prefer to use DBus with standard freedesktop values, because it's standard... Now, what are the Fyne rules? Do we accept "default dark theme" for KDE and wait them to respect the standards? I don't have the power to decide 😉 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is excellent, thanks so much.
The SetTheme
needs to be changed though, as it will override developer settings.
This is so cool, thanks :)
This would be my preference - but as you say it will not work for KDE for some time... so maybe the KDE code needs to remain. |
So, for now, I will leave the code like this (with changed you asked)
Actually, I made this detection very recently. Months ago, I prepared themes for Gnome variants and KDE/Plasma:
I decided to not reimplement the Gnome theme reading with I really don't know if I should take some parts of what I did in fyne-x, or if I should use DBus value only for Gnome and remove the KDE specific case later. In any case, I've got solutions. The hard part is to decide. |
To complete the answer, I can do (for Gnome): Solution 1: Solution 2: Solution 3: |
I am quite certain that I have read somewhere that KDE Plasma actually support the dark style preference. A quick Google search did also seem to indicate that it is the case: https://www.reddit.com/r/kde/comments/rwizt0/freedesktop_dark_style_preference_for_kde_apps/ |
I made many tests to check – when I select the light/dark theme in KDE / Plasma on Fedora 36, it doesn't change anything on the DBus property. It changes the kdeglobals file, it breaks Gnome theme by forcing GTK and icon theme, but the DBus property is still set to the same value. Maybe it changed in Fedora 37 (I didn't upgrade yet), but at this time, it's not the case. So, I wonder what to do. If I only use this DBus variable, newest KDE will be OK and Gnome will be OK. But, previous KDE version will not respond. Because it's only to detect the variant, that is not a breaking feature, and because the color-scheme variable in DBus is the "correct" way to decide... Should we not, finally, leave the previous behavior for desktop manager that are not yet ready to use it? And so, leave the previous behavior (dark theme by default) for them? I mean, the decision could be:
This will simplify the source code too. |
I am personally leaning more to what you are describing above. I’d be interested in what the others think of it |
Actually, if we change the behavior by what I described, the functions should be renamed to "XXXFreedesktop" - that will not be specific to Gnome or KDE 😄 |
Sounds like a good plan to me too. |
I will change source code in a few minutes/hours, if it's not OK for @andydotxyz I can revert. |
I am happy to go with the consensus here - we can always iterate as we get user feedback. |
- Gnome already makes use of color-scheme from freedesktop portal settings - KDE should provide the value in current and next version - waiting for it: fallback to dark theme variant - For all others desktop managers, fallback to dark theme variant
The variant should be calculated by the work made at fyne-io/fyne#3414 So, we can now only get colors and icons from the applied theme in Gnome or KDE.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks. I annoyed a few minor things that can be tidied up but it is getting very close
app/app_xdg.go
Outdated
case 1: | ||
return theme.VariantDark |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't think you need three cases here. You can remove "1" case, and just add a comment that dark is a one, then let it be caught by the default
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Right, I wondered if that was interesting for the reading. I can change.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I just tested this on Fedora 36 with Gnome 42 and it does not seem to work. Nothing happens when I change between light and dark mode. The app just always use the dark mode no matter what preference I set in the settings
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I now retested after having upgraded to Fedora 37 and Gnome 43. It works flawlessly. I don't know why I did not see it working before. Nice work 🙂
Just found a few last notes. Should be very close to landing 👍
app/app_xdg.go
Outdated
|
||
var value uint8 | ||
if err = call.Store(&value); err != nil { | ||
log.Println("failed to read theme variant from D-Bus", err) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
log.Println("failed to read theme variant from D-Bus", err) | |
fyne.LogError("Failed to read theme variant from D-Bus", err) |
app/app_xdg.go
Outdated
dbus.WithMatchInterface("org.freedesktop.portal.Settings"), | ||
dbus.WithMatchMember("SettingChanged"), | ||
); err != nil { | ||
log.Println(err) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Let's use fyne.LogError
here as well.
app/app_xdg.go
Outdated
func watchFreedekstopThemeChange() { | ||
conn, err := dbus.SessionBus() | ||
if err != nil { | ||
log.Println("Unable to connect to session D-Bus", err) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Let's use fyne.LogError
here as well.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Works great. Thanks for working on this. It will make Fyne applications work so much better on Linux :)
@andydotxyz Did we decide that it was fine to merge this even though we are in a feature freeze? I have a vague recollection of talking about that but I can't remember. |
Yes I think it's good - "bug fixes" still allowed and this is technically one. Though an epic one 😀 . |
Great. You still have required changes. Feel free to review and merge if you feel that it is ready :) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Great thanks
The variant should be calculated by the work made at fyne-io/fyne#3414 So, we can now only get colors and icons from the applied theme in Gnome or KDE.
Description:
This detects theme variant for Gnome and KDE.
gsettings
to get the color-scheme (can be prefer-dark, prefer-light or "default"Checklist: