Live data from Hacker News

Use Alacritty instead of Termite

github.com

191–200 of 331 posts

Re: Use Alacritty instead of Termite

#191
post #185

Earlier quoted context omitted.

>This is about the needs of users and developers. I know, I'm saying that app developers and users want CSD in some form eventually. I've seen this trend everywhere. You may not want them on your system and you're entitled to that opinion, but some app developers do want them. >That's the point I'm trying to drive in here. GNOME devs feel like they can just break existing behaviors and ecosystems if they feel like it…

>I know, I'm saying that app developers and users want CSD in some form eventually. I've seen this trend everywhere. You may not want them on your system and you're entitled to that opinion, but some app developers do want them. It feels like we are just going in circles now. Other compositors give the option for both. GNOME only gives the option for CSD, and tells others to "fix their app". You can use SSD or CSD, I…

>Other compositors give the option for both. GNOME only gives the option for CSD, and tells others to "fix their app". You can use SSD or CSD, I don't care, but I also don't want to hear "this app doesn't work on mutter", or "use libgtk to make this app work on our special compositor".

I'm sorry I'm confused. I was responding to your suggestion earlier about making it SSD only, which I think is much less feasible than having it be CSD only. I believe I've said my position regarding the option already: If the problem is the apps don't want to write their own code for drawing window decorations, there are multiple solutions to that aside from SSD, that would require about the same amount of code in clients as SSD would. So to me it's not really an issue of the app working in mutter or not, or needing to link against gtk, or whatever. It can all be handled transparently with the right solution. Maybe eventually someone could create a version of libwayland that handles decorations transparently, with no changes needed to the apps at all.

Re: Use Alacritty instead of Termite

#192
post #187

Earlier quoted context omitted.

> don't make the mistake of thinking their libraries are meant for others to use I agree. This presentation convinced me: https://youtu.be/ON0A1dsQOV0?t=2468 GTK+ is really just a toolkit for GNOME projects. All other users are secondary.

To give another perspective, that presentation is from 7 years ago and does not reflect the current state of things. The situation has improved and currently some GNOME functionality is being moved out of GTK into a new library, so GTK can focus on being its own library: https://aplazas.pages.gitlab.gnome.org/blog/blog/2021/03/31/...

Are you affiliated with GNOME?

Re: Use Alacritty instead of Termite

#193
post #187

Earlier quoted context omitted.

To give another perspective, that presentation is from 7 years ago and does not reflect the current state of things. The situation has improved and currently some GNOME functionality is being moved out of GTK into a new library, so GTK can focus on being its own library: https://aplazas.pages.gitlab.gnome.org/blog/blog/2021/03/31/...

Are you affiliated with GNOME?

No, I'm just an app developer who used GTK recently and noticed that a lot of what people say about it is based on out-of-date information. My experience really wasn't that bad, progress is being made and issues are being addressed, even though it's not happening as fast as some would like. For whatever reason there is a staggering amount of misinformation in these HN threads.

Re: Use Alacritty instead of Termite

#194
post #40

Earlier quoted context omitted.

Gnome developers actively hate their users and non-gnome developers. This issue takes the cake: https://gitlab.gnome.org/GNOME/mutter/-/issues/217

If that's your best argument against Gnome it seems like they are doing pretty well. Decorations can be done client-side with a library if needed - there is no reason to push that work to the compositor.

>> Decorations can be done client-side with a library if needed - there is no reason to push that work to the compositor.

In a wayland system the compositor IS the desktop shell. Window placement is not up to the application, so moving them and hence putting "handles" on them in the form of decorations is a natural fit for the compositor.

Another feature that belongs in the compositor is remembering where each application was last placed and sized and replicating that when starting them. I agree with the Wayland ideas that programs do not have the ability to warp mouse pointer or know about their environment, but once that model has been adopted there are useful features that need to move (or for decorations should move) into the compositor.

Re: Use Alacritty instead of Termite

#195
I was considering switching to Alacritty earlier this week, but a quick look at some github issues changed my mind. The devs come off super toxic.

Take a look at this guy that got verbal abuse for pointing out the color labeled "green" looks more like banana than lime:

https://github.com/alacritty/alacritty/issues/1561

Strike 2/2 was multiple devs responding to OSX issues with "switch operating systems"

Re: Use Alacritty instead of Termite

#196
post #5

Does Alacritty still require you to copy terminfo to remote servers in order for backspace to work? I loved Alacritty, but copying terminfo every time gets old pretty quickly.

ncurses/terminfo is pretty fundamentally broken for the modern SSH/Tmux use-case.

For example a few years ago I tried to enable 24-bit ("truecolor") support...

