feat: launcher gui

[iamllama]

To run, install tauri's system dependencies, cli (cargo) and then, in the repo root, cargo tauri dev with .\yarn ld in another window

• Error handling and display
  • Check if os/glibc ver. is supported
• Uninstall isn't implemented yet
• Refactors
  • The uv code was almost wholesale transplanted from the old launcher (with modifications for pty) and is in dire need of a cleanup but I didn't want to spend time on major changes without checking if any of this is acceptable (😅) and if we still want to keep the cli around?
  • UI state needs reworking, versions should be queried on app launch, not on svelte mount
• CI
  • svelte-check action for the launcher
  • target for installing tauri cli tool
• UI design
  Tentatively based it on the options pages (i probably won't be of much help here)

Closes #4152

EDIT: CI is missing some of tauri's needed system deps

[dae]

This is impressive work llama! I'll need a bit more time to review the current code properly, but I wanted to give you some quick feedback to unblock you.

• Happy with the general direction, and don't think we'll want to keep around the terminal-based approach with this in place, subject to the next point. Given that, it might be nice if the code for this lived in qt/launcher, as that'll also make it easier to track any changes made to the old launcher code.
• We'll probably want to get an alpha build of this into the hands of testers as soon as basic functionality is working on all platforms, so we can identify any unanticipated compatibility issues that might prevent us from switching away from the terminal approach.
• Not urgent, but it would be nice if our build system eventually provides a target that takes care of installing the cli tool (like we do for cargo-nextest).
• Your pty approach saves us a bunch of work, and may end up being our best approach. Downside is that we won't be able to show overall progress to users who might be daunted by the per-package output. It might be worth starting a discussion with uv about possible alternatives, such as a flag that restricts progress to a single overall bar, or exposes progress events over a socket or the network. If they're amenable to something like that and we decide it's a good idea, we could send through a PR to make it easier for them to accept.
• I wasn't able to test the install process on a Mac, as I get the following during startup:

thread 'tokio-runtime-worker' panicked at qt/launcher-gui/src-tauri/src/commands.rs:140:58:
called Result::unwrap() on an Err value: Read "/Users/dae/Local/rust/Resources/.python-version"

The existing code expects the launcher binary to be run from within an app bundle. This is how the layout looks like for the terminal version:

$ ls -aR ../../../out/launcher/Anki.app
.        ..       Contents

../../../out/launcher/Anki.app/Contents:
.          ..         Info.plist MacOS      Resources

../../../out/launcher/Anki.app/Contents/MacOS:
.                 ..                install_name_tool launcher          uv

../../../out/launcher/Anki.app/Contents/Resources:
.               ..              .python-version Assets.car      pyproject.toml  versions.py

build.sh in qt/launcher/mac takes care of the building that folder after compiling. If you don't have access to a Mac, I can take care of this before the alpha test.

Should hopefully have more comments in the next few days!

[dae]

I probably won't have a chance to circle back to this until late this week/early next week :-( If you're blocked on anything, please let me know and I'll try to get to that earlier.

[dae]

Just wanted to give you a bit of an update/some background.

The decision to go with a launcher approach was partly due to feeling overwhelmed, and wanting to reduce the overhead of making releases. I figured it'd get users something close to auto-update support at the same time, so it seemed like a win-win. But between uv edge cases and users' eyes glazing over the moment a terminal window appears, it hasn't been as smooth as I'd hoped.

A launcher GUI is the logical next step. It should solve a bunch of pain points/be more user-friendly. But it doesn't solve all problems (e.g. #4151), and some users want to be able to do a single download without subsequent extra downloads.

Months back Andrew floated the idea of using Briefcase instead, which is closer to our old PyOxidizer setup. We have extra hands at our disposal now, making maintenance less of a concern, so that may be more practical now. I think we might want to explore that path in more detail (only a very basic PoC so far), and then decide whether to persist down the launcher path, provide both in parallel, use some hybrid approach, or switch over to a more conventional packaged build.