Live data from Hacker News

Use Alacritty instead of Termite

github.com

211–220 of 331 posts

Re: Use Alacritty instead of Termite

#211
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. 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.

From what I have seen, I don't believe they ever intended to support those apps that didn't provide decorations. The move towards CSD was intentional for them and started 10 years ago, and supporting those CSD apps is the primary focus. This wasn't a problem for Qt apps either because Qt does provide decorations.

Re: Use Alacritty instead of Termite

#212
post #92

Earlier quoted context omitted.

Electron uses Gtk and Games should use SDL2. They will support CSD, which is work, but it will happen. You could also say that SSD would mean that Mutter needs to do extra work just to satisfy an application designer ego. Btw: I'm a GNOME user who is against SSD.

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.

Old apps should dynamically link SDL / Gtk+ / Qt so they should work. For other old apps there's Xwayland which still provides SSD in GNOME.

Re: Use Alacritty instead of Termite

#213

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"

To be fair, I thought the dev’s response was adequate here. Just posting on the issue section that the “colors are wrong” while comparing with uxrvt, without any explanation or self-investigation as to why this could be a problem, has ample potential to be regarded as rude to the devs (I’m using this another terminal app and have better colors, why aren’t you fixing this?) And please note that Mac OS is NOTORIOUS for…

IDK, the screenshot posted makes what is supposed to be pretty primary (OK secondary) color green look like yellow. Color in terminals is pretty important; if I configured something to use ANSI green and it came out like Alacritty rendered it, I'd think something was off. Why is the default theme not standard?

And FWIW, that website they're all referencing absolutely will not say a color contains mostly "yellow" (it reports the highest RGB value), no matter what you do [1].

[1]: https://www.color-hex.com/color/feff00

Re: Use Alacritty instead of Termite

#214

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"

To be fair, I thought the dev’s response was adequate here. Just posting on the issue section that the “colors are wrong” while comparing with uxrvt, without any explanation or self-investigation as to why this could be a problem, has ample potential to be regarded as rude to the devs (I’m using this another terminal app and have better colors, why aren’t you fixing this?) And please note that Mac OS is NOTORIOUS for…

Yes, it can be frustrating when your users don't know as much about your product as you do and ask for help in a vague way. It's unintuitive that a color named green would correspond to the color on the left that I don't think most people would think to check.

It's totally fine to have a policy of not supporting OSX, as long as you communicate it with professionalism or at least civility.

Re: Use Alacritty instead of Termite

#215
post #202
post #174

Earlier quoted context omitted.

>How can they otherwise ignore such an obvious, massive load of complaints with such disrespectful and dismissive comments? [...] We're talking multiple or many seconds of wait and stress that this behaviour can cause, even on beefy machines. I don't think the complaints were ignored, multiple other tickets with concrete work items were opened in response to the complaints. There is a ticket open to improve the speed…

You can keep the type-ahead functionality while also implementing proper full search like every other OS available does. It doesn't need to be a one or the other type deal. File Explorer in the last 4 major Windows releases has a search box in the top right of the window, while also supporting a type-ahead search as well. There's no reason why GNOME can't also do that. I don't think you'll ever be able to improve the…

>It doesn't need to be a one or the other type deal.

Sadly it does. Search is currently the default. If you bring back type-ahead, that will de-prioritize search. Nautilus could copy the Windows approach but that would also bring along with it all the issues of the Windows approach, where there are two similar options with subtlely different behavior of how they match against file names, with no clear explanation to the user why this is or why some files are accessible in one way but not the other. You and I may be familiar with the approach because we're used to it but other users might not. I've seen some users that have been using Windows for decades and still they have no idea what type-ahead is because they never even thought to type into the file manager.

>I don't think you'll ever be able to improve the speed of a full search to a point that it'll match the performance of a type-ahead style search.

Why not? I would think search would actually be faster, because that only has to show a few relevant search results, whereas type-ahead has to keep scrolling the view around and reflowing the whole folder.

Re: Use Alacritty instead of Termite

#216

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"

To be fair, I thought the dev’s response was adequate here. Just posting on the issue section that the “colors are wrong” while comparing with uxrvt, without any explanation or self-investigation as to why this could be a problem, has ample potential to be regarded as rude to the devs (I’m using this another terminal app and have better colors, why aren’t you fixing this?) And please note that Mac OS is NOTORIOUS for…

If MacOS support is terrible, then they could either not advertise it[1] or disclaim it results in poor UX.

https://github.com/alacritty/alacritty#installation

Labeling a piece of software as "cross platform" without testing on all platforms comes across as dishonest.

Re: Use Alacritty instead of Termite

#217
post #215
post #202

Earlier quoted context omitted.

You can keep the type-ahead functionality while also implementing proper full search like every other OS available does. It doesn't need to be a one or the other type deal. File Explorer in the last 4 major Windows releases has a search box in the top right of the window, while also supporting a type-ahead search as well. There's no reason why GNOME can't also do that. I don't think you'll ever be able to improve the…

