Live data from Hacker News

Use Alacritty instead of Termite

github.com

221–230 of 331 posts

Re: Use Alacritty instead of Termite

#221
post #218

Earlier quoted context omitted.

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…

Until global file indexing became a thing built into operating systems, every file manager was slow to open and sort directories with a lot of files. At least that was my experience. An index is still needed to do type-ahead, at minimum you'd need to build a prefix tree. You can't just load the list of files and be done; linear search will cause the same arbitrary slowness. Imagine typing an 'a' when on disk the all the 'a' files happen to be stored at the end of the directory. You would have to rescan the whole list every time you type another letter.

>you can't be helped

This is not the way to have a constructive conversation, please stop. I gave an example of how it's confusing and not predictable for some, let's discuss ways we can make it more predictable.

Re: Use Alacritty instead of Termite

#222

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"

Yeah, I side with the devs on that one.

Frankly, that is a total misrepresentation to call that verbal abuse. What it is, is frustrated devs dealing with a rudely worded and pointless issue.

That issue is literally just trying to start a bikeshed about a color in a standard color scheme they chose as the default. It could not be more useless. On top of that, they try to start that bikeshed by simply saying "the colors are wrong" and pointing to a terrible screenshot.

Open source devs have to deal with a ton of unproductive garbage issues that they are not paid to deal with which risks engendering total burnout. It is way too much to ask them to treat every single person with kid gloves especially when they are opening issues from a place of disrespect.

Re: Use Alacritty instead of Termite

#223

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.

>> GTK+ is really just a toolkit for GNOME projects. All other users are secondary. They do seem to be paying more attention to MacOS and Windows with GTK 4. I find the notion that GTK is just for GNOME rather funny since most the GNOME apps are very basic. The Software app is notoriously crap, but that's due to a lack of people to work on it. Their map app isn't much more than a GTK window frame on google maps or so…

GTK4 still doesn't support native rendering of window controls, so unless you're willing to create a faux "native" theme, your application will look like it doesn't belong on anything other than a Gnome desktop. I think it's idiotic and childish that the devs stick to their guns like this when there's clearly a high demand for a crucial feature like this. I dislike the project as a developer.

Don't get me wrong, I'm using a Gnome desktop for my day to day work. As a user, I enjoy the end result and I'm very happy with the way the system looks, but the absolute refusal to allow for any SSR has so far prevented me from ever seriously considering GTK for any cross-platform desktop application I'd like to write.

I don't really have a problem with the Gnome apps. There's nothing special about them, but they work and they're there. I quite like the software tool when it works, I've never managed to get Discover working for more than a few days so at least Gnome Software is stable in comparison. I also don't have any trouble with MPV for video playback. Sure, it doesn't contain a lot of power user features, but I only need it to play video files when I double click them, for anything else there's VLC.

Gnome, as a package to build a diatro around, works quite well. With a full Gnome setup, you can do almost everything you need to do on a computer. KDE is similar in that regard, although I really dislike the general UX of the KDE ecosystem for some reason.

On a side note, VLC is getting a (controversial) new UI that makes it look more slick and modern than the current design.

Re: Use Alacritty instead of Termite

#224

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"

I was experimenting with it this week as well, and that exact issue was what had me uninstall it. I guess this post doesn't add much value, but I thought the (synchronicity?) Of our experiences was interesting. It's a curious hill to die on, so to speak.

I imagine they would probably say the same thing to you.

You're really not willing to use an excellent piece of software because one time you saw a dev dismiss someone who didn't like the default color scheme? How is that not even more petty?

Re: Use Alacritty instead of Termite

#225
post #221

Earlier quoted context omitted.

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…

Until global file indexing became a thing built into operating systems, every file manager was slow to open and sort directories with a lot of files. At least that was my experience. An index is still needed to do type-ahead, at minimum you'd need to build a prefix tree. You can't just load the list of files and be done; linear search will cause the same arbitrary slowness. Imagine typing an 'a' when on disk the all…

See, you just iterate the list or array where you store the list items that you're pushing to the screen anyway. There is nothing at all that you need to add in terms of data structure. No index whatsoever.

> linear search will cause the same arbitrary slowness.

Let's see. My Thinkpad x220, which was built almost 10 years ago, can easily scan through 10 Gigabytes of memory per second. If we assume that visiting each list item causes a cache miss though (which is pessimistic), then (assuming a cache miss costs 100 nanoseconds) maybe we can visit roughly 10 million directory entries with the worst possible, dumb, serial implementation. Let's say we want to ensure a reasonable target of not wasting more than 1 millisecond for the search, we can still Type-Ahead through directories containing 10000 entries with incredible performance (1ms latency).

However, if the directory contents are stored only in a slightly reasonable structure (say, the developer spent the slightest thought at it, like caching the entries in a list of array chunks or so), then, I don't know, it might be closer to 100K entries per 1ms or even approach 1 million entries per 1ms with a little optimization.

It's not a problem at all, it's less than a piece of cake.

Re: Use Alacritty instead of Termite

#226

