Appstream metadata #34
Conversation
| <launchable type="desktop-id">rpi-imager.desktop</launchable> | ||
| <screenshots> | ||
| <screenshot type="default"> | ||
| <image>https://www.raspberrypi.org/app/uploads/2020/03/RPI_intro-e1583228263677.png</image> |
There was a problem hiding this comment.
@XECDesign are these URLs guaranteed to continue to exist, or should they be changed to something else?
There was a problem hiding this comment.
I'm not sure, it's not anything I'm familiar with.
There was a problem hiding this comment.
It's not that much of an issue if these snapshots were to move at a future time. You'd just have to update the metadata when it happens.
There was a problem hiding this comment.
@XECDesign Would it make sense to copy these screenshots to http://downloads.raspberrypi.org/imager/ ?
A key element to agree on early is the app ID. It could also be |
|
Naming decisions sound like a @ghollingworth thing 😉 |
|
Considering the naming convention used for other binaries under this download page, I believe using |
|
See also #26 😉 |
|
I see, so it's been changed before already.
Le mer. 18 mars 2020 à 15:41, Andrew Scheller <notifications@github.com> a
écrit :
… See also #26 <#26> 😉
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<#34 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAO7U3ZFFHGV6FNEUZCGE7LRIDMTLANCNFSM4LIYPZDA>
.
|
|
So, are you all fine with |
|
Sorry to insist, but I won't get as much time to finalize the Flatpak in the future. All I need is a confirmation for the app-id ( |
|
That's fine |
|
FYI, the flatpak submission is happening here. Please wait before merging this as the Flatpak maintainers team might provide additional tips to improve it. |
|
One piece of comment I got was about the screenshots, which could be improved as far as resolution is considered. Could you generate and upload a new batch which conforms to the recommendations listed by the freedesktop, i.e. minimum width of 620px, 16:9 ratio and default theming. As far as hosting is concerned, the screenshots could well be put in this repository inside a |
What should be done with existing shadows added by the compositing manager? |
There is a tolerance for that as long as it remains reasonable. I usually take screenshots with Alt+PrSc with the window active and the cropping is optimal (under GNOME). |
|
I just happened to spot that Raspberry Pi Imager has been packaged as a snap. |
|
@lurch hello, do you mean screenshots or something else? I manually entered the metadata and took the screenshots myself. They're not in appstream (in that I didn't submit them). Not sure what specifically you're after, sorry. |
|
Actually, the reason I want to submit these metadata is precisely so that any downstream distribution of the software, such as raw Debian or Fedora, as well as more generic packaging solutions like snap and flatpak, can all benefit 😄. |
|
Here are a handful of screenshots compliant with AppStream: Main window:
Choose OS:
Choose SD :
Write in progress:
Write done:
|
|
@ghisvail Do you want to add those screenshots to this PR? Or are you expecting some other course of action? |
I'd need a canonical URL for them. Could you upload them somewhere long term (such as in a screenshot section of the official webpage) or shall I add them somewhere in the source code? I could use the GitHub generated URLs above, but something more "official" would be better. |
|
ping @XECDesign in case he has time to upload these somewhere "canonical" ? |
|
It's up to the repo maintainers whether hosting them on github is a better approach, but I have uploaded your screenshots here and removed the old ones: |
|
The PR for the Flathub release has just been merged, so the app will be made available soon. |
Does that imply that this PR is now ready for merging too? |
| <launchable type="desktop-id">rpi-imager.desktop</launchable> | ||
| <screenshots> | ||
| <screenshot type="default"> | ||
| <image>https://downloads.raspberrypi.org/imager/RPI_intro-e1583228263677.png</image> |
There was a problem hiding this comment.
Did you forget to update this URL? 😉
No, no, I have to sync it with the version published on the Flathub repository. |
|
Oh, so the file here is a "downstream version" of the one on Flathub? I still know nothing about flatpak, so I mistakenly assumed it was the other way around 😉 |
|
Once this one is merged and a new version of rpi-imager is out, the metainfo file on the Flathub repo will be dropped in favour of the upstream version. That's usually how we proceed. Instead of bothering upstream upfront with freedesktop integration files ( |
|
Perhaps this PR should be titled as WIP then, to stop it being merged prematurely? |
|
FYI, it is now listed on Flathub and available in supported software stores:
|
|
Can we confirm what the next steps are here? Does this need to be merged? |
|
@ghollingworth I have to synchronize the code with what has been reviewed for the Flathub submission. I'll try to get it done by the end of the week. |
|
OK, that's great, I was hoping to get a new release out soon to close some of these PRs |
|
Merging #52 would help |
ghisvail
force-pushed
the
appstream-metadata
branch
from
6dd0056
to
f8e19f8
Compare
|
@ghollingworth It's done. Sorry for the delay. Please ping me when the new release is done so I can adjust the flatpak packaging appropriately. |
|
@ghisvail V1.3 was released recently. |
Great! Too bad this PR was not merged before hand. |
|
The flatpak has been updated to v1.3. |
|
@ghisvail Given previous comments, I'm afraid it's still not 100% clear if this PR is "ready for merging" in this repo yet? 😕 🤷 |
| <binary>rpi-imager</binary> | ||
| </provides> | ||
| <releases> | ||
| <release version="1.2" date="2020-03-10" /> |
There was a problem hiding this comment.
I'm guessing this would have to be updated on every release?
There was a problem hiding this comment.
Some upstream provide detailed release notes through the release metadata (so that changes are displayed and formatted nicely in software stores), others just keep one entry and only update the version and date (which is comparatively simpler to maintain).
Your call.
|
Is listing release dates and prior versions mandatory? If not, I would be tempted to have cmake put just the current version number in the file automatically (similar to what we do with @IMAGER_VERSION_STR@ in windows/rpi-imager.nsi.in ) |
Recommended, but not mandatory. |
I should have made myself clear then, my bad 🙏 |
I intend to submit a Flatpak for rpi-imager to Flathub (I have it working locally) and need to provide some AppStream metadata for proper registration in Linux software stores like GNOME Software or KDE Discover.
I prefer contributing these metadata upstream so that all downstream distributions can benefit (not only Flatpak). I am proposing
org.raspberrypi.rpi-imageras the application ID but it can be something else, as long as the latter fulfills the requirements explained in section 2.1.3.I used the wording in the blog post introducing the imager for the description. Feel free to review it and propose improvements. This description will become what's displayed in the software store alongside the name, summary and screenshots, so it is quite important.