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 😃

[vkbo]

I hate to close this with all the work you did, but I also don't really want to maintain another release format. The AppImage release is much easier to maintain in comparison. Also, most of what's in this PR needs to be refactored to fit with the current main branch, and the main branch has also moved to Qt6.

Would you mind if this was just closed? If not, it can be refactored and merged, but I am unlikely to maintain a flatpak release in the foreseeable future. I'm trying to reduce the workload of this project.

[Ryex]

I wouldn't mind if it was closed, I completely understand the desire not to maintain a alternative release format and flatpack is pretty useless unless it submitted to to flathub imho.

That said, would you be opposed to someone (not necessarily me, not sure I have the time) submitting a flatpack to flathub independently in the future?

[vkbo]

That said, would you be opposed to someone (not necessarily me, not sure I have the time) submitting a flatpack to flathub independently in the future?

No, not at all. I would much prefer to focus on the code. 😃

I'm also hoping someone want to actively maintain the MacOS release action and scripts. It bothers me that I'm releasing these packages with no way of testing that they actually work.