Linux packaging docs

[eira-fransham]

No description provided.

[tronical]

Very nice. This is fairly brief and not too much boilerplate. A few comments within. The biggest pain point that I can see is the skia side. See comments within for three options.

[tronical]

Since we're in the guide section, I don't think it's really necessary to justify our choice of Flatpak. A short reference to the alternatives is fine IMO. We're not competing with anyone here :)

[tronical]

This is a positive key phrase :)

[tronical]

This could be the box where you could very briefly mention alternatives IMO.

[tronical]

If there's doubt, then I think there's value in explaining it. Otherwise, I think it's better to just state the fact to avoid leaving the reader hanging. Here, I'd just stick to org.freedesktop.Platform and that's it.

A comment on the version might be more relevant, perhaps with a link where readers can find out what versions exists and if it's worth upgrading.

[tronical]

This remains an open point.

[tronical]

This refers to the visual editor. Subsequent for all the skia related bits, I strongly suggest to leave those out of these instructions for now. There's value in supporting Skia here, but I think that could almost go into a separate section.

That said, it's in our interest to support Skia (for our own needs), and for Linux then alternative that I think is easier to support, without the need to hard-code URLs like the above), is to build skia from sources. I think automating that will be easier because instead of the user having to figure out skia-binaries-a25a0fdb7d90429... type of URLs, we can use the existing meta-data in skia-bindings to determine the correct url for the source sources and prepare that.

I tried a local build with skia sources (by setting SKIA_SOURCE_DIR) and that works within the sandbox.

So I see three paths forward:

1. We keep the above as it is. I'd prefer not, because it'll be outdated by the time we release Slint 1.18.
2. We omit skia from the instructions for now and I'll try to create a separate PR to add a section and a helper script for apps that would like to include it and then the build will build it from source.
3. I'll try to finish my experiment with from-source build and we incorporate it in this PR.

[eira-fransham]

My preferred path would be 3, although personally I think this is fine. I give instructions on how to figure out which URL to include.

Not that you're suggesting this, but I definitely don't think that leaving it out is an option since Skia is the best-supported renderer. All of those options are viable though, I wouldn't be unhappy with any of them.

[tronical]

I've included my instructions, so you get to choose :)

[tronical]

One idea I've had is that perhaps it would make sense to integrate this into https://github.com/slint-ui/slint-rust-template . Our tutorial, the vs code extension's quick pick, etc. all use the templates and it would be most convenience to have them in there (maybe in a packaging sub-directory). That's not an acceptance criteria for this PR, but if you feel that this makes sense, please feel free to connect it :)

[tronical]

I also needed this:

sdk-extensions:
  - org.freedesktop.Sdk.Extension.rust-stable

[eira-fransham]

Ah, I meant to mention that below in the Rust section. Good catch.

[tronical]

On second thought, don't we always need this? For C++ we surely do. For Python and Node.js what's in this template is incomplete.

[tronical]

Here's what I ended up with in terms of Skia support that's perhaps a bit easier to maintain:

• Added - org.freedesktop.Sdk.Extension.llvm20 to sdk-extensions.
• In the build-options an append-path with /usr/lib/sdk/rust-stable/bin:/usr/lib/sdk/llvm20/bin
• Claude wrote this little generator python script: https://gist.github.com/tronical/b31e4542b99b0de1a6b1f7ddcb4636c2 . Running it generates skia-sources.json and prints the gn revision needed for the source build.
• gn becomes a module to build:

 - name: gn
    buildsystem: simple
    build-commands:
      - python3 build/gen.py --out-path=out --allow-warnings
      - ninja -C out gn
      - install -Dm0755 out/gn ${FLATPAK_DEST}/bin/gn
    sources:
      - type: git
        url: https://gn.googlesource.com/gn.git
        commit: b2afae122eeb6ce09c52d63f67dc53fc517dbdc8 # sha1 taken from flatpak-skia-generator.py output
        disable-shallow-clone: true   # gn's build derives its version from tags

• The env is extended with

        SKIA_SOURCE_DIR: /run/build/my-app/deps/skia-src
        SKIA_GN_COMMAND: /app/bin/gn
        LIBCLANG_PATH: /usr/lib/sdk/llvm20/lib

• The cleanup section is extended to also remove /bin/gn

So if the application uses Skia, the dependency is in the lock file, the python script extracts the correct sources and writes them into the sources json file, and gn may or may not be updated (it's not updated frequently IIRC). Overall I think that's not too bad, we could have the python script in our repo and link to it (like we do for the iOS build script), and we could use this ourselves for the visual editor.

Suggested options remain, I just wanted to present my findings that IMO make the from-source build easier to maintain.

[eira-fransham]

One idea I've had is that perhaps it would make sense to integrate this into https://github.com/slint-ui/slint-rust-template . Our tutorial, the vs code extension's quick pick, etc. all use the templates and it would be most convenience to have them in there (maybe in a packaging sub-directory). That's not an acceptance criteria for this PR, but if you feel that this makes sense, please feel free to connect it :)

In my opinion, I think we should make a separate project. Putting the .yaml file in the project root is an ok solution, but imperfect. It's one thing to have that be the method in the docs, where we can explain that it's imperfect, it's quite another to have it in the template.

Here's what I ended up with in terms of Skia support that's perhaps a bit easier to maintain:

Funnily enough, I originally wrote out something extremely similar in the docs as a small bash script, but then decided it was overcomplicating things. Just checking the version with cargo metadata, looking at the git tag, then finding the correct binary using the hash tied to that tag. I dropped it because I thought it was overcomplicating things, though.

[tronical]

One idea I've had is that perhaps it would make sense to integrate this into https://github.com/slint-ui/slint-rust-template . Our tutorial, the vs code extension's quick pick, etc. all use the templates and it would be most convenience to have them in there (maybe in a packaging sub-directory). That's not an acceptance criteria for this PR, but if you feel that this makes sense, please feel free to connect it :)

In my opinion, I think we should make a separate project. Putting the .yaml file in the project root is an ok solution, but imperfect. It's one thing to have that be the method in the docs, where we can explain that it's imperfect, it's quite another to have it in the template.

That's fine with me :)

[eira-fransham]

gn becomes a module to build:

Using FLATPAK_DEST installs gn into the final output package, it should be installed into /run/build/... or something like that. I honestly think that even if my method is complex, we should avoid recommending that users use some unofficial Python script and add more complexity to their yaml to build gn etc. Your method is better in some ways, but it adds more friction to the very common usecase of just wanting to use Skia inside of a Flatpak-distributed Slint application. I mention ways to figure out if the version of skia-binaries is out of date and how to figure out the correct one, we can try to keep the URL correct when we update to the next version of Slint but even if we don't the user has the tools necessary to fix it.

[tronical]

This remains an open point.

[tronical]

On second thought, don't we always need this? For C++ we surely do. For Python and Node.js what's in this template is incomplete.