But yeah, I also do not like Gnome, because they more and more just removed the switches, but without spending effort to make things fine for everyone.
Plasma is so configurable, I've never seen anything more configurable. On any OS that I've seen.
My personal experience: Yes, you can also build your own environment out of blocks. And then you configure a lot. But not in order to customize it better, but in order to somehow glue these components together in a way that somehow remotely makes sense. :-/
And what's the point of video clips in the terminal? What weakness are you trying to workaround with that? E is a graphical desktop, no? Based on X11 or Wayland. There are actual media players!! A lot. Not a single one is really great, but most will be better than the terminal, I guess. VLC is that bad?
His last comment before today was in 2016. And he came on today just to comment.
Thanks for making Enlightenment! I really enjoyed it for the brief time I used it!
And then you only need access to the mouse position in pixel granularity, and you basically have the foundation for a graphical environment. We can implement Qt and GTK for that new thingy. So there is finally a usable text editor available in a Unix terminal! Email clients that don't make you sad! You can finally navigate your files in a less lousy way!
And, of course, we can then also port these E libraries, so we can start their terminal app inside their terminal app inside their terminal app!
But: What is it for? Why not use your graphical environment in a direct way? The existence of terminal emulators is the proof for it being at least as strong (or stronger) as your terminal can ever get. Right? So what's the point of this indirection? I just don't get it...
Yes... Let's imagine I regularly look through my files. And these files aren't plain text (otherwise it would just be cat or mcedit) and aren't ODT files, kdenlive projects, Gimp files, ..., ..., but they are particularly png or jpeg or mpeg (or whatever the tycat thingy understands). And I want to do that via ssh. And I always have this E terminal in range. Then this is one valid option to do so imho. Still a very weird, freaky, odd one. But it would somehow make some sense to me...
> or whatever the tycat thingy understands
> And then you only need access to the mouse position in pixel granularity, and you basically have the foundation for a graphical environment. We can implement Qt and GTK for that new thingy.
> But: What is it for? Why not use your graphical environment in a direct way?
> What is it for? Why not use your graphical environment in a direct way? The existence of terminal emulators is the proof for it being at least as strong (or stronger) as your terminal can ever get. Right?
We do also use our graphical environment. It's just that our terminal also happens to not be stuck in the 1970s and pretending it's running on a teletype. Decades ago someone could have made a very similar argument to the one you're making that we shouldn't have added colours to terminals because real dumb terminals are all green or amber screen.
It's at least partially about pushing the envelope, not accepting the status quo, and trying to improve things. Terminal emulators tend to have a fixed feature set and there's a bunch of things they can't do that would be nice to have.
I mentioned the kitty terminal emulator before. It's doing similar things. And it's quite popular with the kids. These enhancements to terminals are a good thing! I'm glad these people are experimenting with things even if they turn out to not be very useful (and many terminology improvements are great!)
Another great example of this type of thing is the tysend command, which lets you download files without starting a new ssh session: you're ssh'd into some remote machine and you want a file. You can switch to another terminal and scp, or (as long as the host you're logged into has tysend), you can just do 'tysend /path/to/file'. Terminology pops up a (very pretty) save dialog asking where you want to save the file, and then displays a (very pretty) progress bar while the transfer happens.
I think maybe you need to try terminology to understand the many, many ways it's superior to a more conventional terminal emulator. For me, terminology is definitely enlightenment's "killer app". You can try it just by installing it, btw - you don't need to be running enlightenment :)
As far as I understand, you're missing the point. Every format that someone now wants to handle on terminal, needs to be supported by the EFL library?! Does it support LO spreadsheets? PDFs? Audacity projects? Raw camera images? HTML? Yes? And now I want to switch away from LO to some very new office tools, and I cannot, because EFL doesn't support it yet?
And all that just in order to show some previews in a terminal emulator instead of the graphical environment around it that is perfectly capable to do so since half a century? Where all the applications already exist?
> tycat doesn't need to know or care about file formats, nor does terminology
Fine. Just replace tycat with EFL in what I wrote before.
> I was playing around a while back with embedding GUI elements like buttons inside terminology. [...] Limited real-world practical value, perhaps, but interesting IMO.
Yes, it sounds like an interesting puzzle. But it's artificial. It solves a problem that just doesn't exist at all, and it doesn't actually improve anything, as long as it's not universally supported (at least in an actual Linux virtual terminal outside of X11/Wayland).
> Rasterman and I have both given examples of how this improves the terminal experience.
But why are you trying to improve the horse riding experience, if you actually have a car that is just artificially stripped down to feel like a horse? Just use the car as a car instead! ;)
What context switch are you talking about? Your eyes moving to where the new window opened? srsly?
Why can't the same folks not improve keyboard support in e.g. VLC? If it's actually so bad... Is it? I rarely feel the desire to keyboard control a media player, admittedly... But I would be surprised if VLC is worse in that regard than some terminal thingy that is a niche inside a niche inside a niche... A terminal media player needs the same explicit development work to get it right. It's not magically keyboard-friendly just because it involves antiquated technology for displaying.
> and time of having to fire up a media player to preview a file
You fire up a new tycat instance instead. What's the difference? Here VLC takes, idk, 500ms?! Half of it is the window animation that I could turn off, if I would dislike it (I don't).
> I mentioned the kitty terminal emulator before. It's doing similar things. And it's quite popular with the kids. These enhancements to terminals are a good thing!
Yeah, make them universally work on any virtual terminals, and then it'd be at least an interesting discussion whether this was an actual improvement or not. As long as I need some E terminal, or a particular terminal that is "popular with the kids", I really don't see at all why this is a good idea to spend any efforts for. Just use the car as a car, instead of disabling the engine, pretending it to be a horse, and then find clever ways to make it feel more like a car again. It already _is_ a car. Don't make up artificial restrictions that do not exist, just in order to find mediocre ways to somehow patch parts of them away a bit.
Give Dolphin a chance! It's like the kids' vi setup, just with slightly different shortcuts, and without all the weaknesses. It even can render actual icons without a patched terminal font! And if keyboard support is weak, then this is not because it's not a terminal application. Make them a bug report. Or, if appropriately skilled, send them a patch! Then we all profit from it.
Bonus: It can display emojis, without breaking alignment in half of the terminal emulators, because the actual glyph width differs from what the "API" (i.e. dancing some escape sequences and somehow intercept the answers from somewhere) tells you.
Whatever desktop environment you're referring to probably uses some of the same underlying third-party libraries for file format support as EFL, so what's the difference?
Why would being able to display graphical elements in my terminal program only be useful if it were supported on the Linux virtual console or some other terminal program I don't use?
Why would you expect "the same folks" to stop working on projects they find interesting or useful in favor of fixing your problems with entirely different applications?
All the terminal tech ecosystem is already somewhat beyond it's actual capabilities. You see that when you e.g. use tmux or screen. Or when you just have some emojis which are actually wider than the API tells you and your alignment goes off the rails. Or that conceptual discrepancy between the 16 colors support, where users can typically decide freely how exactly each color should look like (up to the point of having the background in white instead of black), and then the additional 256-color support, which adds 240 more colors (or sth like that?!), but with really fixed color values...
Everything is just a historically grown mess. And I've just mentioned a few points that came to my mind spontaneously, and there are probably a lot of further problems that I've never even heard about.
With that in mind, when I hear about the idea of hacking full graphics support into that, as a professional software developer my first instinct is to understand whether that's really worth the trouble. And what the rationale behind is. And whether it actually makes sense, from an architecture perspective if you want to call it this way. And all the arguments that I've read here made no sense to me at all. It feels more like a cult when I talk to terminal-centric users.
I don't have any privileges to decide for any involved project, though. If e.g. Konsole starts supporting that tomorrow, well, I'd doubt this was a useful thing, but then that's what it is. I could then only hope that they didn't break other things.
As a Linux user since 20 years, my experience tells me that all these things always break something else.
And then it's basically for people who say that basic image viewers start too slow for them. Either that's trivially fixable (and then we'd all be better off doing _that_ instead!), or just an illusion/cult, or the EFL previews will not be faster. There is just no way they could be faster. A basic graphical image viewer would do the same thing, just without all these indirection, translation to escape sequences, interpreting them again, etc.
Similar for the matters of proper keyboard support.
> Every format that someone now wants to handle on terminal, needs to be supported by the EFL library?! Does it support LO spreadsheets? PDFs?
But if you want to be able to preview libreoffice spreadsheets or PDFs in terminology - and also incidentally and for free every other EFL project which uses that control - I'm sure they'd be happy to look at your pull request.
> And now I want to switch away from LO to some very new office tools, and I cannot, because EFL doesn't support it yet?
> And all that just in order to show some previews in a terminal emulator instead of the graphical environment around it that is perfectly capable to do so since half a century? Where all the applications already exist?
The graphical environment might be able to do the same job, but as I've pointed out time and time again, it can't do it nearly as quickly or as fluidly when I'm already working in a terminal. We've been over this ad nauseum, but I'll just point out for the 30,000th time that all the ways you talk about involve opening up some other, slower program and switching away from the teminal. Which is a less seamless experience than just viewing the thing right there in the terminal. I don't know how I can state it any more clearly.
Did I say "editing the thing" or "working with the thing"? No, no I didn't say that. Because I didn't mean "Editing" or "working with".
> Fine. Just replace tycat with EFL in what I wrote before
> But it's artificial. It solves a problem that just doesn't exist at all, and it doesn't actually improve anything, as long as it's not universally supported (at least in an actual Linux virtual terminal outside of X11/Wayland).
> But why are you trying to improve the horse riding experience, if you actually have a car that is just artificially stripped down to feel like a horse? Just use the car as a car instead! ;)
> What context switch are you talking about
> Why can't the same folks not improve keyboard support in e.g. VLC?
> I would be surprised if VLC is worse in that regard than some terminal thingy
(btw, off-subject, but there are a couple of really great terminal-based media players. And I can pretty much guarantee their keyboard controls are superior to vlc. But I'm not sure because I don't really try to keyboard control VLC. Because I don't have to. Because I don't have to launch it to preview a media file)
> You fire up a new tycat instance instead. Here VLC takes, idk, 500ms?!
I just fired up VLC. It took about 3 seconds (that's 3000ms, but what's 600% between friends?) from launch to a window being visible. According to htop, that empty VLC window with no file opened used up about 100Mb of my memory.
conversely:
$ time tycat /path/to/some_video.mp4
real 0m0.142s
user 0m0.117s
sys0m0.043s
> What's the difference?
> Yeah, make them universally work on any virtual terminals, and then it'd be at least an interesting discussion
Why do you expect me to care what terminal you're using? Do you think I write software in the hope that you in particular will use it? If you want to use worse software and not be supported by my terminology-specific stuff, be my guest.
> As long as I need some E terminal, or a particular terminal that is "popular with the kids"
> I really don't see at all why this is a good idea to spend any efforts for
Just remember to go and set your terminal to not support colour - after all it's not supported by any of those amber-screens! And while you're at it you better disable those extended unicode characters and switch back to baudot code. You can probably find a punchcard reader if you look around.
> Just use the car as a car, instead of disabling the engine, pretending it to be a horse, and then find clever ways to make it feel more like a car again. It already _is_ a car. Don't make up artificial restrictions that do not exist, just in order to find mediocre ways to somehow patch parts of them away a bit.
No.
Your terminal emulator is a horse. A tired, old horse. That's gray and boring and totally uninteresting. So uninteresting that you haven't even noticed it's got an infection in its foot.
Meanwhile, my terminal emulator is a horse with cybernetic legs and wings that allow it to break the sound barrier, and also fly. And if I keep messing around a bit I might be able to get it to do even more cool stuff. Who knows what exactly? Will all of it be groundbreaking and super useful immediately? Maybe not. But it'll be fun and interesting and it can already do shit you never even imagined was possible and can't even comprehend when I tell you about it, insisting on asking backwards questions like "well yeah but if it's flying then what happens with the horseshoes?"
Have fun with your old nag!
> Give Dolphin a chance!
"patched terminal font"?? What the fuck are you talking about?? It's almost like you don't understand what you're talking about.
> Bonus: It can display emojis
> because the actual glyph width differs from what the "API" (i.e. dancing some escape sequences and somehow intercept the answers from somewhere) tells you.
Argle bargle snerf blu carn delg bling blong blu barg sneh bork mert.
Haha, you beat me to it. Basically the same example.
Just like today. But we lost the option to make it work.
> In a lot of cases, configurability is just a workaround for the issue that devs were unable to implement sth that just works 'fine'.
For instance, there's a setting in enlightenment to allow you to choose how scrollbars work - you can:
a) Have sensible scrollbars like graphical applications have had for 40+ years, or
b) Have 'hover at the right to show the scrollbar and make it virtually impossible to select the last item in a list' behaviour, like the gtk-bros insist you want, or
c) Have no scrollbars at all if you prefer. Maybe you've got a touchscreen or a wheel mouse and a tiny screen, or whatever.
In e, this is just a setting where the user gets to choose what their computer does.
I know, it's a pretty revolutionary idea. So I'll just say it again: the user is the one who chooses what their computer does.
I haven't played with KDE seriously since the days of Corel Linux. I tried KDE4 back when it was a new thing, observed my desktop running at <1fps for the 10 minutes it took me to exit, and never tried it again. I've since heard good things about plasma. One day maybe I'll try it.
> And what's the point of video clips in the terminal? What weakness are you trying to workaround with that?
It's a fantastic way to preview videos. You type "ls", and it gives you a list of files. And you say to yourself "Huh, I don't remember what 'video_clip_1280p.mp4' is. So you right-click on the filename and choose 'preview', and the video pops up in your terminal window and starts playing. And once I know what the file is I press escape and I'm back to where I was. It's marvellous! The only way I could think of improving this would be if there was some way to do it without any mouse interaction... like for example by typing 'typop video_clip_1280p.mp4'.
I do watch my movies in either vlc or mpv, usually - nobody is actually sitting around watching movies in their terminal (I hope!). For that, you use a media player. But for quickly previewing videos / images / audio (yes, audio too!), it's :chef-kiss:
I also have a custom command_not_found_handle which displays a randomly-chosen animated gif from a list I've built up (things like picard facepalming and people shaking their heads), along with a nice ascii art message in the vein of "You suck!" when I type an invalid command [1]. The reason I have that is........................................because it's fun!
When I read further, about your scrollbar example, I wasn't sure if I would consider that a good example for your point or for my point... ^^ Anyways... Maybe it's a corner case. Fine. Not the worst one I've ever seen.
> I know, it's a pretty revolutionary idea. So I'll just say it again: the user is the one who chooses what their computer does.
That's obviously just the 2nd part of the story. At least so far. In some years, sure, every user (of FOSS software at least) can vibecode her own creepy set of features...
> It's a fantastic way to preview videos.
What you describe sounds exactly like what I would do, but I would start Dolphin instead. It's another shortcut for closing it. That's it. On the other hand: Here I can start arbitrary applications. For a LO-spreadsheet, LO would start! For a Blender model, Blender would start! VLC starts so quickly, and can read any remotely valid video file. I still don't really understand what I'm missing tbh...
> I also have a custom command_not_found_handle which displays a randomly-chosen animated gif from a list
Well, okay, that's far away from my taste how a system should behave... Maybe I'm just too old... ^^
> personal preferences instead of work around technical weaknesses
> What you describe sounds exactly like what I would do, but I would start Dolphin instead
> On the other hand: Here I can start arbitrary applications. For a LO-spreadsheet, LO would start! For a Blender model, Blender would start!
> VLC starts so quickly
> that's far away from my taste how a system should behave... Maybe I'm just too old
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...
> 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.
Then Qt and GTK can have backends for terminal( emulator)s and I can finally run a graphical terminal emulator inside a terminal emulator? tmux and screen will be dead!!! :D
And when do the terminal hacks for AR glasses start to appear? I still cannot walk through vimacs? Doing ":q!" with just some head gesture? Why not??
SCNR