Even if we don't ship it for Workstation, we may want to consider it specifically for Silverblue.

It does require patches to VTE but those are essentially the same patches we have today in Fedora but with lots of rebasing. So no big deal there. I will need to fix them up for the 0-76 branch of VTE anyway (which has differed enough from master to cause issues).

If you wanted it default for something like Silverblue, I would consider just calling it Terminal with a .desktop patch and perhaps even having an icon which fits better with the default aesthetic.

Yes please for Workstation too! As I said in the gnome-terminal -> gnome-console issue I'd very much rather Ptyxis (well, Prompt as it was known back then) instead of Console. It's just better in every single way.

I'm not quite so enthusiastic about replacing the default terminal application, but I would at least like to have it packaged so we can evaluate it.

FWIW, I also ported gnome-terminal to GTK 4 which will probably land in GNOME 47. So if you just want a GTK 4 based terminal which has accessibility, that should happen.

But that won't have any of the container'y patches because those only exist in Fedora and need to be rewritten to support that.

Please don't migrate to GTK4 terminal until keyboard shortcut bug is resolved (https://gitlab.gnome.org/GNOME/gtk/-/issues/5384). I don't want to accidentally break command execution trying to copy text with Ctrl+Shift+C (which is treated as Ctrl+C on non-Latin keyboard layouts).

FWIW, nearly every keyboard shortcut in Ptyxis is configurable.

It has been proposed for Incubator

It has been proposed for Incubator

From my perspective, I consider GNOME's choices here advisory. We are not GNOME and we make our own decisions based on our needs. This is why we ultimately didn't switch to kgx/gnome-console and I'm hesitant to make a call for ptyxis until we actually have it packaged in Fedora and can properly evaluate it.

Sure, but that works both ways because GNOME wants our feedback on Incubator apps. The Incubator process was designed specifically to avoid a repeat of the situation with kgx/console where the app entered GNOME core before downstream stakeholders were comfortable with it.

