> I never thought about running the terminal emulator itself in a bwrap session, but I am eager to learn what those optimizations entail.
This is a pretty common scenario on immutable distros, and any power user who attempted to run a terminal emulator from a Flatpak would soon find out much of a pain it is. From what I recall, the main limitation is not having full access to the host processes, not having full access to the filesystem, and a few other Flatpak/bwrap induced restrictions.
Kwi solves the first problem by launching your shell directly on the host via D-bus, so the shell has full access to the host. Note that the terminal device itself still sits in the sandbox.
As for the file handling, it's mainly when you click on filesystem links, instead of going thru the xdg portal system like most portal apps, it again uses uses host execution method and calls `kde-open` to open the link via host's file handler, and furthermore, ensuring that the new window takes focus instead of remaining in the background (due to Wayland behaviour).
There's some other minor code around host process tracking and exit handling.
All of this makes the Flatpak version of the app behave like a native app (so don't rely on anything being actually sandboxed, if you're operating under that assumption).
Nothing too fancy honestly - Konsole inspects process metadata on the host via `flatpak-spawn`, which has a high overhead. Kwi makes D-Bus calls instead and saves a few processes/forks, and hence CPU. It's a fairly minor item on the list, all things considered.
There are some more ambitious approaches, like Ptyxis which runs an agent process on the host and talks to it over a socket pair, but I didn't want to invite that complexity just yet.
9 years down the line, people are still believing the blurbs on the WWW that in fact pre-date systemd-consoled. Whilst Kmscon itself still exists, having spent the time from roughly when David Hermann (now Rheinsberg) pulled it from systemd until 2025 under the stewardship of Peifeng Yu, there's no sign yet that people who make distributions are building Linux as a general rule with the in-kernel terminal emulator cut out.
Would that they were! I, for one, first proposed this in 2006.
Anyone can run a userspace virtual terminal system. I've been doing so for over a decade. It's cutting the terminal emulator out of the kernel (for which there has been a configuration option for years) that the distributors are not doing. Fedora is not doing that here the same as everyone else has not done that.
Sooooooo computers are fast now. we don't have to miserly conserve every single bit and cycle.
Monospace font is required because "i" and "m" are differently wide, and because computers were slow, rendering text to the screen was hard. We don't live in that world anymire though. TLS protects every action you take on the web with a giant pile of math that would make the first computers choke.
Kwi seems to follow in those footsteps and continue this abuse of typography and beauty.
I'm pretty sure it started with typewriters. And now just about every command line tool, REPL and traditional roguelike depends on the font being monospace if you want it to look right.
It's also the only way to get perfect alignment in plain text. With proportional fonts you need a full GUI library.
For kwi to win I would expect both more features and fewer computing resources (cpu, ram, gpu if any).
Imho, more features alone is not enough as it brings more complexity and lower maintainability.
> I never thought about running the terminal emulator itself in a bwrap session, but I am eager to learn what those optimizations entail.
This is a pretty common scenario on immutable distros, and any power user who attempted to run a terminal emulator from a Flatpak would soon find out much of a pain it is. From what I recall, the main limitation is not having full access to the host processes, not having full access to the filesystem, and a few other Flatpak/bwrap induced restrictions.
Kwi solves the first problem by launching your shell directly on the host via D-bus, so the shell has full access to the host. Note that the terminal device itself still sits in the sandbox.
As for the file handling, it's mainly when you click on filesystem links, instead of going thru the xdg portal system like most portal apps, it again uses uses host execution method and calls `kde-open` to open the link via host's file handler, and furthermore, ensuring that the new window takes focus instead of remaining in the background (due to Wayland behaviour).
There's some other minor code around host process tracking and exit handling.
All of this makes the Flatpak version of the app behave like a native app (so don't rely on anything being actually sandboxed, if you're operating under that assumption).
Nothing too fancy honestly - Konsole inspects process metadata on the host via `flatpak-spawn`, which has a high overhead. Kwi makes D-Bus calls instead and saves a few processes/forks, and hence CPU. It's a fairly minor item on the list, all things considered.
There are some more ambitious approaches, like Ptyxis which runs an agent process on the host and talks to it over a socket pair, but I didn't want to invite that complexity just yet.
(Kwi author here.)
Prefer non qtquick apps, as they use 10x more memory.
Really hope Yakuake would also benefit from this development.
It can - Kwi also embeds into Yakuake :-) At the moment this takes a little bit of fiddling still, but hopefully it will be simple to choose soon.
Can you elaborate on that? I use yakuake and I don't understand the connection. (I am merely a user not a software development or engineer)
> Linux distributions are currently moving away from the in-kernel virtual terminal to better userspace solutions, generally Kmscon.
As I noted 9 years ago, Kmscon got pulled into systemd with much fanfare, and then was quietly dropped with a lot less fanfare.
* https://news.ycombinator.com/item?id=16014573
9 years down the line, people are still believing the blurbs on the WWW that in fact pre-date systemd-consoled. Whilst Kmscon itself still exists, having spent the time from roughly when David Hermann (now Rheinsberg) pulled it from systemd until 2025 under the stewardship of Peifeng Yu, there's no sign yet that people who make distributions are building Linux as a general rule with the in-kernel terminal emulator cut out.
Would that they were! I, for one, first proposed this in 2006.
Fedora just did.
https://fedoraproject.org/wiki/Releases/45/ChangeSet#Use_kms...
No, it did not. As it says:
> fbcon will still be compiled in the kernel
Anyone can run a userspace virtual terminal system. I've been doing so for over a decade. It's cutting the terminal emulator out of the kernel (for which there has been a configuration option for years) that the distributors are not doing. Fedora is not doing that here the same as everyone else has not done that.
20 years and counting …
Sooooooo computers are fast now. we don't have to miserly conserve every single bit and cycle.
Monospace font is required because "i" and "m" are differently wide, and because computers were slow, rendering text to the screen was hard. We don't live in that world anymire though. TLS protects every action you take on the web with a giant pile of math that would make the first computers choke.
Kwi seems to follow in those footsteps and continue this abuse of typography and beauty.
> we don't have to miserly conserve every single bit and cycle.
Have you seen the memory prices recently? I'd say this attitude is what got us to a point where just loading up the OS takes 2-4GB.
I'm pretty sure it started with typewriters. And now just about every command line tool, REPL and traditional roguelike depends on the font being monospace if you want it to look right.
It's also the only way to get perfect alignment in plain text. With proportional fonts you need a full GUI library.