I highly-valued the cohesion and simplicity of having a suite of tools provided by a single vendor and all on a single bill, despite how often this turns into a vendor-lock-in strategy

Proton was part of my attempt to de-Google, precisely because it offered email (with custom CNAMEs), calendar, and storage, and because they open-sourced their clients and tools

Despite the UX and feature set being quite bare, I was okay with justifying this with the added privacy (which was a nice-to-have but not a deal-breaker for me)

It seems like all the alternatives are either less open-source, have even fewer features, are even less cohesive (indeed, I’d have to select entirely separate solutions and give up all integrations) or seem to have even fewer resources for development and project sustainability

I’d moved from Bitwarden to Proton Pass only 6 months ago, so moving back wasn’t too much of a difficult choice (both services have great import/export and Bitwarden even offers self-hosting)

Thanks for sharing! <3

Okay, let’s go with xterm running bash, where the user ran ls, so xterm -> bash -> ls …

• ls never talks to xterm directly, it’s stdout/stderr are provided by bash
• bash effectively outputs a grid of characters to xterm, xterm doesn’t know about prompts or words or line feeds, just the grid
• every time ls outputs a line, bash adds a row of output to the grid that it sends to xterm
• if there’s not enough space for a new row, bash discards the top-most row, moves all other rows up by one row, and then inserts the row for the ls output

Now imagine a hypothetical fork of bash or some other new shell …

• the only thing different is the direction that the rows move off the edge of the screen when running out of space, that’s all

Thus, this is entirely a shell problem, with a shell solution

However, what I’ve neglected to mention so far is that terminal emulators and shells are almost certainly optimised for rows dropping off the top edge and new rows being added to the bottom edge

So, the role of a terminal emulator in this scenario could be to provide ANSI control characters or other protocol for operating just as quickly in the opposite direction, sure

Seems like a shell feature, and not a feature that a terminal emulator would implement

I’m not an expert, but my understanding of the Global Shortcuts portal is that it’s very much designed for the push-to-talk use case where an app is not focused but still receives button events for exactly the keys its interested in and no other keys: I think this would cause problems if an app requested every key (e.g. if the request was approved then no keys would work in every other app)

It’ll be interesting to see how the remaining compatibility/accessibility issues are tackled, either in portals or in wayland protocols

There’s a portal for Global Shortcuts: https://flatpak.github.io/xdg-desktop-portal/docs/doc-org.freedesktop.portal.GlobalShortcuts.html

KDE and Hyprland already implement it, and COSMIC seems likely to

On the app side, if we can get the major toolkits to adopt it, then hopefully that covers most actively-maintained apps (but it’s unlikely to cover legacy apps): https://github.com/electron/electron/issues/38288