For one thing, the terminfo reporting for 24-bit color support wasn't universally recognized: terminfo added an 'RGB' capability to report this, but because this was added only "recently" (as far as terminals are concerned), not all programs relied on it. For example, Emacs or Vim didn't seem to use this capability.

For another thing, there can be a mismatch between what the local and remote terminfo databases (provided by ncurses) support in terms of recognized capabilities. I had tried to copy the xterm-direct terminfo to the remote, but it wasn't recognized! Turned out it had to be compiled with the remote server's tic.

Supposedly the Terminals Working Group [1] was looking into overhauling the ancient terminfo system to support this, but there was no clear path forward. I suppose one of the problems is the massive backwards-compatibility requirement. (There is probably nothing else in the software ecosystem that requires such backwards compatibility as terminals, they literally trace their ancestry to the 19th century! [2] )

[1] https://gitlab.freedesktop.org/terminal-wg

[2] https://en.wikipedia.org/wiki/Teleprinter

Re: Use Alacritty instead of Termite

#197

I was considering switching to Alacritty earlier this week, but a quick look at some github issues changed my mind. The devs come off super toxic. Take a look at this guy that got verbal abuse for pointing out the color labeled "green" looks more like banana than lime: https://github.com/alacritty/alacritty/issues/1561 Strike 2/2 was multiple devs responding to OSX issues with "switch operating systems"

That was my conclusion as well after my limited interactions with them. I no longer use it.

Re: Use Alacritty instead of Termite

#198
post #126

Earlier quoted context omitted.

The issue is that Electron and SDL will fix this 10 years later, old apps will still not work. Same issue with tray icons, GNOME is expecting cross platform apps will use their shirty design OR their users will use only new GNOME apps. >You could also say that SSD would mean that Mutter needs to do extra work just to satisfy an application designer ego Is better that say all the 10 WM implement SSD (maybe as a fallba…

> The issue is that Electron and SDL will fix this 10 years later, old apps will still not work. The SSD in GNOME still works for X11 apps. For now the only path for old apps that need SSD is to continue using the X11 backend in Electron and SDL. For GNOME, SSD was never in the plan with wayland, so this is not breaking compatibility with apps there because it was never supported.

>> so this is not breaking compatibility with apps there because it was never supported.

It's not breaking GTK apps. If they want to say GNOME really only works with GTK apps that's fine and the toolkit will provide the decorations and nobody needs to care which part of the system draws them. But they want to support more than just GTK apps and rightly so.

Re: Use Alacritty instead of Termite

#199

I was considering switching to Alacritty earlier this week, but a quick look at some github issues changed my mind. The devs come off super toxic. Take a look at this guy that got verbal abuse for pointing out the color labeled "green" looks more like banana than lime: https://github.com/alacritty/alacritty/issues/1561 Strike 2/2 was multiple devs responding to OSX issues with "switch operating systems"

Oof, that interaction was uncomfortable. Definitely a very bad look for that dev.

Re: Use Alacritty instead of Termite

#200
post #39
post #5

Does Alacritty still require you to copy terminfo to remote servers in order for backspace to work? I loved Alacritty, but copying terminfo every time gets old pretty quickly.

short-term: Add the terminfo file to your vm provisioning tooling: ansible, terraform, etc long-term: Maintain an alacritty package in your distro of choice so the terminfo is automatically included

I can just imagine me chatting with devops people:

- Hi Jeff, I know you have a todo queue from here till the next century, but please add one more item, having all our VMs, however they built, to include this set of files. I need it ASAP since without it if I log in to a server, I can't use backspace.

- What? Why? This looks like lots of work to modify each one of our 10000 deployments. It also may create some bugs and using non-standard deployment packages is time-consuming. What's wrong with plain old ssh, it works everywhere? What's wrong with your backspace, maybe I should order you a new keyboard?

- Well, ssh is fine but you see, I've got this new OpenGL super-fancy terminal emulator, and if I use it to ssh into a random server my backspace doesn't work. So if you changed every deployment we have to support it, that would be great, mmmkay? Oh and longer term I also need you to maintain a custom package for every linux distribution we might use that fixes this issue.

- Are you high? Did you check you temperature lately - maybe you have a high fever and your mental capacities are compromised?

- Hold on, Jeff, don't you think me using a fancy terminal program than can scroll 35% faster worth the effort? And it's also written in Rust! You could use it too, it's really awesome unless you need the backspace key for some weird reason.

- clickety click I've disabled all your shell access to all our servers until your mental health improves, and asked HR to issue you a week of sick days. Please get well soon.

Post reply on HN