Flatpak

[JakobDev]

I created a Flatpak for SMB3-Foundry. This allows publishing on Flathub and installing on any Linux Distro out there (this does not work with the Binary). You need these files:

io.github.mchlnix.SMB3-Foundry.yaml

id: io.github.mchlnix.SMB3-Foundry
runtime: org.kde.Platform
runtime-version: '6.5'
sdk: org.kde.Sdk
command: foundry
sdk-extensions:
  - org.freedesktop.Sdk.Extension.llvm16
build-options:
    append-path: /usr/lib/sdk/llvm16/bin
    prepend-ld-library-path: /usr/lib/sdk/llvm16/lib
finish-args:
  - --socket=fallback-x11
  - --socket=wayland
  - --share=ipc
  - --device=dri

modules:
  - name: qt-include
    # https://bugreports.qt.io/projects/PYSIDE/issues/PYSIDE-787
    buildsystem: simple
    build-commands:
      - mkdir -p /app/include/qt
      - cp -R /usr/include/Qt* /app/include/qt
    cleanup:
      - /include

  - name: PySide6
    buildsystem: cmake-ninja
    builddir: true
    config-opts:
      - -DCMAKE_BUILD_TYPE=Release
      - -DBUILD_TESTS=OFF
    sources:
      - type: archive
        url: https://download.qt.io/official_releases/QtForPython/pyside6/PySide6-6.5.1.1-src/pyside-setup-everywhere-src-6.5.1.1.tar.xz
        sha256: 9741a06f0b7d4b2168818448134bc7e96ddb5efb846a3915b4177ba4159b5b78
      - type: shell
        commands:
          # use qt-include
          - sed -i 's|\(--include-paths=\)|\1/app/include/qt:|' sources/pyside6/cmake/Macros/PySideModules.cmake
          # fix python module search path
          - sed -i '/--sys-path\b/ a "${pysidebindings_BINARY_DIR}/.."' sources/pyside6/cmake/Macros/PySideModules.cmake
    cleanup:
      - /plugins
      - /include
      - /bin

  - python3-modules.yaml

  - name: SMB3-Foundry
    buildsystem: simple
    build-commands:
      - mkdir -p $FLATPAK_DEST/SMB3-Foundry
      - cp -r * $FLATPAK_DEST/SMB3-Foundry
      - install -Dm755 foundry.sh $FLATPAK_DEST/bin/foundry
    sources:
      - type: archive
        archive-type: tar-gzip
        url: https://api.github.com/repos/mchlnix/SMB3-Foundry/tarball/1.2
        sha256: 96f01cde6059415d7dfe71ee00801df067b51660dfc19ae051289cd21ed76a45
        x-checker-data:
            type: json
            url: https://api.github.com/repos/mchlnix/SMB3-Foundry/releases/latest
            version-query: .tag_name
            url-query: .tarball_url
            is-main-source: true
      - type: script
        dest-filename: foundry.sh
        commands:
          - cd /app/SMB3-Foundry
          - exec python ./smb3-foundry.py

python3-modules.yaml

# Generated with flatpak-pip-generator --yaml --checker-data py65 QDarkStyle
build-commands: []
buildsystem: simple
modules:
  - name: python3-py65
    buildsystem: simple
    build-commands:
      - pip3 install --verbose --exists-action=i --no-index --find-links="file://${PWD}"
        --prefix=${FLATPAK_DEST} "py65" --no-build-isolation
    sources:
      - type: file
        url: https://files.pythonhosted.org/packages/de/d0/8c07b2abfe19b4dad6640ac273e2b90072185425c1f3cdba7a82253597fa/py65-1.1.0-py2.py3-none-any.whl
        sha256: 43bae388727f130f7ce6fbadffc7d501fff05985b96813d2bcd3e6f00ea0d738
        x-checker-data:
          name: py65
          packagetype: bdist_wheel
          type: pypi
  - name: python3-QDarkStyle
    buildsystem: simple
    build-commands:
      - pip3 install --verbose --exists-action=i --no-index --find-links="file://${PWD}"
        --prefix=${FLATPAK_DEST} "QDarkStyle" --no-build-isolation
    sources:
      - type: file
        url: https://files.pythonhosted.org/packages/48/59/01f454d0eacb6670c77add68611b7a572455ae69ba902d270ed761869f87/QDarkStyle-3.1-py2.py3-none-any.whl
        sha256: 679a38fcd040de9fac8b8cae483310302fdb12c8d912845249c41dc54974a9b2
        x-checker-data:
          name: QDarkStyle
          packagetype: bdist_wheel
          type: pypi
      - type: file
        url: https://files.pythonhosted.org/packages/51/9f/495736f9bbebc56b9f2ba3d95df1045fd367378254f799e86463b0037ab0/QtPy-2.3.1-py3-none-any.whl
        sha256: 5193d20e0b16e4d9d3bc2c642d04d9f4e2c892590bd1b9c92bfe38a95d5a2e12
        x-checker-data:
          name: QtPy
          packagetype: bdist_wheel
          type: pypi
      - type: file
        url: https://files.pythonhosted.org/packages/ab/c3/57f0601a2d4fe15de7a553c00adbc901425661bf048f2a22dfc500caf121/packaging-23.1-py3-none-any.whl
        sha256: 994793af429502c4ea2ebf6bf664629d07c1a9fe974af92966e4b8d2df7edc61
        x-checker-data:
          name: packaging
          packagetype: bdist_wheel
          type: pypi
