feat: replace blackbox with ptyxis

[NN708]

• Removed Black Box and System Monitor (resolves Replace Black Box with Ptyxis as the default terminal #279, enhancement: replace System Monitor with more modern alternative #286).
• Added a setup script to automatically configure Ptyxis for vso-pico. The script is primarily intended for use with vso pico init (feat: setup terminal after pico init vanilla-system-operator#183), but can also be run manually to restore Ptyxis configuration if it was modified by the user, or if Ptyxis was not previously installed.
• Updated paths for VSO v3 compatibility.

[jardon]

we likely need to provide an alternative to the rescue shell

[NN708]

@jardon Thank you for your review! I tried to handle this carefully (reset-vso resets the Ptyxis profile back to the host shell, regardless of whether it was created by setup-vso-terminal or manually by the user). However, you are right that edge cases remain. If a user deletes apx-vso-pico container manually via Podman or Distrobox, Ptyxis will display a "Cannot locate container" error and prompt the user to edit the profile. Alternatively, they can still access the host shell directly from the top-left menu (as shown below).

[taukakao]

I'm very against having a flatpak app as the only installed terminal emulator.
Flatpak needs a lot of parts to function. If any of these parts fail, it should always still be possible to open a shell and not everyone knows about TTYs.

[NN708]

I'm very against having a flatpak app as the only installed terminal emulator.

I would say it's not the only installed terminal emulator, it's just the default one we provide. If a user prefers, it can be easily uninstalled, as not everyone requires a terminal emulator.

Flatpak needs a lot of parts to function. If any of these parts fail, it should always still be possible to open a shell and not everyone knows about TTYs.

If Flatpak was to fails, it would mean that almost every app would be unusable, then we would definitely not release that version.

I think we should give users the freedom to choose whether they need a terminal emulator, and which one to install. Even Apple now allows users to remove most built-in apps on iOS (except essential ones like App Store and Settings). The same applies here: users can always reinstall Ptyxis anytime via GNOME Software, and run setup-vso-terminal to restore the configuration.

[taukakao]

Flatpak failing could be caused by some local configuration, it wouldn't necessrily affect everyone.

I'd also argue that a TE is an essential app on Linux.

[NN708]

Flatpak failing could be caused by some local configuration, it wouldn't necessrily affect everyone.

In that case, simply uninstall Ptyxis using the "delete app data" option and reinstall it, which is the common troubleshooting step users would expect for any misbehaving app. This is actually a benefit of Flatpak, as this is much simpler than dealing with an app installed directly on the host system.

I'd also argue that a TE is an essential app on Linux.

That's true for Linux in general, but Vanilla OS has a vision of being easy to use for everyone. It is designed to "just work" for general use without a terminal emulator, much like iOS, Android and ChromeOS which we aim to compete with.

[taukakao]

I meant a misconfiguration of something like flatpak or systemd, not Ptyxis itself.

Also, while it would definitely be nice to not need a TE, we are simply not there yet.

[NN708]

I meant a misconfiguration of something like flatpak or systemd, not Ptyxis itself.

Flatpak does not rely on systemd (ref).

Regarding Flatpak configuration, issues can sometimes arise if a user manually revokes permissions using flatpak override. This can still be fixed without a terminal by installing Flatseal from GNOME Software and resetting the app's permissions there.

That said, a detailed guide for troubleshooting apps would be helpful, but that's a general need, not specific to terminal emulators.

Also, while it would definitely be nice to not need a TE, we are simply not there yet.

I'd say we're getting quite close. If you stick to apps from Flathub, it's already more than enough for everyday use, since system updates are handled automatically.

[taukakao]

I never said it relied on systemd, but systemd handles starting the daemons that are, for example, needed to run flatpak-spawn --host.
It also doesn't matter, my point is that with a flatpak app, a lot more things can break than with a simple app on the host, since flatpak is a much more involved environment.

[NN708]

@taukakao I see your point now. You're right that a host install is simpler for the app. However, I would prioritize the long-term simplicity and stability of the entire system.

I consider Flatpak a core OS component, similar to the desktop environment, and in practice it's extremely robust. If a user were to somehow manage to break Flatpak, they would just as easily break the whole desktop environment as well. This marginal risk is far outweighed by its systemic benefits: automatic updates, guaranteed dependency correctness, and the ability to completely reset an app's state if needed. Therefore, I still believe Flatpak packaging should be used whenever possible.

[mirkobrombin]

I'm very against having a flatpak app as the only installed terminal emulator. Flatpak needs a lot of parts to function. If any of these parts fail, it should always still be possible to open a shell and not everyone knows about TTYs.

Agree with this

[NN708]

We've recently received user feedback that having the terminal emulator installed on the host system while also being available as a Flatpak creates confusion in GNOME Software. Users still see an "Install" button for the same app that already installed, and installing the Flatpak version overrides the host-installed one with a different configuration. By making the Flatpak version the default, we can ensure a more consistent user experience.

Additionally, we need Ptyxis 49.3 for compatibility with Apx subsystems, which is not yet available in Debian sid. If we stick with the host-installed version, we will have to wait until it enters sid. While I'm happy to wait here for that, I still prefer the Flatpak approach, and would like to proceed with it if everyone approves.

[NN708]

Ptyxis has now been updated in Debian sid, but directly to version 50.beta, skipping 49.3 entirely. So I'd like to revisit which approach we should take:

1. Adopt the Flatpak approach to ensure we always use stable versions. The pros and cons have already been discussed above.
2. Wait another month for version 50.0, but this would severely limit our ability to increase release frequency in the future.
3. Accept using a beta version, but this introduces potential stability risks.

I'd love to hear everyone's thoughts on this.

[taukakao]

We already accept the risk of using beta software, since we are using debian sid snapshots.