The patches we have currently will end up being in Fedora anyway (they're just rebased version of what's in Fedora's VTE patches). I can add a build-time switch for ptyxis-46 to remove the accessibility support at build time. That patch is in VTE master but will not be in VTE 0.76.

We just need Fedora to get VTE 0.76 packaged first then building Ptyxis should be pretty easy.

As for GNOME 47, we should be able to remove the VTE patches as there will be something that can be used instead in VTE (termprops). So rawhide, if using early snapshots of what will become 0.78, can move forward that way.

In doing so, Fedora will need to either remove the container'y patches from gnome-terminal (which the gnome-terminal authors prefer anyway) or port them to work like I've done for Ptyxis.

I use Ptyxis, and like it in general. What I miss with it is transparency of background. I'm not certain it is quite yet ready as the terminal for Fedora Workstation, but maybe in the atomic variants would make more sense to start.

Ptyxis has transparency, but you need to tweak the GSetting to enable it. That is because libadwaita does not support transparency yet well enough for the tab overview to not be glitchy.

Hello @hergertme ,
Thank you for pointing that out I will indeed try it. Like the terminal BTW.

This is still waiting on @catanzaro to complete the package review process. We cannot formally review this application until it's integrated into Fedora.

Here is the package review bug

Now built also for rawhide

Workstation WG has approved switching gnome-terminal to ptyxis, on the condition that orca must be able to read terminal text in rawhide.

(ptyxis is not accessible in F40, but we think it should already be accessible in rawhide. But we need to verify this.)

Workstation WG has approved switching gnome-terminal to ptyxis

I presume that this will increase duplicates of the GTK4 bug with Ctrl+Shift keyboard shortcuts (https://gitlab.gnome.org/GNOME/gtk/-/issues/5384). It's great that Ptyxis allows you to reassign keyboard shortcuts, but good defaults matter, and users will be confused when the Copy (Ctrl+Shift+C) shortcut acts like Undo (Ctrl+C) for non-English keyboard layouts.

So although we've had ptyxis in Fedora 40 for a while now, it looks like there were no successful builds in rawhide until today (thank you Jens!). I'm going to say it fails the accessibility test by default simply because it is not in the repos yet. I will check again tomorrow or later this week.

I presume that this will increase duplicates of the GTK4 bug with Ctrl+Shift keyboard shortcuts (https://gitlab.gnome.org/GNOME/gtk/-/issues/5384).

This looks like a problem with all GTK 4 apps though, not just the terminal?

I presume that this will increase duplicates of the GTK4 bug with Ctrl+Shift keyboard shortcuts (https://gitlab.gnome.org/GNOME/gtk/-/issues/5384).

This looks like a problem with all GTK 4 apps though, not just the terminal?

Yes, that's correct. The reason why I'm concerned about the terminal is because this issue can be very annoying there. For example, consider the following scenario. The person started kernel compilation, then switched to the chat application and used Ukrainian keyboard layout there. After switching back to the terminal, the person noticed some weird warning and decided to copy it with the familiar Ctrl+Shift+C shortcut. But instead, this shortcut interrupted the kernel compilation.

I am also interested in integration with Nautilus (something similar to gnome-terminal-nautilus). Fedora Silverblue downstream distro Bluefin, which already switched to Ptyxis, decided to use nautilus-open-any-terminal.

Yes, that's correct. The reason why I'm concerned about the terminal is because this issue can be very annoying there. For example, consider the following scenario. The person started kernel compilation, then switched to the chat application and used Ukrainian keyboard layout there. After switching back to the terminal, the person noticed some weird warning and decided to copy it with the familiar Ctrl+Shift+C shortcut. But instead, this shortcut interrupted the kernel compilation.

I think it's a persuasive argument to delay our switch to ptyxis, although I wish you had raised the problem sooner rather than after we approved the change. Except gnome-terminal is also going to have the exact same problem once it's updated to 47, so we'd have to delay updating that too. Hopefully we can resolve the upstream issue report.

I am also interested in integration with Nautilus (something similar to gnome-terminal-nautilus). Fedora Silverblue downstream distro Bluefin, which already switched to Ptyxis, decided to use nautilus-open-any-terminal.

I think our designers have intentionally not added a context menu item for opening the terminal.

Plugging in nautilus-open-any-terminal into Fedora Workstation/Silverblue should be done as a separate ticket. From my perspective, I'm open to considering this as an user experience enhancement for Fedora GNOME, but it should be separate from this ticket about Ptyxis.

@catanzaro Nautilus already includes built-in support for "Open in Console" menu item. As far as I know, this is intentional part of Files design. However, that menu item is hard-coded just for kgx and is invisible when kgx is not installed.

Ah OK. We could just patch it to use ptyxis instead then.

@catanzaro

I think it's a persuasive argument to delay our switch to ptyxis, although I wish you had raised the problem sooner rather than after we approved the change.

Well, I've actually raised this concern here before (although my previous attempt was less descriptive). Anyway, I'm really glad that you agree with me on the importance of this issue.

@ngompa

Plugging in nautilus-open-any-terminal into Fedora Workstation/Silverblue should be done as a separate ticket. From my perspective, I'm open to considering this as an user experience enhancement for Fedora GNOME, but it should be separate from this ticket about Ptyxis.

Ok, I've opened issue #442 for this.

I attempted to test accessibility again today, but ptyxis is still not available in rawhide yet. I guess we just need to wait another day?

Well, I've actually raised this concern here before (although my previous attempt was less descriptive). Anyway, I'm really glad that you agree with me on the importance of this issue.

Oops, sorry.

I attempted to test accessibility again today, but ptyxis is still not available in rawhide yet. I guess we just need to wait another day?

Previously it was blocked on a VTE 0.77 tag (for GNOME 47) which includes the new VTE termprops API. Ptyxis 47.alpha uses this instead of our many downstream VTE patches which can now be deleted for Fedora 41.

OK, well ptyxis became available in rawhide sometime between yesterday and today. Unfortunately I have tested it and confirmed that accessibility does not work: orca is not able to read any of the contents of the vte widget, whereas in gnome-terminal it works perfectly fine.

I know a bunch of upstream work has happened here, but evidently it's either not in Fedora yet or not working. Please let me know when to test again.

orca is not able to read any of the contents of the vte widget

Did you enable screen reader access in Ptyxis Preferences? It is off by default due to the overhead of GTK 4 a11y infrastructure not being lazy-by-default like Atk was.

We can, of course, change that if it's necessary with a distro gsettings schema override.

OK, it works fine with that preference checked.

I'm not a fan of having to enable accessibility on a per-application basis, but sounds like there are technical challenges behind the existence of that preference. (No way to detect whether the screen reader is running...?)

there are technical challenges behind the existence of that preference. (No way to detect whether the screen reader is running...?)

Correct.

I can certainly be persuaded to turn it on by default, it's not like I didn't try to optimize the heck out of it. But it really should be designed in GTK internals to know if there is an observer first.

I'm not sure if Newton is going in the right direction here either, but it should be possible with at-spi at some point.

I think we should have it turned on by default at least in Fedora, as otherwise there's an appearance of a significant regression as we make this transition.

I would also prefer to turn it on by default, but I'll leave that up to Christian. The capability of supporting screen reader is what I was checking for, and that is present.

Would also be really nice to see the shortcut issue fixed, but as that's a general GTK 4 issue and it's coming soon to gnome-terminal as well, I won't block on that.

We're going to do an experiment here: the new ptyxis will have a versioned Obsoletes such that it replaces gnome-terminal for anybody who has older versions of gnome-terminal installed. I'll add similar Obsoletes to loupe and snapshot as well. We'll never increase the version in the Obsoletes, so you can simply reinstall gnome-terminal once if you prefer to keep gnome-terminal. This way, users who don't do anything will transition to our newer default apps, and users who prefer the older apps can still keep them after doing one thing.

I'm certainly fine with Fedora shipping a gschema override to enable it by default, but I don't want to enable it by default in Ptyxis upstream until I'm confident in the GtkAccessibleText doing the right thing at the GTK and VTE levels.

I won't add any override.

We should ship the override. We will have major PR problems if we regress like this out of the box, especially in light of the larger a11y effort going on in Fedora.

OK, I will add an override. :P

Totally fine by me, I just want to make it clear that Fedora is pushing that forward, and therefore Fedora needs to step up from the standpoint of ensuring that our a11y is both functional, performant (and whatever that means), without melting the ice caps.

The VTE a11y code does try to be as efficient (if not more) as it can be implementing the same design as what was in VTE for GTK 3.

It snapshots the accessible text of the last drawn frame and the current drawn frame and tries to do a light diff between the two. That is then submitted to GTK internals to do whatever with it. So you are always clamped to your monitors hz at most.

If you're running btop or something at 200msec updates, that can be quite a bit of chatter and string copies but it's still negligable (sitting here on my M2 Pro Apple Silicon, where I'd probably not notice it anyway). I still barely noticed blips in the btop CPU graph.

Debian & Ubuntu will also include the override because of how impractical it is for someone who needs a screen reader to find that option in the app

So I started working on a commit to add the gschema override, but the package in rawhide is broken and unbuildable. It depends on vte 0.77, which is not available in rawhide yet. We'll need to wait for that before proceeding.

I'm not sure how Jens managed to build ptyxis-46.5-2.fc41, because that version was never committed to dist-git, which is very confusing. Did you somehow build the F41 package from the F40 branch?

Note that chpe added a tag for us yesterday (0.77.90) which can be used for rawhide containing all the termprops stuff.

https://gitlab.gnome.org/GNOME/vte/-/tree/0.77.90?ref_type=tags

Problem is the vte 0.77 update removed almost all of our downstream patches to vte, breaking our downstream patches for gnome-terminal which were not removed. That needs to be sorted out one way or the other before we can progress here. Reference

The goal of Ptyxis to begin with was so that we can ship an unmodified gnome-terminal to make upstream happy. So it should be "just delete the patches" from my PoV.

We're going to do an experiment here: the new ptyxis will have a versioned Obsoletes such that it replaces gnome-terminal for anybody who has older versions of gnome-terminal installed. I'll add similar Obsoletes to loupe and snapshot as well. We'll never increase the version in the Obsoletes, so you can simply reinstall gnome-terminal once if you prefer to keep gnome-terminal. This way, users who don't do anything will transition to our newer default apps, and users who prefer the older apps can still keep them after doing one thing.

Unfortunately this will cause gnome-terminal to be replaced with ptyxis on spins that may not want to make this transition, and we don't have a good way to conditionalize the upgrade to only Fedora Workstation. So I will avoid trying to add Obsoletes.

The goal of Ptyxis to begin with was so that we can ship an unmodified gnome-terminal to make upstream happy. So it should be "just delete the patches" from my PoV.

I agree, but Neal wants to make sure spin maintainers are OK with this.

Ultimately I'm just not sure what @amigadave is intending; clearly the patches were removed intentionally, but equally clearly gnome-terminal isn't ready for that yet. Let's wait for him.

It turns out that dnf system-upgrade will install the new applications because it updates comps groups. PackageKit, however, does not. I've reported a PackageKit issue.

OK, Nieves has successfully built ptyxis 47.beta in rawhide. I've added the gschema override.

Here is a comps pull request. If that doesn't land today before F41 gets branched, then we'll need to create a second one for F41.

Comps pull request has landed. We're done here. \o/

Users who upgrade from F39/F40 will unfortunately have to manually replace gnome-terminal with ptyxis until the PackageKit issue is fixed.

The current packaged version is missing translations:
https://bugzilla.redhat.com/show_bug.cgi?id=2311297

Users who upgrade from F39/F40 will unfortunately have to manually replace gnome-terminal with ptyxis until the PackageKit issue is fixed.

I just ran into this while testing a F41 upgrade and it was definitely a surprise. Two "Terminals" in the menu, differentiated only by color, and it's not even easy to figure out that the second one is "ptyxis". This app has no right-click menu entry with information, and the "burger" menu's "About" only describes it as "Terminal", which is not very perspicuous. If I click on the website, it's described as a terminal for a "container-oriented desktop", which is not what I associate with Fedora Workstation and I would never guess the appropriate workflow is to manually remove gnome-terminal.

Well that shouldn't have happened. The expected behavior is:

• If upgrading via dnf system-upgrade then gnome-terminal should be replaced with ptyxis
• If upgrading via GNOME Software (recommended), then gnome-terminal should remain installed and ptyxis should not get installed (due to this PackageKit bug causing comps to not be processed correctly)

Any idea how you wound up with both at the same time? Did you upgrade using dnf or using GNOME Software?

I followed the instructions here with dnf system-upgrade (I know I was two days early!): https://fedoraproject.org/wiki/Test_Day:2024-10-11_F41_Upgrade_Test_Day#How_to_test?

This was on a relatively fresh install of Fedora Workstation 40 (August 10) which I use Gnome Software to keep updated, although I ran the F41 upgrade with dnf as noted.

I wasn't really thinking when I reported this on Pagure; happy to move the conversation elsewhere if there's a more appropriate venue.