Provide flatpak manifest, Appstream XML

[flxzt]

This adds a Flatpak manifest for development and packaging.
It also adds a .metainfo.xml which contains metadata about pympress, a requirement when publishing to Flathub

I am planning to create a Flathub package as well, the manifest should end up looking identical with the exception of sources which will be replaced by the release tarball.

Things to note:

• Flatpak only accepts icons that are named identical to the App-ID (so io.github.pympress) so I renamed it
• When this is merged I'll take the first new release for the initial Flathub package
• I took me@cimba.li as the contact mail, but I could also change it to my mail f.zwettler@posteo.de for Flathub if wanted

I tested it briefly and it seems to work fine but please try it out as well since I am a relatively new user of pympress myself and I don't yet know all the features which could possibly break in the Flatpak.

Thanks for writing this app, I really like it! :)
Hopefully it will get a Gtk4 port at some point.

addresses #132

[Cimbali]

Hi and thanks for this PR! With pip installs being less favoured nowadays I think it’s good we have a decent option for OSs that don’t package pympress. I’ll try to have a more detailed look soon.

[Cimbali]

So thanks again for opening this PR and sorry for the time it took to delve into it.

After looking into it I think this manifest should live on flathub only, and doesn’t need to exist in this repo. I built and tested which all turned out nice, including media playback.

I then ran their linter which told me
a) --own-name in finish args is redundant
b) io.github.pympress is not allowed as a name, we need 4 parts if using github.

I’ve rebased and fixed (a) but I’m not sure how to properly fix (b). We could call it io.github.pympress.pympress but it’s a little stupid. Their rules suggest io.github.cimbali.pympress which is where the repo lives, but I’m not too keen on that either, especially since:

1. there’s nothing at cimbali.github.io (they also say the reversed-id url should be reachable)
2. we control pympress.github.io which is literally made for that sole purpose
3. The id io.github.pympress is what we already use everywhere, including dbus, desktop files, etc.

I think given these points the best way forward is maybe to submit as-is, and ask for an exception on the 4-part rule if they complain. Hopefully they have a whitelist of exceptions somewhere.

In the mean time I’ve merged the other parts of this PR at 6f48879. We can rename files to something else (or rename them as part of the build process?) if we need them named under a different id for flathub.

[Cimbali]

I think I can setup a repository redirect from github.com/pympress/<any name> to github.com/Cimbali/pympress by renaming the repo back and forth, then we could use io.github.pympress.<any name> (.app? .presenter? .reader? .pympress? .pdf?) but it’s a bit dodgy and I’d rather not resort to that.

[flxzt]

After looking into it I think this manifest should live on Flathub only, and doesn’t need to exist in this repo.

It was meant for maybe development with Flatpak or adding nightly bundles at a later time as well, but you're right, it's not necessary. I can remove the manifest once the remaining issues are resolved and the app is ready for submission on Flathub.

I built and tested which all turned out nice, including media playback

nice! Thanks for confirming

io.github.pympress is not allowed as a name, we need 4 parts if using github.

Hm, I think I wasn't up to date with the latest changes of their requirements.

If I understand it correctly for Github based projects they are looking for the ID to correspond to the Github repo URL. I saw you already set up a redirect from cimbali.github.io/pympress which I think is everything you can additionally do to satisfy the requirement.

So I would say io.github.Cimbali.pympress should be used as the ID because that's the unique identifier which you control and where the project actually lives.
Or do you want to avoid your account name in the ID specifically?

I think given these points the best way forward is maybe to submit as-is, and ask for an exception on the 4-part rule if they complain.

I have doubts they will do that for newly submitted apps..

What do you think?

[Cimbali]

Additionally to the 3 reasons I listed above, my account name definitely isn’t relevant to the id indeed. The premise of their rule is based on the incorrect assumption that a "vendor" offers a program, but here it’s not the case. In the same way Mozilla develops Firefox, but there’s no vendor behind vim.

I have doubts they will do that for newly submitted apps..

No way of knowing without asking. If they are smart about it, they have a whitelist. The fact that we have well-established uses of the existing id (dbus, documentation, desktop files, etc.) makes this a reasonable ask in my opinion.