I wonder why fedora creators have chosen Ptyxis, is it because more lightweight?
With the Nvidia or GTK4 bug that we live today old terminal could launch and this new cannot.
To install old gnome terminal you would need to layer it?
The Ptyxis terminal is developed by the same person who was already backporting most of the modern features like GTK4 to the Gnome terminal. They created Ptyxis to be more compatible with container environments, which suits the atomic desktops like Silverblue better that have become increasingly popular in the last few years. Ptyxis may become the default terminal for Gnome vanilla overall, but Fedora took a step in advance by already adopting it as the default Fedora terminal for F41.
It should be a drop-in replacement for the earlier Gnome terminal. If you encounter any bugs or issues you can file a bugreport on the Gitlab tracker. The developer is actively working with the Fedora maintainers to fix bugs and optimize compatibility.
The old gnome-terminal
is a legacy-gtk app, and some of the current issues are related to gtk4
apps, as noticed.
Ptyxis is being worked on by the same person who was already mostly maintaining GNOME Terminal (the “old” terminal app), but Ptyxis uses libadwaita and has better support for containers like toolbox, which benefits those using Silverblue and co.
If you’re having issues launching the terminal, you should probably create another thread for that.
Assuming you’re using Atomic, I think so. I haven’t used Atomic in a hot minute, though.
A bigger question might be why not kgx
since it’s what upstream GNOME uses
They’re mostly the same thing (GTK4) even down to how they look, but iirc ptyxis
made mention of being specialized for Containers.
Fedora already decided to diverge from upstream by not shipping Console.
Besides both using GTK 4 and libadwaita, they are not similar applications. Console is meant as an “oh no, I’m a novice user who needs a terminal for this very specific and unexpected emergency scenario!”. Console doesn’t have profiles, color schemes, font settings, cursor settings, or any of the other kjghpillion settings that people who use a terminal on the daily want and need.
Added ptyxis
I don’t think I like a new terminal. I just discovered that he doesn’t warn about the ongoing closing process.
If there is a running program Ptyxis will ask if you want to close the window:
There is also an option in the preferences to remember the session:
Having said that, there are many other terminals in the repositories. If Ptyxis doesn’t work well for you, you can try out a few others.
Recovering a session only restores tabs, does not resume processes, it is completely different. I’ve run a sh script with a series of rsync. And it does not display the question about closing the window. But maybe it’s a problem because of the update, I haven’t installed the fresh fedora again. Or maybe I found a situation where the window does not appear. This requires further investigation and I may report this as a problem.
It’s standard behaviour. Bash can run interactively or non-interactively, the commands contained in a user script will be run non-interactively which means they will be forked to the background. If you want to avoid that clicking on the window (x) closes the terminal, then you need to run the process in the foreground. You can do this by starting the script with:
$ source myscript.sh
instead of the default
$ ./myscript.sh
When you then click (x) Ptyxis will ask if you want to terminate the script and close the terminal:
So there’s something for it. :D. The old terminal displayed the question. But your advice works. That’s interesting. Thanks a lot.
But that is running in the foreground!?!?
Sounds more like new shell processes are not handled properly:
$ cat >/dev/null
$ sh -c 'cat >/dev/null'
The former asks whether I want to close the window while a command is running, the latter does not.
It’s a bit tricky / confusing.
What Bash does by default if it encounters a shell command or script (shebang) is spawn a new shell process in which it executes that command. So the current shell process which invokes the command does not know the running status of that command.
When using source
Bash will execute the command directly in the current shell process, so the terminal will know that the process is running and will not close the window without confirmation.
But no-one wants to source a script that is executable.
It’s executable for a reason.
This all sounds to me like a bug, I’d suggest reporting it and seeing what the maintainers think.
You can look up 10+ year old stackoverflow threads about this behaviour and you will find roughly the same explanation as i gave:
I’m inclined to agree with @barryascott on this one.
The post you’ve pointed to describes a difference in shell context, not whether or not the subshell process is a child to the current shell.
If the subshell invoked via a shell script in the current shell would die should the current shell be killed, then I think there should be a warning just like any other shell-accessible command.
We have no argument with there being a difference. Bu it’s just a context difference for the shell commands in the script being in a subshell vs in the current shell.
But, for the script, that subshell is itself a command being run by the current interactive shell in the terminal window. If that command will be killed by killing the parent shell, then I think there should be a warning just as there is for any other command.