> Why should graphical applications be fundamentally worse (e.g. in terms of keyboard support) than terminal applications when terminal emulators are a graphical application?
> 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.
> 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
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?
> 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.
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.
> 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).
> Yes, that's one of the things that I feel so spooky with that approach.
> It cannot work...
> Maybe for a handful of persons that constantly search for jpeg/png/mpeg files, in bulk mode, and need quick previews.
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.
Yes. But how often do I spontaneously need previews of something? And how often is it then enough to get what this EFL lib can give me? In terms of format support, and in terms of functionality (e.g. can it show me the TOC of some pdf and allows me to navigate to some chapter?). Well, there seem to be some use cases... Obviously... I still cannot imagine how they look like, though.
> Well then either dolphin is by some miracle orders of magnitude faster than any file browser I have ever seen [...] Or [...] Or [...]
Maybe a combination of all of them... :) I don't know. The performance was always good enough to be much faster than I am.
My point was also: Before we now start to shoehorn graphical functionality into terminals, which we then only can use in graphical environments anyways, shouldn't we better just improve the graphical apps? 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).
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. It's not bash, which completely freezes then, e.g. when the network drive has a slow day, and I blatantly pressed Tab. Same for most of the other things you wrote. Win 98 did it as well (not the mimetype-detection, though). Even that was okay for most practical purposes. But look what machines we had back then! I've just navigated to /bin. At least around 3000 files. I would avoid having so many files in a single directory. For organizational purposes. Anyways. 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.
BTW: All the thumbnail stuff is done on demand, as soon as you scroll down.
And finally: You can just turn it off! ;)
Counting the files, and determining which application is associated with a file type, are quite cheap operations. That's nothing, even compared to the very bare directory enumeration, right?
> No, it will not do that when I press tab.
Yes, well, sure... But that's not because a terminal is the superior environment (how could it be if you just emulate it with the "bad" one). If all that 'modern' (win98) Dolphin magic is too slow, there are probably more lightweight alternatives that are still graphical. 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 anyways, instead of just getting the graphical apps right.
>> I really don't see why terminal applications should be fundamentally faster than graphical applications in that regard > ..........um, what?
Yeah, I'm assuming terminal applications that you run in your graphical terminal emulator. But that's obvious, right? If I would be wrong, then, of course, let's today start porting all our graphical apps into that E terminal thing. Maybe we then can get even faster by putting that again inside an E terminal. And again, and again...
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...
> Seems to me like maybe you've never used a terminal program?
I was a child when I got regular access to my first PC... It ran MS-DOS 5. 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. :-/ Even they made use of the 16 colors (or 8?!) you could have, though. ^^ No idea where I found out how to do that, a decade before my first internet connection... But at least as much I loved my first Windows 3.0 installation! Sure, command.com was probably quicker than Windows File Manager, strictly speaking. It was never so bad that I opened a terminal window for file management, though.
> GUIs and GUI toolkits, on the other hand, are huge complex libraries
Technically, I can just agree again. But all that happens so quickly nowadays, in terms of wall clock time, that I really doubt the practical relevance. 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.
> 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!).
We can definitely agree here!!! :)
> I don't know what else to say. Go talk to every single GUI application author ever, I guess?
Better than reinventing a whole new kind of terminal applications which aren't actual terminal applications, but only work in an environment emulated by the very thing they want to replace. The same morons will come and screw up with all kinds of things there again, once that'd get more momentum. But now, since they also have to maintain EFL plugins or other graphical-to-terminal translations for their apps and file formats, they will even screw up heavier.
>> If you know the file name starts with "cat_s", then you can also find it this way in Dolphin. > Sure. After you've waited almost an entire second, [...]
On an average day, I open a Dolphin window maybe once or twice... Often not even once (e.g. I just open my IDE and stay there, or the browser, or a game, you name it). You don't need a new one for every operation! I mean, if your workflow is seriously superior, then be happy that EFL and all that exists and supports all the file formats that you want to preview, and be happy that it provides all the features you need. I'm happy with you then. I have the feeling that it's a very special workflow for a very special task at best, though.
> 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?
If you want to understand it that way, that's fine... And you type "xdg-open" while I can just press Enter (or double-click ^^). Why should I constantly want previews of something, so often that I'd care about a second of waiting time once in preparation, so much that I should avoid Dolphin, which just gives me these previews without any user intervention needed, just because it take a second to start?! Couldn't you just leave it open then?! Yeah, you'll definitely have some reasons...
> I already specifically said that "We do also use our graphical environment".
Sure you do! I know! Terminology is one of them. That's exactly the point. For an actual (virtual)terminal, it would at least remotely make some sense to me. Because there it's not an option to just use a common X11/Wayland image viewer.
> Who said terminology is "trying to be a graphical app"?
No; it already is of course. It's trying to make terminal apps graphical, right? And all that technical complexity is just there because you don't have to move your eyes to another window (there are very basic image viewers without any features; I've no idea why they should be slower than the EFL previewers - and if you want a video thumbnail, just write an ffmpeg oneliner as an alias). Again, I'm happy for you that it's available, but I'd definitely dislike to see all that arriving in major desktop environments. And I'm still optimistic in that regard. If it does, at least there might be ways to integrate the Dolphin thumbnailers. :)
> I'm not sure why you insist on making this so complicated or acting like it's scary somehow.
In some way that's exactly what I'm wondering about when people have terminal-centric workflows in an environment that could actually just do graphics. In particular when they then start to patch graphics support inside their terminals.