Fixed a regression where Linux theme is not properly detected

[veler]

Pull request type

Please check the type of change your PR introduces:

• Bugfix
• New feature or enhancement
• UI change (please include screenshot!)
• Code style update (formatting, renaming)
• Refactoring (no functional changes, no api changes)
• Build related changes
• Documentation content changes
• Internationalization and localization
• Other (please describe):

What is the current behavior?

Issue Number: #1381

What is the new behavior?

Use DBus to retrieve the org.freedesktop.appearance parameter to detect the theme on Linux Mint, Ubuntu, Fedora.

Other information

Quality check

Before creating this PR:

• Did you follow the code style guideline as described in CONTRIBUTING.md
• Did you build the app and test your changes?
• Did you check for accessibility? On Windows, you can use Accessibility Insights for this.
• Did you verify that the change work in Release build configuration
• Did you verify that all unit tests pass
• If necessary and if possible, did you verify your changes on:
  • Windows
  • macOS
  • Linux

[CodedOre]

Looks good to me. On Fedora, the app now follows dark mode again, but the titlebar remains light:

Which I guess is to expected since GTK itself still doesn't know about the dark mode preference...

[badcel]

This looks good at a first glance. You should be able to remove the Gio initialization though.

I will try to test your change on my hardware and report back.

[badcel]

You can remove this line. This is part of the sample as the Gio.Module is not initialized automatically.

For Libadwaita and GTK applications this is done automatically via the Gtk.Application class for all GTK dependencies including Gio.

• Gtk.Application calls Gtk.Module.Initialize
• Gtk.Module.Initialize calls Gdk.Module.Initialize
• Gdk.Module.Initialze calls Gio.Module.Initialize

[badcel]

@CodedOre Thanks for testing then I will skip the testing on my side.

Making the title bar dark should be possible, too.

[CodedOre]

Looking through the docs, I think setting the gtk-application-prefer-dark-theme property should work?

Though I haven't tried that yet.

[badcel]

@CodedOre Yes this works, tested on fedora 40 with:

var application = Gtk.Application.New("org.gir.core", Gio.ApplicationFlags.FlagsNone);
application.OnActivate += (sender, args) =>
{
    var window = Gtk.ApplicationWindow.New((Gtk.Application) sender);
    window.Title = "Gtk4 Window";
    window.SetDefaultSize(300, 300);
    window.GetSettings().GtkApplicationPreferDarkTheme = true;
    window.Show();
};

return application.RunWithSynchronizationContext(null);

So setting GtkApplicationPreferDarkTheme to true seems to be the right thing to do.

@veler It should work if you use the Gtk.Settings you already have around in your code. No need to get the Window object involved.

[badcel]

I think Gtk.Settings.GtkApplicationPreferDarkTheme should not be used as a fallback decider for the preferred theming mode. This is implied by the linked docs of @CodedOre, too.

I think it is more meant as an "application level setting" defining the developers preference of either a dark or light theme. E.g. in GNOME there are apps, which use a dark theme, even if the user chooses to have a light theme. This is the case for media related apps like video players. I think those apps set this setting to indicate that they prefer a dark theme over the user choise.

And If your code detects, the user wants to use a dark theme you set this property to true to adhere to the users wish resulting in a dark titlebar.

[badcel]

@veler Are you aware that the dbus call might fail regularly in case of old distributions (API not available). In those cases you would not check the GTK theme currently.

[veler]

Hey everyone! Thank you all for your feedback, it's super helpful :)
I think I updated the PR according to your suggestions. I'm struggling at setting up a Fedora somehow. I wouldn't mind if one of you could try it. On my side, I tested on Mint and Ubuntu.

[veler]

Alright, I finally got Fedora to work!
The title bar now follows the theme of DevToys. However, DevToys does not detect the system's theme. userThemePreference on line 179 is 0, so it fallback on checking the theme name, which is just "adwaita", whether it's dark or not.

I'm happy to take suggestions, otherwise I kind of happy with the current state too. I know it's not perfect but it's not a blocking issue.

[CodedOre]

Which edition of Fedora did you install?

Because the Settings portal, like the other XDG desktop portals, depend on a implementation in the desktop to provide the information.

Gnome and Elementary have implemented the new portal, as well as KDE (partially at least).
But some like Cinnamon or Xfce might not provide the preference yet, so there a fallback to the theme name would be used.

[CodedOre]

I did just check with my Fedora desktop (to be precise, Fedora Silverblue with the Gnome desktop), and it does work fine and is indeed using the portal.

[badcel]

@veler you could double check if you use "D-Spy" to execute the call to the portal interface manually like I showed in the screenshot.

Perhaps you really have some variant / version which does not have this feature available?

[veler]

Hey there,
Thanks for your comments :)

I made a virtual machine of Fedora Workstation 40 using the ISO from the Fedora website.
If I'm not wrong, @badcel , I'm getting the same result than you in D-Bus. This is in my Fedora, currently set to Dark mode.

Am I understanding correctly it finds "1" ? Also, when I switch the theme to Default, then the value is "0".

[CodedOre]

The values from the settings portal looks right to me. If you look at the portal documentation, the value 1 stands for dark mode, while 0 for "no preference". The reason Gnome sets "no preference" instead of "prefer light" on the default setting is that some apps on default would prefer to be dark (like image viewers), while most apps use light as default.

[CodedOre]

So, I so notice that as of now, on the default setting the app uses the fallback. So, this could be improved by calling the fallback if the DBus call returns an error (like when it did not find the portal).

[CodedOre]

Somewhere here you should, if I read the documentation right, check for an G_IO_ERROR_CLOSED error, in which case the fallback should be called.

[veler]

Thanks ! (and sorry for the late reply)
I will try to do this soon. :)

[badcel]

If an error occurs, the bus.CallSync() call will throw an exception as gir.core interpretes the error argument by itself and raises an exception. As there is already a try/catch in place this should be fine.

So you probably only need to explicitly define in the switch expression which Theme DevToys should use if the user has no preference instead of calling the fallback.