appstream-glib
appstream-glib copied to clipboard
hughsie
screenshot priority is not described in docs
In https://github.com/hughsie/appstream-glib/issues/210#issuecomment-350478849 you say:
The order isn't prescribed, it's XML afterall. You can however control the priority that they are shown. Simply use priority="number" for each
and it will respect that.
However, that is not described and not even hinted in the appstream docs: https://www.freedesktop.org/software/appstream/docs/chap-Metadata.html#tag-screenshots
Please adjust the docs to state that the screenshot order is not defined and how to define the order manually (do they show up in ascending or descending order?).
Thanks.
(Btw, according to the info I found, all XML parsers return elements in the document order, even though they are not required to do so).
It seems to work. In descending order. If I specify them, it even fixed bug #210 (the default tag is not shifted).
@hughsie Yes, you did :D For libas, the order is always default screenshot first, and then the rest in whatever order it is defined in the XML. This is just coincidence though, upstream shouldn't make assumptions in how screenshots are shown in the software center (might be some timeline, or a grid layout, or a carousel, ...) according to the current spec.
If hughsie made it up, how come it really works? 😄 I just tested it, after processing through flatpak-builder, the screenshots are always sorted in the final output appdata according to the priority tag (in descending order).
And also, if authors shouldn't make assumptions, that's fine. But why shouldn't they be able to at least provide a hint for a recommended screenshot order? It's then up to the application to display it somehow, and a recommended order is definitely a good thing to have, I believe. For my application, I surely prefer to show some basic overall screenshots first, before I show you some "specialties".
@kparal It means that is is only working in the appstream-glib implemantation, but not in any other - so the things will look different in at least Arch, Debian, Ubuntu, Elementary, KDE, ...
For my application, I surely prefer to show some basic overall screenshots first, before I show you some "specialties".
That's what the "default" screenshot type is for. Set type="default" for the screenshot and it will be displayed first and as primary image for your app.
@hughsie I am surprised you used some additional property for sorting screenshots instead of just listing them in the order they were parsed. I would have assumed that doing the latter would be much more performant than having an extra sorting step in there. Also, it feels weird to have that priority thing in there, tbh, because we already - sort of - go by tag order for content ordering in e.g. the description tag.
That's what the "default" screenshot type is for. Set type="default" for the screenshot and it will be displayed first and as primary image for your app.
Sure, but that's just a single one. Having a recommended order is still better than not having it, for any software store.
Also, it feels weird to have that priority thing in there, tbh, because we already - sort of - go by tag order for content ordering in e.g. the description tag.
If the document order is kept (or at least recommended to be kept to the store implementation), we don't need priorities and it's also natural/intuitive for the appstream writers.
If the document order is kept (or at least recommended to be kept to the store implementation), we don't need priorities and it's also natural/intuitive for the appstream writers.
That's what I would think as well, but before touching the spec in that regard, I'll need to know if @hughsie would be fine with such a clarification.
Looking back at my workbook, the reason I used priority was to merge and fix screenshots. For example, if you're using a merge-type component that adds screenshots to an existing AppData file, how do we sort them?
@hughsie If the screenshots are added, just append them to the existing list? How often do these merges happen, by the way? Is this really a feature that is still relevant, now that we have so much more high quality metadata?
@ximion you're right, the merges don't happen anymore expect for older distros like RHEL 7. If you're not happy adding this to the spec I can just close this PR and we can fix our RHEL tools.