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.