>It doesn't need to be a one or the other type deal. Sadly it does. Search is currently the default. If you bring back type-ahead, that will de-prioritize search. Nautilus could copy the Windows approach but that would also bring along with it all the issues of the Windows approach, where there are two similar options with subtlely different behavior of how they match against file names, with no clear explanation to…

> I've seen some users that have been using Windows for decades and still they have no idea what type-ahead is because they never even thought to type into the file manager.

Haven't thought of typing into the file manager, like most non-programmers probably. And how does that support your argument that re-instroducing Type Ahead would de-prioritize search for them?

> I would think search would actually be faster, because that only has to show a few relevant search results, whereas type-ahead has to keep scrolling the view around and reflowing the whole folder.

Search could be faster if reading the directory was the FAST operation and displaying was the SLOW operation.

You can cook up situations where that is the case, like when the application has the directory cached in memory and / or the directory has (recursively) very few entries AND the display is actually on the other end of a remote desktop connection in the Siberian Sea so that it might matter whether you display 1 or 3 folder icons.

In more realistic cases, like where you have 10GB/s of memory access performance and a fast link to the GPU/display, but file systems that are still comparatively slow (especially with regards to filepath lookup, especially for directory trees that are routinely gigabytes in size / routinely have 1000s of entries in 100s of subdirectories), that will never be the case, not by a factor of 10s of 1000s.

Re: Use Alacritty instead of Termite

#218
post #215

Earlier quoted context omitted.

>It doesn't need to be a one or the other type deal. Sadly it does. Search is currently the default. If you bring back type-ahead, that will de-prioritize search. Nautilus could copy the Windows approach but that would also bring along with it all the issues of the Windows approach, where there are two similar options with subtlely different behavior of how they match against file names, with no clear explanation to…

> I've seen some users that have been using Windows for decades and still they have no idea what type-ahead is because they never even thought to type into the file manager. Haven't thought of typing into the file manager, like most non-programmers probably. And how does that support your argument that re-instroducing Type Ahead would de-prioritize search for them? > I would think search would actually be faster, bec…

If you don't preload the folder contents and index it then type-ahead will also be arbitrarily slow there too. I don't know of any Linux filesystem that stores the files sorted and indexed on disk.

>And how does that support your argument that re-instroducing Type Ahead would de-prioritize search for them?

The idea I got from reading the GNOME HIG is that if users accidentally type into the window, the behavior should be consistent and predictable with what the user was really trying to do (search). Doing a strange and inconsistent matching behavior that is not available through any other means and is essentially hidden functionality is only going to cause confusion.

Re: Use Alacritty instead of Termite

#219
post #218

Earlier quoted context omitted.

> I've seen some users that have been using Windows for decades and still they have no idea what type-ahead is because they never even thought to type into the file manager. Haven't thought of typing into the file manager, like most non-programmers probably. And how does that support your argument that re-instroducing Type Ahead would de-prioritize search for them? > I would think search would actually be faster, bec…

If you don't preload the folder contents and index it then type-ahead will also be arbitrarily slow there too. I don't know of any Linux filesystem that stores the files sorted and indexed on disk. >And how does that support your argument that re-instroducing Type Ahead would de-prioritize search for them? The idea I got from reading the GNOME HIG is that if users accidentally type into the window, the behavior shoul…

But why would you rely on the filesystem to implement Type-Ahead? The File Manager just goes through that little list of files that it has already cached because it is displaying them anyway.

And it just goes through the list linearly, starting from the currently highlighted item, stopping at the first match.

It's a miniscule operation.

--

Speaking practically, have you ever experienced any file manager that has type-ahead (like most do) and the type ahead was not blazingly fast?

> The idea I got from reading the GNOME HIG is that if users accidentally type into the window, the behavior should be consistent and predictable with what the user was really trying to do (search). Doing a strange and inconsistent matching behavior that is not available through any other means and is essentially hidden functionality is only going to cause confusion.

If you're refusing to see that they achieved just the opposite and broke a totally sane implementation that was super predictable for any user that actually cared about their workflow, you can't be helped.

Re: Use Alacritty instead of Termite

#220

Earlier quoted context omitted.

The other dev chiming in at the end with "I've heard only good things about Alacritty's default colorscheme so far" was also frustrating. Saying "well nobody else complained" is an awful reason to dismiss an issue.

Considering this is their reaction to someone pointing out that their green is actually yellow, I'm not surprised that they are in an echo chamber.

Echo chamber is one term, another would be tribe.

An insecure group member feels threatened by an outsider and lashes out. Another group member sees an outsider triggering a group member and he immediately jumps into help. Together, they attack the outsider and drive him off.

I think if the maintainer was less insecure and more able to take critique, the exchange wouldn't have aroused the "fight or flight" instincts of the group.

Post reply on HN