feat: add Flatpak configuration

[PureTryOut]

This uses https://github.com/TheAppgineer/flatpak-flutter to generate a Flatpak manifest (de.provokateurin.neon.yaml) that can build from source without network access.
The input for that is the flatpak-flutter.yaml. When submitting the application to Flathub de.provokateurin.neon.yaml with the "generated" folder is what would be submitted to them.

Note that I have trouble testing this as during the building of de.provokateurin.neon.yaml Flatpak executes some commands on the host which then fails as I'm running postmarketOS (and bare Alpine Linux on some other systems) which uses a different libc than the Flatpak sandbox (musl vs glibc). Shouldn't be a problem on distributions using glibc though (most of them). My system was just missing a binary on the host, I've built it successfully now.

You can build the application yourself as follows (instructions taken from https://docs.flatpak.org/en/latest/first-build.html):

$ flatpak remote-add --if-not-exists --user flathub https://dl.flathub.org/repo/flathub.flatpakrepo
$ flatpak-builder --force-clean --user --install-deps-from=flathub --repo=repo --install builddir de.provokateurin.neon.yaml

Please test it before accepting 😄

[provokateurin]

Thanks for the effort, however this project is basically dead at this point. There hasn't been any development by @Leptopoda or me in the past year and I don't think we're going to start with it again any time soon. There is nothing speaking against other people picking up our work again, though.

[PureTryOut]

That is very disappointing to hear 😢
I'm excited for this project due to the lack of good options on Linux mobile and this very much seems like the way to go: 1 codebase and thus experience for all platforms. And I'm using it on Android where it actually functions quite well already. I also do Flutter development for my day job so could actually help out.
This is not the news I was hoping for...

[provokateurin]

This is basically why I started the project. I wanted to have a nice Nextcloud client for Linux on phones. One main problem is that this is a lot of work, even though this project introduced techniques like OpenAPI that reduced a lot of code that would have to be written manually. This part was also adopted by the whole Nextcloud project, but implementing so much functionality is simply not possible for just 2 people. Like you said using one codebase also has a major advantage over the existing clients that duplicate features and bugs across codebases.

You can basically think of two people, competing with ~20 people from Nextcloud GmbH who have been doing this for years and full time, competing with probably thousands of people from Google and Microsoft who have been doing this even longer also on full time.

I'd be happy to help revive this project, if there is real interest and people who want to continue it.

[provokateurin]

BTW I almost forgot myself, but there already is a setup for building this app as a Flatpak: https://github.com/nextcloud/neon/blob/main/packages/neon_framework/example/de.provokateurin.neon.yaml IIRC I was even able to build and run an aarch64 variant on my x86_64.

[PureTryOut]

but there already is a setup for building this app as a Flatpak

Yes, but that uses binaries compiled outside of Flatpak. If you want to submit the app to Flathub (which I think should be a goal) the app has to build completely from source, the manifest and approach I submitted here achieve that goal.
Although to be honest I did not see there was already a manifest 😅

I'd be happy to help revive this project, if there is real interest and people who want to continue it.

I'm interested, and I'd love to contribute. But I doubt me being interested is enough for you 😅

but implementing so much functionality is simply not possible for just 2 people.

Maybe you're biting off to much to chew at once (is that a proper way of using that saying? Not sure haha). You can't expect to be able to implement the entire feature set of the other clients and keep up with new features all at once with only 2 people. Instead you have to start small and get basic functionality in there, for example perhaps just file syncing (since that's the core of Nextcloud after all) and get that working well and tested. I'm sure there is a lot to just that already (authentication, file system permission requesting on various platforms, I haven't looked into it really) but with that it's probably already a really usable client for a bunch of people.
Like, I like that this client integrates various apps (news, notifications, notes, etc), but not even the official Android app has that. Yes you can get notes through a second app which has some integration with the main app (just authentication afaik though) but the main app itself does not do that. So why go for such a feature in this one while it doesn't fully compete with the functionality of the main app yet? You're trying to catch up to a rocket going to the moon by shooting yourself to Mars.

I think the basic goals of this framework and app are great, but you have to keep it manageable for the amount of people working on it. Keep it to the bare minimum functionality required for file syncing until they are rock solid on all platforms supported by the app. Even with just that existing it will already be the best option for Linux mobile out there, and it'll be enough functionality for probably a fair amount of users on platforms like Android. This will get you users and through that probably also (some) developers, and at the very least it'll get you bug reports which are very useful on itself of course.
Once that's there, slowly expand the scope: things like automatic syncing of photo's appearing in the camera folder, favoriting, sharing with other people, etc. If this is done gradually enough I think it's perfectly feasible to catch up with the main platform-specific apps, but yes it'll take a while.

I don't know, perhaps I'm dreaming to much, but I think the goals are worthwhile going for. If only because Microsoft (Windows), Apple (macOS and iOS) and Google (Android) are clearly platforms we need to move away from, and a good Nextcloud client for Linux mobile will go a long way towards that 😉

[provokateurin]

has to build completely from source

I see, I didn't know about that.

I'm interested, and I'd love to contribute. But I doubt me being interested is enough for you 😅

I'd be up for reviewing the occasional pull request, but at the moment I don't feel like starting to pick up work myself again. However I might have some more time again in a few months, when I have cleared up some personal stuff.

Maybe you're biting off to much to chew at once

I know, we were always aware of that. Still it felt great to be able to achieve so much with so "little" work.

Instead you have to start small and get basic functionality in there, for example perhaps just file syncing (since that's the core of Nextcloud after all) and get that working well and tested

There is a prototype for file sync: #600

So why go for such a feature in this one while it doesn't fully compete with the functionality of the main app yet? You're trying to catch up to a rocket going to the moon by shooting yourself to Mars.

Originally I really liked the idea of having multiple Nextcloud apps in a single app, but over time we also realized that it's better to have them split again at some point, such that they only use common libraries, but don't interact directly. OTOH IMO one of the great benefits of Nextcloud is that these apps integrate with each other and are not completely isolated, so...

I think the basic goals of this framework and app are great, but you have to keep it manageable for the amount of people working on it

This was always a problem, because there were so many ideas, but we were lacking the amount of people that is required to be able to actually implement a fair share of them.

This will get you users and through that probably also (some) developers, and at the very least it'll get you bug reports which are very useful on itself of course.

I always wished that would happen, but I was probably to afraid of making a first public release for people to try. Also I'm really not good at marketing my own work. This is clearly something this project needs help with, if it is revived.

Once that's there, slowly expand the scope

I totally agree. Once the basic underlying structure is there, most things become super easy. Like some stuff we implemented for new versions took us only a few hours, while the developers of the official clients needed weeks...

I don't know, perhaps I'm dreaming to much, but I think the goals are worthwhile going for

Absolutely not! I still admire the goals I once had with this, when I started it.

---

Thank you for your kind words! ❤️ Maybe you'd be interested in chatting a little more? We should switch to a different channel though, this PR is not the best place 😅

If there is any way to bring in new people and revive this project, I'm absolutely here for it and I'd appreciate any help you or anyone else could give.

[PureTryOut]

Maybe you'd be interested in chatting a little more? We should switch to a different channel though, this PR is not the best place

Sure, and agreed! I'm available on Matrix as @puretryout:postmarketos.org, not sure which platfoms you tend to use but for me it has to be an open-source one 😉

If there is any way to bring in new people and revive this project, I'm absolutely here for it and I'd appreciate any help you or anyone else could give.

That's great to hear, let's see if we can make it work!

Now let's keep the discussion here to the PR itself 😄 As I mentioned this manifest makes it possible to build the app completely from source. I'm still struggling to build it myself but that's due to integration issues with flatpak-builder and postmarketOS/Alpine Linux which I'm trying to fix. I'd like someone to properly build and run it before this gets in at least.

[provokateurin]

Builds fine for me. It seemed to have no internet access, so I wasn't able to log in, but that could also be my fault. Did it work for you?

I think it's great to have such a setup to be able to build the flatpak from source, it should live somewhere else. Adding the ability to build from path instead of a git commit is not enough, because the generated files need be kept up-to-date and I don't want to add a CI that ensures this is the case.

I'm not sure if we really need this. You have successfully shown that this app can be built as a flatpak from source, so I'd suggest we just keep this PR in draft and once we want to publish to flathub we copy the files there and update them in the dedicated repo.

[provokateurin]

This file is quite similar to de.provokateurin.neon.yaml and is not used AFAICT, is this intentional?

[PureTryOut]

This file is used by https://github.com/TheAppgineer/flatpak-flutter to generate de.provokateurin.neon.yaml. It's not built directly and yes that's intentional.

I think for this repo I'll modify the generated manifest to just use network access so it doesn't need the files in packaging and it uses the local checkout for it's sources.
Then when we actually submit to Flathub we'll use flatpak-flutter.yaml again and generate a proper offline from-source manifest to submit there.

[PureTryOut]

It seemed to have no internet access

Fixed that. I only ran it to the setup screen, I didn't really test any further so missed this. Sorry for that!

I think it's great to have such a setup to be able to build the flatpak from source, it should live somewhere else. Adding the ability to build from path instead of a git commit is not enough, because the generated files need be kept up-to-date and I don't want to add a CI that ensures this is the case.

I disagree, I think it's very useful to have automatic Flatpak builds for every commit in git as a "nightly" version that people can easily test out so we get bug reports quickly. There is not much to keep up-to-date either, the file as it is now will basically be it for a long long time and if that changes it's easy to just update it.
I suppose we can keep the current manifest already in the repo in packages/neon_framework/example to do this but that then has to be modified too to make it "nightly", and since it's different from what will be on Flathub will not be representative for what people actually get once there is a new release.

[PureTryOut]

So for future reference when submitting to Flathub, this is the flatpak-flutter.yaml used to generate the finale manifest and module sources when used with https://github.com/TheAppgineer/flatpak-flutter:

id: de.provokateurin.neon
runtime: org.freedesktop.Platform
runtime-version: '25.08'
sdk: org.freedesktop.Sdk
sdk-extensions:
  - org.freedesktop.Sdk.Extension.llvm20
command: nextcloud-neon
finish-args:
  - --share=ipc
  - --socket=fallback-x11
  - --socket=wayland
  - --share=network
  - --device=dri
modules:
  - name: neon
    buildsystem: simple
    build-options:
      arch:
        x86_64:
          env:
            BUNDLE_PATH: packages/neon_framework/example/build/linux/x64/release/bundle
        aarch64:
          env:
            BUNDLE_PATH: packages/neon_framework/example/build/linux/arm64/release/bundle
      append-path: /usr/lib/sdk/llvm20/bin:/run/build/neon/flutter/bin
      prepend-ld-library-path: /usr/lib/sdk/llvm20/lib
      env:
        PUB_CACHE: /run/build/neon/.pub-cache
    build-commands:
      - mkdir /app/lib/
      - if [ "$arch" == "x86_64" ]; then ln -sf /usr/lib/x86_64-linux-gnu/libsqlite3.so.0 /app/lib/libsqlite3.so; fi
      - if [ "$arch" == "aarch64" ]; then ln -sf /usr/lib/aarch64-linux-gnu/libsqlite3.so.0 /app/lib/libsqlite3.so; fi
      - cd packages/neon_framework/example && flutter build linux --release --no-pub
      - install -D $BUNDLE_PATH/nextcloud-neon /app/bin/nextcloud-neon
      - cp -r $BUNDLE_PATH/lib /app/bin/lib
      - cp -r $BUNDLE_PATH/data /app/bin/data
      - install -Dm644 packages/neon_framework/example/de.provokateurin.neon.desktop -t /app/share/applications/
      - install -Dm644 packages/neon_framework/example/assets/logo_inverted.svg /app/share/icons/hicolor/scalable/apps/de.provokateurin.neon.svg
    sources:
      - type: git
        url: https://github.com/nextcloud/neon.git
        commit: 93f74b2d818add82392d32495b1d2524dae80c01
      - type: git
        url: https://github.com/flutter/flutter.git
        tag: 3.38.9
        dest: flutter

The commit of course can be changed to point to any particular version that needs building.

I've edited this PR to just build from source using network access and using the local source as input so it doesn't have to be modified every time a dependency updates. This should be good to go!