feat: add AsPromotional and <promotionals> element

[razzeee]

Introduce a new top-level component element for promotional banner/hero images and videos, distinct from screenshots. These are marketing assets (not screen captures) and are entirely optional — omitting the block never triggers any warning.

New public API:

• AsPromotional object (mirrors AsScreenshot infrastructure)
• as_component_get_promotionals() / as_component_add_promotional()

Validation rules (only applied when the block is present):

• promotional-contains-text-missing: warn if contains-text attribute is absent (must be explicitly true or false)
• promotional-image-not-landscape: info if source image width <= height
• promotional-no-media: error if a has no image or video

Example xml:

<promotionals> <promotional contains-text="false"> <caption>Hero banner</caption> <image type="source" width="1920" height="1080">https://…</image> </promotional> </promotionals>

Currently fails to compile on fedora.
Also not sure, how to handle the copyright headers correctly, as this is heavily based on the screenshots component.

But mostly, this is to talk about the feature itself, do we want something like this? Is it feasible? Flathub gets apps that get screenshots wrong like this from time to time. Mostly probably because they come from other stores and already have artwork ready.

[ximion]

The stance so far on this has been that we wouldn't want to add it to AppStream, primarily because the designs and layouts of frontends that show AppStream data are so very different that finding a one-size-fits-all hero image and promotional artwork would not work (or be extremely hard). There was also worries that people would use it to game the system, abuse it in some ways as well as space concerns because all the data has to be cached on CDNs in multiple sizes, likely multiple languages, etc. People aren't even using videos in screenshots properly yet to showcase their application.

The compromise back then was adding the branding block, because colors are universally applicable across designs, and there's algorithms which can evaluate matching colors too (which is harder for images). Some frontends also wanted to control the promotional art, and not have the app provide it.

Of all of this, not having a "one size fits all" solution is probably the strongest argument, plus cluttering the metadata files (but the latter could be solved by making this a companion spec that's referenced from the main file, like releases files, at least in theory).

[razzeee]

The stance so far on this has been that we wouldn't want to add it to AppStream, primarily because the designs and layouts of frontends that show AppStream data are so very different that finding a one-size-fits-all hero image and promotional artwork would not work (or be extremely hard).

This is already a problem with landscape vs portrait screenshots and we get by okayish. I'm not even suggesting, that every frontennd should make use of this.

There was also worries that people would use it to game the system

I get that, when they are not separated from screenshots. They should always live in their own places in the frontends, but otherwise, I'm not sure how to game these. Every interaction with the user can be thought of manipulating them, if we take this to it's conclusion. It's just more visual here?

as well as space concerns because all the data has to be cached on CDNs in multiple sizes, likely multiple languages, etc. People aren't even using videos in screenshots properly yet to showcase their application.

I'm more worried about video space then space for promotionals/screenshots. That should be managable, at especially with modern image formats

Some frontends also wanted to control the promotional art, and not have the app provide it.

That won't scale. Especially, if you need to have text translated for these.

As a store I can easily create promo videos for apps, using their colors and screenshots, but it falls apart, as soon as we need texts and call to actions etc. - you would have to pull these out of thin air for each app - without misappropriating them.

plus cluttering the metadata files (but the latter could be solved by making this a companion spec that's referenced from the main file, like releases files, at least in theory).

Initially liked the idea, but it might lead to it not being very discoverable - at least not organically - without reading the spec.