Add working flatpak manifest

[Ryex]

Summary:

This PR adds a working flatpak manifest.

This manifest is built off the org.kde.Platform flatpak runtime at version 5.15-22.08 which supplies python version 3.10.6

This manifest uses a baseapp https://github.com/flathub/com.riverbankcomputing.PyQt.BaseApp at version 5.15-22.08 which supplies PyQt5-5.15.7

the modules installed include:

• enchant v2.3.3 installed from https://github.com/AbiWord/enchant/releases
• a pypi-deps.json which installs lxml 4.9.1 and pyenchant 3.2.2. This file is generated by https://github.com/flatpak/flatpak-builder-tools/tree/master/pip using an included script generate-pypi-deps-json.sh (the python file itself is not included and needs to be downloaded next to the script to be used).

There is a new setup.py command build-flatpak which locally builds a flatpak bundle which can be installed by flatpak install /path/to/novelWriter-*-linux.flatpak. It will need to obtain the SDK and base app from flathub. This bundle can be distributed as a release artifact but it is not itself releasable to Flathub.

The PR includes an updated appstream metadata file at setup/data/novelwriter.appdata.xml which provides data on releases, screenshots, and an OARS content rating . This data is used by applications like GNOME Software to present the app.

The screenshots must link to an external source for this purpose though they should perhaps be separated out to a new folder on the website and have their links updated. See https://freedesktop.org/software/appstream/docs/chap-CollectionData.html#tag-ct-screenshots for information on providing captions and alt sizes for any screenshot with the metadata.

Ideally, before tagging a release a new </release> tag should be added to this metadata.
there is a new gen-appdata command for the setup.py to update it automatically.

This appstream file currently lists the metadata as being licensed as CC0-1.0. The use of a permissive license ensures the metadata can be added to collections with other data.

Other options are licenses like

• FSFAP
• CC0-1.0
• CC-BY-3.0
• CC-BY-SA-3.0
• GFDL-1.3
• MIT

See https://freedesktop.org/software/appstream/docs/chap-Quickstart.html#qsr-app-contents

The appstream file was validated by

flatpak run org.freedesktop.appstream-glib validate setup/data/novelwriter.appdata.xml  

recommended in the flathub documentation

One last note is that this PR modifies the makeMinimalPackage function in setup.py to ensure MANIFEST.in file is included and to account for the new appstream metadata file.

Next steps for flathub distribution:

• Follow the steps at https://github.com/flathub/flathub/wiki/App-Submission#how-to-submit-an-app
• When adding the manifest file (io.novelwriter.novelWriter.yml) during step 4, also add pypi-deps.json next to it. Additionally the manifest file needs to modified to use an archive downloadable from the releases section instead of referencing the parent source directory.

example (note that this points at the current release and uses the appropriate checksum but the eventual submission would need a new release to ensure the new files are included):

    sources:
      - type: archive
        url: https://github.com/vkbo/novelWriter/releases/download/v2.0.1/novelwriter-2.0.1-minimal-linux.zip
        sha256: e0c9e02d9e0589f4fe268413e82a7033791ac1e1856fe4e8ab9ffa99d81a577c
        strip-components: 0

• The flathub maintainers may have some recommendations to further improve the manifest during the PR process. feel free to CC me in if you would like help.
• After approval, flathub will make a new repo with the RDN app id (io.novelwriter.novelWriter) under their org with the manifest. I believe that way it works is that you will be made a maintainer of that repo. Updating the flathub release form then on is as simple as making and merging a pr that updates the manifest to point to the new release.

Related Issue(s):

#481

Reviewer's Checklist:

• The header of all files contain a reference to the repository license
• The overall test coverage is increased or remains the same as before
• All tests are passing
• All flake8 checks are passing and the style guide is followed
• Documentation (as docstrings) is complete and understandable
• Only files that have been actively changed are committed

[Ryex]

Just added a build-flatpak command to the setup.py. this will build a flatpak bundle that could be distributed as a release artifact. however this is not for flathub distribution.

[Ryex]

Updated the PR with the recent work form the patch branch and added a build workflow to generate a .flatpak that can be installed or simply used as proof that the flatpak builds. Note that the artifact size is small because it still needs to obtain the sdk and base app images from flathub during installation.

I'm still willing to help get novelWriter available on Flathub. If your busy with other things I could presumably start the process for you and make sure to tag you in when it's nearing completion.
Once it's set up updating flathub will look nearly identical to this kind of workflow

flathub/org.prismlauncher.PrismLauncher#12

A simple PR that updates the source link and checksum. flathub automates the test and once you merge the PR it automates the release to flathub.

[vkbo]

Let's hold off on this one for a bit still. I want to figure out the packaging landscape a bit more before I add this too. I just moved AppImage build to the same workflow as the MacOS, so I'm trying to make things a little easier for myself on releases.

[Ryex]

That's fair, no need to unnecessarily increase the maintenance burden. I'll keep this up to date for when your ready for it.

I can just make my own builds to use it myself in the mean time.

[vkbo]

With the recently discovered issues with Qt 5.15.8, I am wondering if it's smarter to go for release formats where we can pin the Qt5 version, like we can here. In particular pinning it to 5.15.2. The Debian packages now have issues, the AppImages, and Windows and MacOS releases do not.

I still greatly dislike Flatpak, but it may be worth it 😃