(lol, split for length, 1/2) > But how often do I spontaneously need previews of something?
I don't know. Or care. I use it a bunch. Maybe you're conditioned not to do that because every time you do it, it takes you 10+ seconds rather then 1. Who knows? Who cares?
> can it show me the TOC of some pdf and allows me to navigate to some chapter?
I've already responded to this spurious scenario. Go read my previous responses.
> Well, there seem to be some use cases... Obviously...
Ooh, what a great concession.
> I still cannot imagine how they look like, though.
Could that be because you haven't tried it and don't understand what you're talking about?
> The performance was always good enough to be much faster than I am.
So in other words, you are slow.
> Before we now start to shoehorn graphical functionality into terminals, which we then only can use in graphical environments anyways,
Who shoehorned what? Where? You haven't read the specs for how it works, so you don't know what you're talking about. Still.
> shouldn't we better just improve the graphical apps?
So your suggestion is to add a terminal to every gui program in existence? I could point out how that's objectively worse in about a thousand ways, but instead I think I'll just let the absurdity of your entire premise sit.
> There is no inherent reason for them to be any worse than your terminal apps (that are eventually hosted by just an ordinary graphical app).
I've already explained, in great detail, that there is indeed an inherent reason why they're worse than terminal applications. Maybe you should consider reading the thing you're responding to.
> About your list what Dolphin needs to do but terminal apps don't: Yes, sure. A lot is going on. In the background. I don't have to wait for it to generate thumbnails.
You do if you want to see them
> It's not bash, which completely freezes then, e.g. when the network drive has a slow day, and I blatantly pressed Tab.
Dolphin does exactly nothing for exactly the same length of time (actually longer, due to all the extra shit it does) in this scenario.
> At least around 3000 files
So a tiny, trivial list of binaries then. That's about 40% the size of the directory where my binaries live.
> I would avoid having so many files in a single directory.
So in other words, dolphin, like every other graphical file manager, is slow as fuck working with directories with lots of files (where "lots" is a colloquial term for "really not very many at all"), and you adjust your workflow to compensate for how dog-slow your shitty gui file manager is.
My music directory contains over 80,000 files. Try opening that in dolphin, you'll learn the meaning of "slow".
> I instantly see it listing the files, and it felt finished instantly, and i was able to scroll around. No waiting time that would have blocked me.
No, you don't "instantly" see it listing files, because it has to open a window first, which you've already said takes ~800ms. You're just not aware of the wait time because you've conditioned yourself to accept constant context switches and thumb-twiddling in your slow DE.
But just as an experiment, why don't you "instantly" select the file named zcat.
> BTW: All the thumbnail stuff is done on demand, as soon as you scroll down.
So in other words: "in advance", while you wait, before you can see them.
> And finally: You can just turn it off! ;)
Dolphin has the ability to disable it's "double click to open file in the preferred editor" functionality, to avoid the need to determine mimetypes, does it?
> Counting the files, and determining which application is associated with a file type, are quite cheap operations
Hahahahahaha.
Hahahahahahahahahahahahahahahahahahaha!Someone has never looked at a directory with subdirectories containing 100K files or more in a graphical file manager.
Someone has never looked at his disk usage while that happens.
> But that's not because a terminal is the superior environment (how could it be if you just emulate it with the "bad" one).
Actually that's exactly why - terminals
are the superior environment.
"emulate it with the 'bad' one?" What are you talking about? Who said guis were bad? When?
> If all that 'modern' (win98) Dolphin magic is too slow, there are probably more lightweight alternatives that are still graphical.
Such as?
I look forward to seeing your list of graphical file managers that are faster (or even within an order of magnitude as fast as) ls. Please be exhaustive, I want to try them all!
> I still don't see the point in patching graphical features into something text-based, which you then need to run in an actual graphical environment
No, you don't see the point. We've already established this.
...Is your complaint here that you can't run these graphical terminal programs without having some sort of graphical environment running? i.e that it won't run on an actual text-only dumb terminal?
When was the last time you used a terminal in an environment where you didn't have hardware for graphics support?
And let's say you're one of the seven people on earth who does use a text-only dumb terminal daily: When did anybody advocate phasing out CLI software that doesn't use graphics features? How do you know that a bunch of this software with graphics support can't fall back to non-graphical options in non-graphical terminals? (hint: many/most can)
By the way, a bunch of actual "text-only" dumb terminals have had graphics support since the 1980s [1], and konsole has supported graphics for at least 5 years [2], and since 2022 it has supported the kitty graphics protocol [3]. Of course I'm sure you knew none of this because it took me >0 seconds of searching to look up the konsole support. I'm also sure this means konsole is broken and doesn't work, and the graphics support that's been there without your knowledge for half a decade has probably caused a bunch of bugs that you've been having trouble with, so I guess you should probably change terminals. Maybe to xterm... oh wait that's had sixel support for 6 years [4].
Here you go: phosphor [5]. I'm 90% sure this doesn't support graphics. And As a bonus, you'll be thrilled to know that it also doesn't support colour!
> let's today start porting all our graphical apps into that E terminal thing
I don't understand where you've gotten this idiotic idea that nobody advocated and which I have repeatedly stated that nobody advocated from. Constructed strawman, much?
> A terminal application that you run in an emulator, which is just some graphical application, cannot fundamentally be faster than just directly running graphical applications without that indirection, right? That would make no sense at all...
I've already explained how it is indeed far far more efficient and faster. If you think it doesn't make sense, that's because you don't understand. I'd suggest doing some reading. For example of my previous explanation.
> I played more with command.com than with the actual games installed, I suspect... My friends played NES, while I tried to hack custom program launchers as .bat files
Ooh I'm
so impressed! By that time, I was already editing command.com itself.
editing .bat files, huh? And then you thought windows 3 was good and never went back to a terminal.
So, another way to say it would be that you don't know how to use a modern unix terminal - which is what I mean when I say "terminal", because dos was always a toy OS.
> Even they made use of the 16 colors (or 8?!)
...and you don't even know what your DOS machine was capable of or what it could and couldn't do. This depended on a few factors, not least what type of graphics card (if any) you had and whether you were using a colour screen or an amber/green one.
> Sure, command.com was probably quicker than Windows File Manager, strictly speaking
So, in other words: text-based software is faster than graphical software.
> But all that happens so quickly nowadays, in terms of wall clock time, that I really doubt the practical relevance.
...because you've conditioned yourself not to notice the time you spend waiting around for your shit software to initialise.
> A "hello world" app in either Qt or GTK starts instantly on my machine. No waiting time that a human being could recognize. I press Enter, and it's there while I'm releasing the Enter key.
1. It absolutely does not start instantly. Go write a "hello world" in qt/gtk that exits instantly as soon as it's displayed its main window. Then time how long it takes. It's going to be >0. Or, in other words, "not instant"
2. This is a false and contrived example - a "hello world" program is intentionally extremely minimal and explicitly does not involve initialising a complex interface - it's literally a single control - how many "hello world" programs do you use on a daily basis for productivity? Please link me to a "hello world" program that can preview video for me, and that starts up instantly.