Support light/dark variants for screenshots

[cassidyjames]

The web lets you set an alternate source for images for prefers-color-scheme: dark. Something similar would be nice for AppStream so software centers could choose to show the correct light or dark screenshot by default for apps depending on the system's light or dark state.

[ximion]

We'll have such a combinatorial explosion with screenshots - every one of them can not only be translated into any language but also be available in variants...
But I am not against having this, maybe this should be combined with allowing per-environment screenshots (a thing we rejected so far).
So, something like:

<screenshot>
    <image environment="plasma">https://example.org/example-on-plasma.png</image>
    <image environment="elementary">https://example.org/example-on-elementary.png</image>
    <image environment="elementary:dark">https://example.org/example-on-elementary-dark-theme.png</image>
    <image>https://example.org/example-on-gnome_fallback.png</image>
</screenshot>

(so, environment having the form of <desktop-environment>:<style>)

The thing is, any such change will necessarily be backwards-incompatible on the XML level - however, now that GNOME Software uses libappstream, the impact of such changes will be less severe and newer libappstream releases can abstract the differences away in their API (would still mean though that any older libappstream versions would just show all screenshots for all environments unconditionally, which is a reason why I am never massively thrilled about these changes).

In any case, the rationale makes sense, and even though I thing this feature would be used very little, having the software center show a preview of how the app would look like in the current environment would be a pretty nice touch!
@hughsie do you have any opinion on this?

[sophie-h]

I think that it's safe to say that everything around customization/accent colors/theming is a bit in the air right now.

I would therefore suggest adapting the scheme_preference property from #187 for the <image> tag as well and solving potential additional needs outside of this issue with separate properties.

/cc @FHEK789 @bertob

[bertob]

We'll have such a combinatorial explosion with screenshots - every one of them can not only be translated into any language but also be available in variants...

I mean realistically the only way to fix that is with programmatic tooling to set up apps in specifc situations (example content and the like), and then re-generate all screenshots automatically on every release. Translated screenshots already aren't feasible without that, regardless of other factors.

[ximion]

Having a color_scheme property for <screenshot/> blocks would make sense IMHO and would not be as crazy as creating the combinatorial explosion of supporting all the themes and environments.
The problem with all of this is though that any of these additions will be a soft-breaking change, requiring at least appstream, appstream-generator, plasma-discover, gnome-software and appcenter to be patched first to display this correctly and not display all the color scheme screenshots next to each other at once. There isn't any way around this though, it's just something we need to keep in mind. So, between implementation of a feature like this and the point where it can actually be used there will have to be a bit of a time gap so all client tools can adjust.

[cassidyjames]

@ximion from the AppCenter perspective, showing light and dark variants next to each other doesn't seem like a big deal; app developers already often include both in their screenshot sets to show what it looks like and so this wouldn't be a change for our users.

[sophie-h]

to be patched first to display this correctly

From GNOME's side we have created our own screenshots guidelines and can hold adding dark screenshots until there is proper support (it's already referencing this issue.) I also don't think that other app developers will adopt it too rapidly.

all the color scheme

In theory, the schemes currently are no-preference, light, dark. But that sounds odd for screenshots?

It would probably be good to stay somewhat in sync with the standard desktops use. Prefer light is reserved for future use IIRC and actually has no meaning currently? Pining @Exalm to avoid making a mistake here. Do you have any input?

developers already often include both in their screenshot sets

Agreed, partially we already have this problem :)

[pwithnall]

Fonts are a slightly special case where light/dark variants would be useful, as the foreground colour that the fonts are rendered with would be different in both cases. See https://gitlab.gnome.org/GNOME/gnome-software/-/issues/1716

[sophie-h]

Since we now have scheme_preference dark/light for branding colors, I think it's pretty uncontroversial that we should just add the same property for screenshots as well?

[mcrha]

Fonts are a slightly special case where light/dark variants would be useful, as the foreground colour that the fonts are rendered with would be different in both cases. See https://gitlab.gnome.org/GNOME/gnome-software/-/issues/1716

Too add to this, with respect of the fonts, the <icon> might be useful here as well, because the font's icon is the font being used. The cited bug (with screenshots, comparing the Fonts app and the gnome-software) is just about that, the font icon (quick font preview) and the screenshot (showing a sentence drawn with the font).

[ximion]

@mcrha Do you think we could expect software centers to just invert colors for fonts on a dark theme? (I'm pretty sure I know the answer to that question, but just in case - adding any additional property to the icon tag is extremely hard without breaking compatibility, due to how its YAML representation is designed).

[mcrha]

Inverting colors on the colored icons is something you do not want to do, I'm afraid. The fonts (and tools and some other "symbolic" icons) are possible, though. Is there any (easy) way to do it, please? Having the software centers as an image editing software doesn't sound too good. I mean, inverting the icons for certain types of app where it's assured it's just black&white&transparent is fine by me, expecting the image is provided for the light theme. I only did not think of it due to not much interest in the image editing routines being part of the app.

[Exalm]

[mcrha]

Right, some fonts are bitmap fonts. Hrm. I see (at least some) icons are 8-bit sRGB PNG files, not a 1-bit or something.

[ximion]

Oh crap 😆 - so unconditional color inversion for fonts is not an option, and having software centers analyze the image data first is also a think that I don't particularly like...
Let's keep this for screenshots, but having icon variants is apparently something we may need as well - and that would be a breaking change for sure, at least on Debian/Ubuntu-based distributions.

[mcrha]

Let's keep this for screenshots, but having icon variants is apparently something we may need as well

Thanks, that was basically my point, to not forget of the icons. I'm sorry if I've been confusing.

[ximion]

I'm sorry if I've been confusing.

Not at all, I genuinely didn't have this on my radar...
This feature still needs an implementation, which means it will definitely miss today's release, but maybe after that I can get to implementing it. Given that the YAML files are versioned, we will also be able to add some backwards-compatibility for icons when we add variants for them, but the transition period for this will be quite long until the new AppStream(-compose) versions have percolated through the stack so this new feature can be used reliably.
(same for screenshots, annoyingly)