name: python3-modules

Check out the Documentation how to build this. Some things needs to be done e.g. launching the NES Emulator is not working, but it is general working. Tell me, if you are interested,

[mchlnix]

Interesting. Thanks for the work. Does launching the emulator not work because of some sandboxing?

[JakobDev]

Yes. Flatpak is a Container Format that is Sandboxed and has a Permission System. You can read more about Flatpak in the official Documentation. You have normally only access to what's available in the Sandbox. To solve the Emulator Problem, you have basically 3 Options:

1. Bundle a Emulator with the Flatpak. This guarantees a Emulator is always available. The downside is, that you need to Maintain the Emulator and you are responsible for it and all it's dependencies. It also means longer build time as the Emulator also needs to be built from source. User can also not use their favourite Emulator. Each Flatpak has also separate save locations. If a User uses the Emulator normally, it will have a separate configuration, which can confuse Users.
2. Use flatpak spwan --host. You can run any command on the Host system by using flatpak-spawn --host <command>. With this way, you don't need to change much. The Flatpak need the --talk-name=org.freedesktop.Flatpak permission to use this feature. The downside is, that this is not very welcome. You basically have a sandboxed Program that has the Permission to leave the Sandbox whenever it wants, so this is only used if Programs have a good reason for it e.g. they are Development tools.
3. Use xdg-open. This is the preferred Way. xdg-open <path> will just open a File with the Default Program for this file type. That means foe NES Roms that it will be opened in the Emulator chosen by the User. The downside is, that you have no control over it. You just call xdg-open <path> which tells the System to open this file with the default program and immediately exit. You don't know, how long the Emulator is running. It also don't work if the file is saved in /tmp.

If you built and installed the Flatpak, you can run flatpak run --command=bash io.github.mchlnix.SMB3-Foundry to open a interactive Shell inside the Flatpak and explore it a bit.

[JakobDev]

@mchlnix Any update on this?

[mchlnix]

Sorry, just getting back into it a bit. So option 1 is too much work and option 3 also doesn't sound great. I'd have to hope that the emulator is associated with the file type, which isn't always the case and then hope that the commandline interface supports just chugging a file at it.

Option 2 kind of defeats the purpose of the flatpack, so making a deb file for linux might make more sense then. Also the user would have to spawn the flatpack with --host if I read that correctly, or can you configure that somewhere?

In general it's a bit too much effort for me, although you've done a lot already.

If you are passionate about having a flatpack version, then you can go ahead and make one yourself. It looks like you've already done the leg work anyway.

So few people use the linux version, that I think most can probably just clone the repo and run it like that.

[JakobDev]

I'd have to hope that the emulator is associated with the file type, which isn't always the case

Don't worry. It's always the case. I haven''t seen an NES Emulator which don't do that. If no Program is registered, the User will be prompted to choose a Program to open with. On KDE for example you will see the following dialog, if no Emulator is installed:

and then hope that the commandline interface supports just chugging a file at it.

No need to hope. xdg-open works the same way as opening a file through the file manager. It is guaranteed to work.

Option 2 kind of defeats the purpose of the flatpack

It's the defeat's the purpose half. The App is no longer Sandboxed, but you can still install it on any Linux System.

so making a deb file for linux might make more sense then

A DEB file only works on Debian based Systems. A Flatpak works on any Linux System out there. You may also need to adjust the DEB file for different versions of Debian based Operating Systems.

Also the user would have to spawn the flatpack with --host if I read that correctly, or can you configure that somewhere?

No. That's the command you need to run inside the Flatpak. It works out of the box, as long as the Flatpak have the Permission.

So few people use the linux version, that I think most can probably just clone the repo and run it like that.

It don't hurt to give Linux Users a better experience. You App will be promoted on Flathub, can be installed with one click on every Linux Distro out there and is guaranteed to always work. Users will also get Updates automatically. That all comes free of charge.

[mchlnix]

I'll have another look, but I make no promises.

While a deb file only works on debian distros, afaik that's most users' distros. Not sure how widespread flatpaks are already. I had heard of them before, but never used them. An appimage almost makes more sense to me. They can also be updated in place and you don't need to download anything specific to make it work, iirc.

This is honestly something that could be contributed, if it's really wanted.

[JakobDev]

Not sure how widespread flatpaks are already. I had heard of them before, but never used them.

They are very Widespread today. Flatpak is preinstalled o many Linux Distros (e.g. Linux Mint, SteamOS) today. You can install Software from Flathub directly in the Software Center out of the box. If it's not pre installed, you can easily install it. It also allows Users to discover Software in an easy way. Many Users have Flatpak set up, as it's in many cases the best way to get the newest Software. Flathub has millions of active users.

An appimage almost makes more sense to me

You can have both. A Flatpak provides better integration into the System and is safer, while a AppImage is a more portable way, which has a few problems.

If you want to create an AppImage, you ca use my tool pyproject-appimage, which allows you to create AppImages of Python packages. The only thing you need to do is making SMB3-Foundry installable with pip. pyproject-appimage does the rest.

[mchlnix]

Ah, interesting. I'll have a look. I've been questioning releasing the editor as one executable, instead of just the source with an executable running the python code for a while. I did that because workshop did it before (although even that isn't really true).