and it's performant af, you won't need to use a 3rd party terminal to get all the performance goodie
and it's performant af, you won't need to use a 3rd party terminal to get all the performance goodies
FWhat is performance of the terminal? How fast it executes commands?
Jgpu rendering, etc.
JJGNOME developer Christian Hergert recently demonstrated how Linux terminal emulators have the potential of running much faster
FI just run normal commands without TUI apps like nvtop, htop etc., so I guess I won't see a difference
FBut I will try Prompt for container integration
TDefinitely want to try out Prompt, but it seems like waiting for stable is a good call given the devel flatpak seems a little broken for me
MAre you on nvidia?
TYes
MGitLab
OS: Arch Linux GNOME 45.1, Wayland session HW: NVIDIA 3060, proprietary driver 545.29.02 gtk4 1:4.13.3+r44+g
TWell that'd do it
TProbably because prompt pulls in a newer gtk with this bug than what the rest of the system is using
Kwhich is also likely because it's in the nightly gnome repo
TYep
JWill Nvidia users have this problem with a stable release in flathub?
TMy other flatpaks seem to be fine, but I'm guessing yes whenever the gtk4 in the runtime gets updated (unless they push a fix before then)
TSeems like
GDK_DEBUG=gl-prefer-gl works as a temp workaroundTA stable release of prompt against the current runtime will probably be fine
MYeah this appears to be a bigger issue for gtk to solve.
TActually I'm not sure. Looks like the current runtime would need to be updated before a stable release would work since prompt depends on things not in the current one
SJFGitHub
... or remove packages that aren't there.
By @EyeCantCU
Took from Bazzite.
Please check if I did changes correctly.
By @EyeCantCU
Took from Bazzite.
Please check if I did changes correctly.
FThanks
Bi'm not aware of an upstream bug for this, it's just "the way it is" and we've had to rehash it a few times because people don't believe me when I say so 
This is exactly why I have made a point to err on the side of keeping our
This is exactly why I have made a point to err on the side of keeping our
-mainYeah I'm just hoping to have one place to point people so we don't have to keep explaining it over and over
Byeah... i'm searing a bit for another explanation online but not finding one
BIt really seems like something which should be covered in this doc: https://coreos.github.io/rpm-ostree/container/#rebasing-a-client-system
BI added a comment to the issue.
Bit is possible to disable but not remove becuase of very basic fact that it is using a OCI IMAGE with some packages disabling works with some it doesnt but from what i have seen not being disabled is mostly function of is it a dependency of something
EI wonder how much bigger the image would be if we embedded just Prompt. Of course, that would come with its own issue of missing updates until the image received an update but it would mean GNOME Terminal could be removed without consequences
Jyeah or perhaps as an rpm, but there are vte patches, I figure for now let's let the people who want to opt in play while we discuss with christian on how to do it in a way that works. I kinda don't wanna package it because he put a ton of effort making it flatpak friendly.
BIn my image i plan to keep gnome-terminal if for no other reason as a backup
BBut prompt is a must have
CI don't like the idea of replacing Gnome Terminal with Prompt because Prompt is just about the worst possible name for a terminal app and makes troubleshooting nearly impossible
CThe repo is unsearchable unless you have a direct link
CAlso, Gnome Terminal has been a reliable and decently feature-complete default for years, while Prompt looks like this for me:
CThe features I've seen y'all describe sound neat, and I'm all for modern GUI features in a terminal app, but I am not confident in Prompt's readiness for prime time as a default, let alone a singular option with Gnome Terminal completely removed
CMostly the issue for me is that it is unsearchable, so it is difficult or impossible for me to find information about Prompt which could address my other concerns
Jyours looks like that because you're on nvidia and it's a nightly snapshot, by the time it lands in flathub you shouldn't have that issue
J
Jlol
EI applied but... Didn't go so hot
CFingers crossed. I'll keep an eye on it
Jit's only a few weeks old
Emaybe prompt could benefit a search-friendly alias, like how go has golang
CI think so
J@xyny images-website had a bunch of dependabot updates backed up and some of them were pretty severe so I merged them, everything appears to be working normally so just a heads up
KWant to give this a try for me? You can run it through distro box