Earlier quoted context omitted.

>> GTK+ is really just a toolkit for GNOME projects. All other users are secondary. They do seem to be paying more attention to MacOS and Windows with GTK 4. I find the notion that GTK is just for GNOME rather funny since most the GNOME apps are very basic. The Software app is notoriously crap, but that's due to a lack of people to work on it. Their map app isn't much more than a GTK window frame on google maps or so…

GTK4 still doesn't support native rendering of window controls, so unless you're willing to create a faux "native" theme, your application will look like it doesn't belong on anything other than a Gnome desktop. I think it's idiotic and childish that the devs stick to their guns like this when there's clearly a high demand for a crucial feature like this. I dislike the project as a developer. Don't get me wrong, I'm…

>GTK4 still doesn't support native rendering of window controls

FYI this is not entirely correct. There is a flag for this in GDK4: https://developer.gnome.org/gdk4/4.0/GdkToplevel.html#gdk-to...

It may be that this is not implemented yet for some backends (I think it is not implemented in the Windows one) but they probably would accept a patch to implement it there if you know how to do it. Please avoid making these hostile assumptions about open source developers without having the full information. From what I have seen, there is a push recently to make GTK4 a better cross platform toolkit than GTK3 was.

Re: Use Alacritty instead of Termite

#227
post #221

Earlier quoted context omitted.

Until global file indexing became a thing built into operating systems, every file manager was slow to open and sort directories with a lot of files. At least that was my experience. An index is still needed to do type-ahead, at minimum you'd need to build a prefix tree. You can't just load the list of files and be done; linear search will cause the same arbitrary slowness. Imagine typing an 'a' when on disk the all…

See, you just iterate the list or array where you store the list items that you're pushing to the screen anyway. There is nothing at all that you need to add in terms of data structure. No index whatsoever. > linear search will cause the same arbitrary slowness. Let's see. My Thinkpad x220, which was built almost 10 years ago, can easily scan through 10 Gigabytes of memory per second. If we assume that visiting each…

If you're set on linear search then you would see the same performance for a simple search box too, I don't see how type-ahead changes it. For big folders you will still need an index, imagine now you sorted the list by reverse alphabetical, typing an 'a' is still going to be slow when you're at the top.

Re: Use Alacritty instead of Termite

#228
post #227

Earlier quoted context omitted.

See, you just iterate the list or array where you store the list items that you're pushing to the screen anyway. There is nothing at all that you need to add in terms of data structure. No index whatsoever. > linear search will cause the same arbitrary slowness. Let's see. My Thinkpad x220, which was built almost 10 years ago, can easily scan through 10 Gigabytes of memory per second. If we assume that visiting each…

If you're set on linear search then you would see the same performance for a simple search box too, I don't see how type-ahead changes it. For big folders you will still need an index, imagine now you sorted the list by reverse alphabetical, typing an 'a' is still going to be slow when you're at the top.

Again, the point is that type-ahead is an operation on the directory entries that are cached in the file manager's memory. It does not touch the file system at all.

That's why it is so fast in practice, it's instantaneous (as far as screen refreshs go) on every file manager I've ever used.

Recursive search however, does have to touch the filesystem, and does have to touch it massively for directories that contain thousands of subdirectories. That's what a "search" is, the user expects the search results to be fresh from the file system, not just scraped from a cache internal to the File Manager.

That's why recursive search is so disturbingly slow, to the point where it routinely takes seconds, or could even minutes depending on the setup (spinning drive + bad filesystem + large directory tree...).

And that is why Nautilus is basically unusable for me and a lot of other people.

By the way, there are other semantical problems with search vs Type-Ahead. For example, I cannot type a prefix in the current directory to see whether there is a file with that prefix in the current directory. Nautilus' recursive search will just pull up a completely unrelated and unexpected file from somewhere in this tree.

That means, that if I mistype, I don't get any reasonable feedback from Nautilus, but instead get a warm "thank you" and a huge diskload. It's about as depressing as browsing some websites that bombard you with ads and never show the contents you searched for.

Re: Use Alacritty instead of Termite

#229
post #72
post #29

Earlier quoted context omitted.

You can fix this by setting the following values in .config/alacritty/alacritty.yml: env: TERM: xterm-256color Another way is described here: https://wiki.archlinux.org/title/Alacritty#Terminal_function...

Setting TERM this way causes other subtle problems your local host. Instead I set `alias ssh="TERM=xterm-256color ssh"` which works pretty well.

What kinds of subtle problems?

Re: Use Alacritty instead of Termite

#230
post #221

Earlier quoted context omitted.

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…

Until global file indexing became a thing built into operating systems, every file manager was slow to open and sort directories with a lot of files. At least that was my experience. An index is still needed to do type-ahead, at minimum you'd need to build a prefix tree. You can't just load the list of files and be done; linear search will cause the same arbitrary slowness. Imagine typing an 'a' when on disk the all…

Win95 and Win98 had super fast file managers.

Hell, the whole 9x era of Windows would run laps around all these "modern" desktops.

Post reply on HN