One of the major new features in F36 is a system wide dark mode. It's possible to have wallpapers that have a light and a dark variant, which are used depending on whether dark mode is enabled or not. This is different from the pre-existing timed wallpapers, which change appearance at different times of the day.
While timed wallpapers are still supported, I think that it's recommended not to use it, and to provide wallpapers with the dark mode variant instead.
In the background settings, wallpapers that have a dark mode appear with a split view, showing both the light and dark variants. How it looks using the upstream GNOME backgrounds:
https://imgur.com/a/ix4MIvZ
How the settings look when using f36-backgrounds-36.0.0-1:
https://imgur.com/a/vmn2h8G
Ideally, all pre-installed wallpapers would have dark mode variants. This will help to showcase the new dark mode feature in F36.
Presumably we are missing dark mode variants for each of the backgrounds, other than the default, as well as the XML to define the variants.
Hey there is a dark variant and there is XML for it too so I suspect this is an issue with packaging. @luya do you track wallpaper package issues here or upstream in github?
ed. @aday sorry i misread the issue here - i dont know where those extra backgrounds come from, maybe the last supplementary package we did but that was a while back. i didnt know supplementarys were being used by default. @luya do you own the supplemental package?
@duffy I tracked here and some time upstream gitlab. I noticed the changes but lacked the opportunity to address them. It looks like XML is trivial to implement.
Supplemental package is actually a sub-package of f36-backgrounds. I let it enabled by default at the request of spin maintainers with a plain blue background. Maybe disabling it for the time being or making a dark plain variant?
Edit: Testing on Fedora Design Suite Rawhide, I modified the XML and can see the dark mode automatically handling the night version of default wallpaper.
I will leave the time of the day default background as an option for other spins like MATE and Cinnamon.
@aday Here is a test RPM on https://copr.fedorainfracloud.org/coprs/luya/fxx-backgrounds/build/3542708/ handling dark mode.
Correction, those supplemental wallpapers are from fedora-workstation-backgrounds from which I lack access. @ryanlerch Would you mind update it to match GNOME 42 features?
Support for dark variants added on https://bodhi.fedoraproject.org/updates/FEDORA-2022-8eb9eb9216 Please test.
I installed the the base and gnome packages from bodhi on my F36 install. Results:
The other set of wallpapers belongs to fedora-workstation-backgrounds package maintained by Ryan Lerch. They will have to get a merge-pull by a proven packager. I will check why the default wallpapers is not located on top,
The attempt to fix this caused a problem: see https://github.com/fedoradesign/backgrounds/pull/34 .
In Fedora we ship a pair of gsettings override files - /usr/share/glib-2.0/schemas/10_org.gnome.desktop.background.fedora.gschema.override and /usr/share/glib-2.0/schemas/10_org.gnome.desktop.screensaver.fedora.gschema.override - which have the effect of making the "default background" for GNOME be /usr/share/backgrounds/fNN/default/fNN.xml, where NN is the release number. That file is expected to exist and "be" the default background, in some sense. So if we want this "dark variant" wallpaper definition to be the default, then /usr/share/backgrounds/f36/default/f36.xml has to do that somehow.
/usr/share/glib-2.0/schemas/10_org.gnome.desktop.background.fedora.gschema.override
/usr/share/glib-2.0/schemas/10_org.gnome.desktop.screensaver.fedora.gschema.override
/usr/share/backgrounds/fNN/default/fNN.xml
/usr/share/backgrounds/f36/default/f36.xml
It seems like there are two different sets of XML files doing different jobs, here (in /usr/share/backgrounds/fNN/default and /usr/share/gnome-background-properties) and I don't entirely grok how that works or how we'd change /usr/share/backgrounds/f36/default/f36.xml to somehow point to the dark variant definition, but that's what needs to happen.
/usr/share/backgrounds/fNN/default
/usr/share/gnome-background-properties
@duffy and I spoke about this last Friday, and agreed to include 6 backgrounds each from fedora-workstation-backgrounds and gnome-backgrounds. The fedora-workstation-backgrounds that we use will need to be updated to include a dark variant.
The gnome-backgrounds already include a dark background. The tracking issue to include more of them is https://bugzilla.redhat.com/show_bug.cgi?id=2061290 .
The tricky part isn't about what's included, but what gets used by default on fresh installs. I think we have a plan for that figured out, though, I'm going to fiddle with it today.
@aday these are the candidates I have, let me know if you have prefs
My prefs for the six:
i put the most work into the himalayan mountain one but i dont know...
@aday I posted ^ in the bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=2061290#c2
Let me know if you need me to do anything else.
I'd say it's perfectly appropriate to ship wallpapers that do not have a dark variant and many of the picks above would work fine in a dark environment. Baking in a lowered exposure doesn't feel right to me, it just results in a poor photo.
Creating light/dark variants of a photo is way more expensive than CG and we haven't been able to produce any upstream. There might be ways to generate them with AI in the future, but so far I'd stick to a single photo unless we can have an actual photo taken in different lighting conditions.
I updated my F36 test machine today. Here's what the background selection grid currently looks like:
One obvious issue there is that the default F36 wallpaper appears twice - once as a light/dark version, and once with a timed background option. i think that it would be better to drop the timed background one - would that be possible?
No problem. I will take of it.
No, please don't. Remember the other discussion. We shouldn't drop the timed one because anyone who installed F36 before https://bodhi.fedoraproject.org/updates/FEDORA-2022-d43d2cbe5c went stable (two days ago) will still have it set as their background. If we remove it they'll get, uh, whatever GNOME decides to fall back on.
If it's possible to change its configuration so it's hidden from the UI, we could do that, but I don't think removing it is a good idea.
No, please don't. Remember the other discussion. We shouldn't drop the timed one because anyone who installed F36 before https://bodhi.fedoraproject.org/updates/FEDORA-2022-d43d2cbe5c went stable (two days ago) will still have it set as their background. If we remove it they'll get, uh, whatever GNOME decides to fall back on. If it's possible to change its configuration so it's hidden from the UI, we could do that, but I don't think removing it is a good idea.
If we can hide the timed wallpaper from the UI without removing the file, then I agree that that's best. But if there isn't a way to hide it, then I do think we should remove it.
F36 is preerelease. There aren't going to be many people who will have selected that wallpaper, and if they have it's not a particularly serious bug.
It's not that they selected it, it's that it was the default. The way we implement defaults in Fedora is with a gsettings schema override file, and the way that seems to work is the overridden setting gets written into the user's config when the user is created and then never changed, even if the override file is later changed.
So anyone who installed F36 while the gsettings override file pointed to the animated file, still has the animated file configured as their background, and if we remove it, their background goes away.
Ugh, this is the worst. What a mess.
Lesson learned in the above. In a future, let's keep both Fedora and GNOME Design Team in sync for future default wallpaper.
If we really feel strongly about it, we could still remove the animated one, I guess. I just wanted to flag up what the consequence of that would be. If we're going to do that we should probably write it up in common bugs and send a mail to the mailing lists to say, hey, yeah, we know your background disappeared, sorry, this is why.
We could even do something fancy like put it in a subpackage that's installed on upgrade but not on fresh install, but that seems like kinda going a bit too far for what the issue is.
The XML file for the wallpapers has a way to hide it doesn't it? the deleted="false" attribute in the main background tag?
ooh, yeah, if setting that to 'true' would make it keep working but not show up in the picker, that sounds like what we want.
I confirm changing the delete parameter to true works as intended. Shall we apply these changes?
@luya I don't know what the delete parameter does for users who already have the timed background set, will it remove their background in an ugly way like we were talking about or will it just hide it from the display? Do you have a way to test this?
@duffy Simply edit /usr/share/gnome-backgrounds-properties/f36.xml and change delete parameter of timed background to true to hide from the display list. Basically, delete parameter is actually hide. As tested, the users' desktops will still retain the selected timed background as long they avoid changing it.
/usr/share/gnome-backgrounds-properties/f36.xml
true
@luya ah I see! I'd go ahead and make then change then!
closing this since I think we're set for F36.
Metadata Update from @duffy: - Issue close_status updated to: Fixed - Issue status updated to: Closed (was: Open)