alt Hacker News> Then it's not "exactly like" what I would do at all - you'd take your hand off your keyboard and switch to your mouse to use a graphical file manager tool.
Definitely yes. That's what I'd definitely do. But there is no inherent reason for that. It just feels superior to me. Why should graphical applications be fundamentally worse (e.g. in terms of keyboard support) than terminal applications when terminal emulators are a graphical application?
> And you'd wait for however long dolphin takes
Yes. All these 800ms! Every single day!
> And you'd wait for however long dolphin takes to start and enumerate the thousand files in that directory, and you'd watch your disk spin and your ram usage shoot up while it previews all the image files and videos in the directory, and counts items in the subdirectories.
Yeah, well, technically, of course. It just never felt like "waiting". It's a matter of milliseconds. And while it enumerates the thousands of files, I can already start working with the first ones. I don't have to wait for some software from the 80s that blocks user input meanwhile. BTW, terminal applications don't need to enumerate directories when they deal with it? How does that work? Even if you just press "tab" in your shell, it will probably do exactly that, no? I really don't see why terminal applications should be fundamentally faster than graphical applications in that regard (again: your terminal emulator is a graphical application, right?). If you know the file name starts with "cat_s", then you can also find it this way in Dolphin.
There are corner cases where I really search in a trickier, more dynamic way. Maybe with "find". Or five lines of Python scripting. But not hundred times a day. Definitely it's not worth rewriting every application now as a terminal app (that tries to be a graphical app via niche-in-niche technologies).
> Notice how you're starting a thousand different things in your examples? Yeah, I'm just doing all that from a single program.
Yes, that's one of the things that I feel so spooky with that approach. It cannot work... Not in general. Maybe for a handful of persons that constantly search for jpeg/png/mpeg files, in bulk mode, and need quick previews. For whatever actual job they are doing there...
> Yes. All these 800ms!
For you. This one time that you tested. It took almost an entire second. Or, another way you could say that would be "longer than it takes terminology to pop up a preview".
> Yeah, well, technically, of course. It just never felt like "waiting". It's a matter of milliseconds
Well then either dolphin is by some miracle orders of magnitude faster than any file browser I have ever seen (which includes earlier versions of dolphin that presumably have fewer features than the current one), or you're not viewing folders containing many files. Or maybe you just have the fastest and most powerful computer ever built. Or perhaps you just don't have any expectation of a performant UI and consider twiddling your thumbs to be no big deal.
> terminal applications don't need to enumerate directories when they deal with it? How does that work?
They do need to enumerate files, obviously, but they don't need to - for each and every file and subdirectory:
1. determine the mimetype for the tile, which may involve actually opening and reading the file
2. look up that mimetype in their "mime type -> friendly description" table
3. look up the default application that needs to be opened if you double-click on said file based on that mimetype
4. if the mimetype is "video" or "image", look in their cache for a thumbnail for the file, and if that doesn't exist fire up a thumbnailer to generate one, which likely involves opening and reading in the entire file.
6. load the aforementioned thumbnail into memory and display it in the appropriate place
7. as previously mentioned, enumerate and count the number of items in directories
8. I'm sure a bunch of other similar things that I can't even be bothered trying to remember right now.
...interrogate every single file for its mimetype, load up a thumbnail for every single media file, and count the number of items in every single subdirectory? No, it will not do that when I press tab. ..........um, what?Seems to me like maybe you've never used a terminal program? Or perhaps you've never used a gui program? I'm not sure what to say to this. I don't think I've ever seen a piece of GUI software which comes close to the speed of its terminal-based equivalent. I'll grant you there are outliers, but those are rare and every single example I can think of doesn't use a GUI toolkit.
There are a few factors at play here. One big one (maybe the biggest?) is simply the complexity of the interface: Terminal emulators are built and optimised to display a whole bunch of text very quickly. They have one job: display text. GUIs and GUI toolkits, on the other hand, are huge complex libraries with a large number of different controls that they need to draw in the right place, do layout, have to deal with mouse interaction and event systems and the windowing system, deal with weird input methods and accessibility, etc etc etc etc etc etc etc. They're orders of magnitude more complex just in their interfaces. And that's before you start doing things like loading icons for every little button you're displaying and thumbnailing every media file in a directory so that you can load it as a pretty icon in your file manager. And before you start taking into account that a lot of gui software is just poorly written trash seemingly written by morons under the CADT model (Hi, gnome!).
GUIs are fine, and the best option for a bunch of things. But they're much MUCH less efficient than terminal-based programs.
I don't know what else to say. Go talk to every single GUI application author ever, I guess?
Yes. One that's using a very limited set of GUI widgets compared to almost any other graphical program, and which has one job: display text. Indeed, the speed of terminals does have a marked effect on the speed of program execution in many cases: just try doing `time cp -Rv /usr /some/new/disk` - you'll spend a LOT of time just listing the hundreds of thousands of kilobyte-sized files you're copying, and the amount of text you're spitting out and scrolling your terminal emulator needs to do will slow down the file copying. If you compare this with `time cp -R /usr /some/new/disk` you'll find the non-verbose incantation to be much faster. Part of this is the fact that it doesn't need to run the printf statements, but much more of it is the time the terminal takes to output what is being printed, and especially scrolling. You'll also notice a pretty significant difference depending on which terminal you use - xterm will be faster than gnome-terminal, for example, because it's not bloated trash. KDE's terminal might be better than gnome's, but it will almost certainly not beat xterm. Nor will terminology. Similarly, running the verbose copy in a screen session and then switching to another 'window' in screen will speed up the copy, because even though it's verbose and running the printf statements, the terminal doesn't actually have to do the work of displaying the huge stream of text. Similarly, you can do a crude benchmark of your terminal's efficiency with bash by just spitting out a long line of text a million times and timing how long that takes. Sure. After you've waited almost an entire second, if you're lucky, for dolphin to start, and waited for it to enumerate all the files, and waited for it to count subdirectories, and waited for it to check its cache for thumbnails, etc etc etc etc etc etc.Meanwhile, like I said, I'll already be half way through previewing the video, and my workflow won't involve switching to some worse program.
I'm not even sure what point you're trying to make here - that sometimes your preferred method is even more shit, and so you sometimes have to fall back to the one I default to? Who said anything about rewriting all programs for the terminal? Why would you do that? I already specifically said that "We do also use our graphical environment". Who said terminology is "trying to be a graphical app"? I'm not sure why you insist on making this so complicated or acting like it's scary somehow. I've already told you that it does, in fact, work. Very very well. Maybe you should try it out so that you have some idea what you're talking about before you start telling me that things I do all the time "cannot work". Did I say I use it "constantly"? I don't recall saying that. I use it as often as I need to. Because I can. Because it's there.And it's a better experience in literally every way imaginable than firing up fucking dolphin and waiting for three ice ages and also an image/video viewer.