build: Add a Flatpak manifest

[bochecha]

This allows building the master branch of Hamster with a simple command:

$ flatpak-builder _build build-aux/flatpak/org.gnome.Hamster.json

---

For those who don't know Flatpak much, here are a few additional instructions.

1. you need to install Flatpak, Flatpak Builder and configure the Flathub remote: https://flatpak.org/setup/
2. you will need to install the GNOME platform and sdk to build;
3. to make rebuilds faster you want to use the --ccache and --force-clean options;
4. once the app is built, you need to export it to a local repo, configure that local repo, then install from that repo; this can be automated with the --install and --user options;

All in all, the following two commands should do the right thing:

$ flatpak install flathub org.gnome.Platform//3.34 org.gnome.Sdk//3.34
$ flatpak-builder --force-clean --ccache --user --install _build build-aux/flatpak/org.gnome.Hamster.GUI.json

If this is merged, we can look at having automatic builds in your CI, published to a development repo, etc…

And then I can help you send the next release to Flathub if you're interested. slightly_smiling_face

[ederag]

Thanks for the proposition,
same answer as for any package, here is the one about snap,
I'd prefer to split responsibility, as least for now.
(I'm fully supporting, following the repo, just not taking responsibility)
Is it possible to do that in an external repo for flatpak as well ?

[bochecha]

It certainly is, yes. In fact that's how it works for Flathub.

If I may though, there are quite a few benefits to having this in the upstream repository:

1. people don't need to figure out what options to pass to Waf, look at the build failures to try and find what dependencies they are missing, because everything is fully described in the manifest;

2. people can just open the Hamster source code in GNOME Builder and start hacking, the "build" button will build Hamster within Flatpak, the "run" button runs it in a sandbox, which leads to a pretty great developer experience and makes onboarding newcomers much easier;

3. that can even become an integral part of your workflow, where the CI builds a Flatpak bundle for each merge request and exports it somewhere, making it trivial to test proposed changes; GNOME does that for lots of its apps now, it has made everybody's life much easier, especially the non-developers (e.g designers or translators) who now don't need to build apps and maintain development environments;

I'll understand if you still don't want it in. I do think it would be a mistake, but it's entirely your choice to make and I'll respect your decision.

If you decide not to take this in, then I won't maintain a Flatpak build of the master branch myself, I'll simply wait for the release and push it to Flathub then. 🙂

[ederag]

OK, that's seducing.

Point 1 is probably not related to being in the master repo itself.
Snap is external, and users do not have to care about waf either.

Yet, points 2 and 3 are a bit different.
Flatpak being so close to gnome, and hamster being a Gtk app,
there are additional advantages with respect to other package systems.
And I can see that development could be improved by having all in one place.
That could deserve a special policy.

The v3.0 coming release (+ main job) is a bit overwhelming,
it would not be reasonable for me to learn a new framework now;
could that be discussed again just after the release ?

Or maybe I could assign automatically any flatpak related issue to you,
and merge blindly any PR involving only those files ?

[bochecha]

Point 1 is probably not related to being in the master repo itself.
Snap is external, and users do not have to care about waf either.

Except with an external repo people need to get that, and then build from there, as opposed to building straight from the sources they just cloned in order to make the changes they want to send you.

The people who benefit the most from this are newcomers and opportunistic contributors, who will easily get discouraged by any friction.

The v3.0 coming release (+ main job) is a bit overwhelming,
it would not be reasonable for me to learn a new framework now;
could that be discussed again just after the release ?

Oh of course.

Or maybe I could assign automatically any flatpak related issue to you,
and merge blindly any PR involving only those files ?

I'd rather not be the only one understanding this stuff. Teach a person to fish, and all that.

There's no rush here. 🙂

[ederag]

I'd rather not be the only one understanding this stuff. Teach a person to fish, and all that.

I'm always curious, and progressively learned some of snap for instance,
so you would not be alone.
But likewise, until things settle down, I would like the responsibility of flatpak to be on other shoulders.
Thanks for your comprehension, so we'll discuss again about that after v3.0.

[ederag]

There will never be any CLA on this code. Please disregard the wrong checks (#589).

[matthijskooijman]

I'm closing this, since #610 has been merged instead.