> You're missing the point, which is that the EFL library just has media playback built into it - for a lot of different formats.
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?
At first, I don't expect anything from anybody; that's just way beyond my privileges, unfortunately... :D I can only comment things and add my 2 ct.
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.
the cost of launching a new process with a gui is not cheap. there's a lot of setup before you even get a window up ... when that process is already there (terminal) with all of that cost paid for it is actually provably cheaper in terms of cpu cycles, latency etc. to pop up an image/video in your terminal. and cheaper not by 1 or 2 ms... but by 100's ms or more. that new window is not cheap. you also have the visual disconnect - the window pops up somewhere else with your wm having no idea that that new window is related to the terminal you ran it from because there will be no transient_for hints set to say that. relying on process tree hunting to figure this out is a crapshoot at best and will probably give you more misses than hits. we can go down that rabbit hole if you want but trust me - it is measurably less overhead to pop it up in a terminal with a few dozen chars worth of escapes sent to the terminal to do it.
In terms of wall clock time, on my system, it costs nothing. I can start a "Hello World" application based on Qt or GTK, and the window is there while I'm still releasing the Enter key. Technically, sure, a lot of things happen... But it's not happening on a P-90 anymore... :) BTW: My machine wasn't particularly strong or expensive either, when I bought it 6 years ago. ;)
When I read (in your other reply) that you are trying "soften the boundaries between workflows and bring some features of of workflow into another", well, that probably sounds nice... I just get a headache tbh...
I'm sure it was fun and a big achievement to implement that. And there obviously is a fan-base for that. So where am I... :)
it is effectively a keyboard driven GUI. you potentially get the full power of the commandline to do your actions without giving up a graphical view of your system.
ttyphoon on the other hand is a terminal project that approaches this from the other side, getting even more graphics and structured data support into the terminal: https://github.com/lmorg/ttyphoon
both have a similar goal: get away from the old limitations that terminals have but keep the power they offer.
I actually do somewhat like the paradigm, from a user perspective. If done well, why not, could be cool... If done very well, it could be very very cool...
But please let's not invent these new kinds of applications based on terminal tech. I still don't see why one would go this pointless detour, instead of just start as a graphical application, tech-wise.
let's not invent these new kinds of applications based on terminal tech
i agree with that. the terminal with its escape sequences needs to go away, it is old and limited. however the commandline will not go away. nor should we give up text based applications. both are too powerful for that.
so what we want is a modernization of the commandline. this is happening with alternative shells, but also with ttyphoon and other projects. and efm brings the power of the commandline to the gui directly. i'd like to see more projects like that.
i see a large spectrum here. some projects try small incremental changes (sixels for example, a wierd concept, and i ask myself why, but ok). others try to bring more powerful datastructures to the commandline. good, because those are terminal independent. on the GUI side there have been various attempts to send objects between applications already for decades. none of them achieved broad acceptance. there is a lot of potential still. a GUI for data pipes for example would be nice. there is one for the terminal. tmux is a terminal manager, it is gaining GUI support. doesn't get rid of the terminal, but modernizes it. small incremental steps. 10 years ago i would not even have believed that alternative shells would gain acceptance. but they are. half a dozen projects that break bash compatibility and are gaining popularity.
Aah, I see. So then I guess that wasn't a demand that people who have their own perfectly functional terminals with graphics support that they've been using for years and are perfectly happy with patch graphics functionality into every other terminal in existence just in case you might happen to try to use a terminal program that requires graphics support. I guess I must have misunderstood. Silly me.
> can only comment things and add my 2 ct.
Perhaps it would be wise to do some basic reading and perhaps even testing to understand some of the basics about how the technology works before making comments about them. This is an excellent method to not come across as totally uninformed and ignorant.
> 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 rail
????
My terminal displays emojis just fine and they align just fine as far as I know. Have you considered trying software that isn't shit? Or filing a bug report containing more than zero detail on the issue?
> Or that conceptual discrepancy between the 16 colors support, where users can typically decide freely how exactly each color should look like
This is actually extremely straightforward if you spend 5 minutes understanding how it works, particularly with regards to backwards compatibility with terminals that don't support it. Which are few - it's incredibly well-supported in almost all terminals. I don't know what you're talking about...
> (or sth like that?!)
...and neither do you.
Damn, your nose is going to get right out of joint if you ever learn about RGB terminal colours. Shhh, nobody tell him!
> Everything is just a historically grown mess
Indeed! Finally something we agree on!
And people working to improve terminals with efforts like terminology and kitty are trying to do what they can to address some of these issues without breaking anything. Which is hard. It's really quite an admirable effort worthy of respect.
But first you'd need to understand what they're doing.
> there are probably a lot of further problems that I've never even heard about.
I have no doubt that there's lots that you haven't heard about
> 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
Ooh, appeal to authority. I'm so impressed.
Perhaps, as "a professional software developer", you should take the time to understand the tech that you're talking about. Doing so will help you form an informed opinion and will help you to avoid wasting everyone's time reading ignorant, uninformed, assumption-laden nonsense.
> And what the rationale behind is
Excellent! So go back and try actually reading my previous posts. That'll help a lot with this.
> And whether it actually makes sense, from an architecture perspective
Excellent! So go and read the docs and form an actual opinion that isn't "I don't like the sound of this herp derp". I'm sure once it's not immediately obvious that you have no clue what you're talking about and have spent zero seconds attempting to understand the architecture, people will be happy to discuss your pull requests making all the revolutionary improvements that I'm sure you'll make.
> And all the arguments that I've read here made no sense to me at all
Then maybe you should try actually reading them
> It feels more like a cult when I talk to terminal-centric users.
Aah! And the penny drops! You don't know how to use the terminal and don't understand its benefits. So of course you don't understand the arguments I've repeatedly outlined for why this functionality is desirable.
> As a Linux user since 20 years, my experience tells me that all these things always break something else
Ooh, appeal to authority #2. I'm so impressed! Meanwhile I've been using linux since last century.
Enlighten me, then, o great software developer and 20-year Linux user: What does the graphics support in terminology / kitty break?
Maybe you should spend 5 minutes understanding how it works before you go making assumptions.
> people who say that basic image viewers start too slow for them
You. Do. Not. Understand. My. Point. Because you don't understand how I operate. Because you don't know how to use a terminal.
> Either that's trivially fixable (and then we'd all be better off doing _that_ instead!),
Please explain, in excruciating detail, exactly how you plan to "trivially" prevent the need to load in the qt library to get VLC to start and show its qt interface. I look forward to reading your technical paper.
> or just an illusion/cult, or the EFL previews will not be faster
I already provided you with hard timing data demonstrating that previewing videos in terminology is more than 90% faster than the way you'd do it. If you have something other than completely uninformed assumptions based on nothing at all to back up your claim that previewing in terminology is not faster, please present your data here.
But as I've alluded to repeatedly and you've completely ignored, speed is actually not the primary issue. It's the context change. It's that "taking my hand off the keyboard" thing. Even more, it's the "staying in the same application" thing. And it's also more than all those factors. It's a similar phenomenon to how I can't really explain to you just exactly how pipes are amazing and one of the most incredibly powerful paradigms you could ever learn. I can't really explain it to you properly because IMO the only way that it will really click in your head is in the moment that you really actually understand pipes, and to do that you have to actually learn and work with pipes.
You're just fixated on the speed because you don't understand the cost of the context change because you don't understand how terminal people work, because you don't know how to use a terminal and think that switching contexts constantly and twiddling your thumbs while GUIs initialise is normal and fine. And that's fine, if you want to work like a windows user. You do you, and more power to you. Just stay the fuck away from making suggestions about how terminals should or shouldn't work.
> There is just no way they could be faster
I have already explained in excruciating detail some of the major reasons why they are. If you still don't understand, I'd suggest reading my previous responses where I explain that. Or, you know, doing some further reading to understand the technology you're talking about.
> A basic graphical image viewer would do the same thing, just without all these indirection, translation to escape sequences, interpreting them again
Maybe you should spend 5 minutes reading and understanding the technology you're commenting about, so that you don't make wildly incorrect assumptions, and don't come off as totally ignorant and uninformed.
Who translates what exactly into escape sequences that you think is more expensive than loading up the gtk/qt/wx widget libraries and instantiating a new window?
> Similar for the matters of proper keyboard support
Without some detail of what you're talking about this is just a non sequitur. Terminology works fine with my keyboard, as has...let me think... every terminal I've used in the last 30+ years.
Since we're doing non sequiturs, allow me to retort: Avatar 3 was shit.
> Every format that someone now wants to handle on terminal, needs to be supported by the EFL library?! Does it support LO spreadsheets? PDFs?
Why would you want to work with a spreadsheet in the terminal when there's a perfectly capable spreadsheet application right there?
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?
What?? so you open your preferred office tool. From terminology if you want to. I don't see why this is so difficult to understand? What about what I'm describing inhibits you from editing a spreadsheet in your spreadsheet editor?
> 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?
And all what? Raster already explained that it's like 3 lines of code.
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
OK so just to clarify: your complaint is that in order to be able to view a file of a particular format, EFL needs to be able to... parse that file format? ...Like every piece of PC software ever made?
> 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).
You don't know what you're talking about. It does indeed solve a problem. It could allow an entirely new class of incredibly rich hybrid terminal/gui applications, for one thing. And I've already given examples of it tangibly improving things. Just because you don't understand doesn't make it useless.
> 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! ;)
By your analogy, a GUI application is somehow better than a terminal one. Which it just isn't. You've got things backwards. A car that's stripped down to feel like a horse??? What the fuck are you on about?
> What context switch are you talking about
For the fifty-thousandth time: launching an entirely new application, waiting a geological age while it gets its shit together, switching to it, getting my bearings, and finally actually viewing the file.
> Why can't the same folks not improve keyboard support in e.g. VLC?
How would that relieve me of the need to start VLC in your suggested workflow?
> I would be surprised if VLC is worse in that regard than some terminal thingy
Who said anything about running a media player in a terminal?
(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
I wasn't able to easily determine the ram used by tycat, because it closes so fast. But given how complicated it isn't, I'd expect it to be measured in kilobytes. I can (and have) written a bash script which is a very close equivalent to tycat as part of my command not found handle. It's 1.3Kb.
> What's the difference?
Well, about 2858ms, give or take. Or if you prefer: about 95.2%. And about 100Mb of RAM, give or take. And a context switch. And me taking my hand off the keyboard.
> Yeah, make them universally work on any virtual terminals, and then it'd be at least an interesting discussion
Feel free to submit a PR to the makers of your preferred terminal. Or you could switch to a terminal that's less shit than the one you're using.
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"
When did anyone say you needed it or had to use it? I encouraged you to try it so that you might come off as less totally ignorant, but you're free to keep using your less-capable terminals and the worse software that works on them if you like. I don't actually care what you use.
> I really don't see at all why this is a good idea to spend any efforts for
No, you really don't.
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.
Your analogy is so hilariously flawed and backwards. It's very clear you don't understand. "disabling the engine"? Lol.
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!
If I'm being honest, the chance of me ever trying any kde trash again is about 0.1%. Which in its defense is about 50 times more likely than me trying gnome trash. I'm sure it's just as bloated as the other ten thousand bloated file managers.
"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
Your file manager can display emojis? Whoop-de-doo. Welcome to like, idk, 2010? Probably earlier tbh. Or are you bragging that your teminal emulator can display emojis? Like every terminal emulator I've seen for a very long time can, and like terminology could i don't even know how long ago because I've never seen it not do it.
> 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.
I'm just going to respond to this with something exactly as sensible and coherent. Here goes:
> Why would you want to work with a spreadsheet in the terminal when there's a perfectly capable spreadsheet application right there?
Well, if these quick previews are such a vital thing, it would be odd to just support a handful of formats. Any format should be supported, then. Furthermore, it shouldn't be just a static preview. I also want to navigate around there a bit then. And in my Blender model, I also want to play around with textures there. Hell, I basically want to just have Blender there. If it's inherently quicker, we should eventually do everything there. Quickly watching a video clip from some website. I don't want to unnecessarily waste ages for something that I can get quicker for free!
>> And all that [...]
> And all what? Raster already explained that it's like 3 lines of code.
We all know this is oversimplified in so many ways... ;)
This was just about adding the video support (which was already implemented and just needed to be called), not for the graphics support in general, right?
Also, the code isn't even my primary concern at all.
Some "improvements" would be just a single line of code, and you'd definitely hate them.
> 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.
Yeah, indeed, you did! But just the repetition doesn't make it sound more reasonable to me tbh. It's either a cult, or you do a kind of work there that I just cannot remotely imagine. Believe me, I also love when thing go quick. I get nuts when I feel blocked. Srsly. Everyone who know me will instantly confirm that. In emotional ways. I just cannot imagine any task where I could imagine to get a relevant speed-up by my terminal being able to render some jpeg/png/mpeg thumbnails. That might very much be my fault! Unfortunately, you didn't help me in that regard either so far. :-/ I still don't know for what kind of workload this might help.
> Did I say "editing the thing" or "working with the thing"?
Well, if you have a superior approach, which is quicker and more seamless, I'd definitely want us to see it using for everything! Mouse and keyboard is already there. It's probably just another three lines of code to make the mouse position available in pixel granularity. And then we can basically start porting everything into that new paradigm. Why should we then stick with the inferior one?
> It could allow an entirely new class of incredibly rich hybrid terminal/gui applications, for one thing. And I've already given examples of it tangibly improving things. Just because you don't understand doesn't make it useless.
That sounds indeed interesting, and it indeed resonates with me. But in my mental model, this is basically a gui application (again; as your terminal emulator also is), maybe even sth like a gui file manager (at least as entry point), but then i allows me to enter commands, and it would behave like a terminal: You ask it something via a command, and it gives you an answer. Basically like a terminal. Maybe with all kinds of additional features. And maybe it could actually integrate all kinds of applications eventually. Not just previews. Exactly as I described above in a slightly sarcastic way. Maybe I can actually open my Blender model in that "hybrid environment", and then I can either click around as today, or type some commands. And the same for all kinds of other applications.
I had hoped that, once someone starts to develop such a "new class of [...] applications", we could have a more modern foundation for it than ttys.
Anyways, as soon as I read about such a technology, and it does a little more than static previews of three or four file formats (or whatever EFL supports), I'd definitely give it a try!
> By your analogy, a GUI application is somehow better than a terminal one. Which it just isn't.
Technically, the application that runs your terminal _is_ a GUI application. I'm not aware of any terminal-based X11 emulators. That's just what I meant. Not more, not less.
> I just fired up VLC. It took about 3 seconds (that's 3000ms, but what's 600% between friends?)
> conversely:
> $ time tycat /path/to/some_video.mp4
> real 0m0.142s
> user 0m0.117s
> sys0m0.043s
Okay. Let's take these numbers. I definitely had machines where it took 3 seconds.
How many video previews (or if you want: any previews) have you looked at in this week so far? Doesn't need to be precise. After 600 ones, you saved half an hour, let's say. I'm not sure how long it would take for me to need 600 previews of something. A year? Five years? And all these must be separate occurrences. If I need thumbnails of a directory with 50 files, well, Dolphin (or hundreds of other apps) gives me all these thumbnails at a glance.
> Do you think I write software in the hope that you in particular will use it?
Ahh, you're also one of the authors of some parts of that software stack? Okay, then I understand your stance a bit more. Or are you refering to the hybrid project? Either way, no I don't expect anything, I just give my 2 ct; which is what comments are for, no?
Can I somehow find at least some early versions? I mean, I liked the idea behind at least.
> I wasn't able to easily determine the ram used by tycat
No worries, my machine has 32 GB RAM. Even with 8 GB, the difference between tycat (assuming it needs no memory at all) and VLC is then about 1% of the machine's capacity. I never need 100 video previews in parallel; that's for sure (and even then, it will not be another 100 MB per instance)!
> Just remember to go and set your terminal to not support colour - after all it's not supported by any of those amber-screens!
No worries here either. A useful baseline seems to be the actual Linux terminal. It can do 16 colors. Unfortunately, it doesn't even support emojis, though.
I ask myself since years: Does this terminal still switch to an actual text mode, or does the text get rendered in a framebuffer by the OS. Anyways... That's another topic... Maybe both variants exist...
> Your terminal emulator is a horse. A tired, old horse.
And even more so all the applications that I know that I could run inside it. Again, I'm always open for something exciting. :)
> If I'm being honest, the chance of me ever trying any kde trash again is about 0.1%. Which in its defense is about 50 times more likely than me trying gnome trash. I'm sure it's just as bloated as the other ten thousand bloated file managers.
Sure it's "bloated" by your criteria. You've already said what crazy things it does. And I'm absolutely fine waiting a second or two for startup, for all the comfort I get back, compared to mc, or even just plain bash (or whatever *sh).
But yeah, my basic point was not actually to evangelize for Dolphin or VLC or any particular app.
> "patched terminal font"?? What the fuck are you talking about?? It's almost like you don't understand what you're talking about.
Well, how do "the kids" get their Git icons etc? As far as I can remember, they call it "Nerd Fonts".
> [Emoji support] Like every terminal emulator I've seen for a very long time can
Yes yes, they somehow can... But all I've tried are buggy sometimes in what glyph widths they report. For some codepoints. mc even seems to apply some explicit tricks against it, when file names contain emojis, but it cannot perfectly hide the issue.
If terminology does better in that regard, good news! Nice!
As an application developer, I still cannot assume that my users all have terminology, so it's still no solution. :-/
> it would be odd to just support a handful of formats. Any format should be supported, then. Furthermore, it shouldn't be just a static preview. I also want to navigate around there a bit then. [...] Hell, I basically want to just have Blender there.
I'm sure the enlightenment folks will be happy to look at your patches for these features you want. I'm not sure how you plan to integrate blender, but you've been programming professionally since 20 years, so I'm sure you have a plan and understand in ways that I simply can't comprehend.
Raster already pointed out, and you ignored, that actually it does support pdfs, and libreoffice already. Seems it just never occurred to me to try them. So you actually won't need to patch that in at all!
> We all know this is oversimplified in so many ways... ;)
Do we? I don't. Maybe you can point me to the relevant lines of source code, where it's more than 3 lines. I'll look forward to seeing your link.
> This was just about adding the video support (which was already implemented and just needed to be called), not for the graphics support in general, right?
No, it does both graphics and video with the same 3 lines of code. As has already been explained and you ignored and/or failed to understand.
> Also, the code isn't even my primary concern at all. Some "improvements" would be just a single line of code, and you'd definitely hate them.
So, to summarise: you bring up an argument that it shouldn't be done due to code complexity, then when that is rebuked because the additional code complexity is very close to zero, just say "the code isn't even my primary concern at all", without elaborating any further to outline what your concern actually is. And to summarise the summary: you don't actually have any reasoning, you just don't like it because you don't like it.
> But just the repetition doesn't make it sound more reasonable to me tbh
Then why do you seem to think that saying "herp derp, I don't understand therefore it's a cult" over and over is going to sound more reasonable to me at some point?
> That might very much be my fault!
Yep
> Unfortunately, you didn't help me in that regard either so far.
Maybe it'd help if you pulled your head out of your ass and actually read what I wrote.
> Well, if you have a superior approach, which is quicker and more seamless, I'd definitely want us to see it using for everything!
We're talking about previewing. I have a superior approach for previewing. Which leads me to re-state my previous question: Did I say "editing the thing" or "working with the thing"?
> It's probably just another three lines of code to make the mouse position available in pixel granularity. And then we can basically start porting everything into that new paradigm. Why should we then stick with the inferior one?
I suspect it'll be much more complex than that, but you're a professional programmer since 20 years who has never looked at the code or even run the software, so you probably know better than I do.
I'm sure the e folks will be happy to look at the patches you provide for this functionality you want.
I suspect there might be a bit of discussion about things like "is this desirable" and "does this break compatibility with existing things" because this is a bizarro thing that you've invented out of nowhere based on nothing anybody said anywhere ever. But I'm sure they'll be happy to discuss it once you submit a patch.
> I had hoped that, once someone starts to develop such a "new class of [...] applications", we could have a more modern foundation for it than ttys.
I look forward to seeing your patch that does this without breaking compatibility with ~50 years of legacy software.
> three or four file formats (or whatever EFL supports)
Again, EFL supports a lot of formats. Including ones I didn't even know about, like the pdf and libreoffice docs you wanted. I guess you didn't bother reading that before.
> Technically, the application that runs your terminal _is_ a GUI application. I'm not aware of any terminal-based X11 emulators. That's just what I meant. Not more, not less.
So what's your point? How is it relevant that my terminal emulator runs on X? I'm not talking about the environment that runs my terminal, I'm talking about things that run in my terminal.
As for "terminal-based X11 emulators:, there's a fairly prominent one you might have heard of, it's called xorg. If you try to run 'startx' inside an X session you'll have problems.
> Ahh, you're also one of the authors of some parts of that software stack?
When did I say that?
> Either way, no I don't expect anything
You demanded that support for terminology's graphics sequences needed to be patched into every terminal emulator that exists in order for you to consider it valid for some reason.
By doing so, you're saying that people who write software that supports these graphical protocols (or maybe the authors of the terminals? It's unclear who you expected to do this for you) should jump through huge, unnecessary hoops just so that you can run their software (that you claim you don't want to run), rather than you..........simply running their software in the environment it requires.
> Even with 8 GB, the difference between tycat (assuming it needs no memory at all) and VLC is then about 1% of the machine's capacity.
Maybe you don't tend to use all your machine's resources, but the way I use my machine, it's constantly at near or over 100% capacity. I'm constantly fighting against swap, no matter how much ram I have. Right now my machine is using about 113% of available ram. I'll have to flush it out and clean it up soon to prevent too much swapping. I probably wouldn't want to start vlc right now without closing something else first - if I wanted to watch a video right now I'd use something more lightweight (or something I already have loaded, like my terminal). This is a normal state of affairs for me.
> A useful baseline seems to be the actual Linux terminal. It can do 16 colors. Unfortunately, it doesn't even support emojis, though.
In what way is this "a useful baseline"? Useful for what? Why is the extremely-well-supported 256 colour set or RGB not more useful? Who uses linux in text-only mode or with a display that can't do rgb in 2026 in any situation that isn't headless or exotic? Why can't they just run more complex stuff on the framebuffer with rgb colour if they want it? Why, given the above, is emoji support in text-only mode important? to whom? For what?
> I ask myself since years: Does this terminal still switch to an actual text mode, or does the text get rendered in a framebuffer by the OS.
Why would anybody who isn't working with extremely exotic legacy hardware care about this in 2026?
> And even more so all the applications that I know that I could run inside it.
Which ones don't run in terminology?
> Again, I'm always open for something exciting.
...as long as it's not the heresy of displaying graphics in a a teminal.
> for all the comfort I get back,
See this is the point right here. You consider it comfort. I consider it nuisance. So go use your GUI applications and enjoy them and let others enjoy their preference. Like I said a hundred thousand years ago.
> But yeah, my basic point was not actually to evangelize for Dolphin or VLC or any particular app.
No, it was to say - without having even bothered to try it yourself - that there's no use for a thing that I use all the time. And then in order to support your thesis you started evangelising the massive pile of software that you'd use to achieve what I can do better with one program that I always have running.
> Well, how do "the kids" get their Git icons etc? As far as I can remember, they call it "Nerd Fonts".
How are nerd fonts at all relevant to any part of the discussion?
Oh, I see: You said "[dolphin] even can render actual icons without a patched terminal font!"...
...you mean like terminology and other graphics-supporting terminals can? If they were using terminology or kitty, they wouldn't need to patch the nerd font icons into their terminal font - they could just display the icon they want.
So your point was to sarcastically suggest another actually-pretty-good use-case for the functionality you're arguing against. Got it.
> But all I've tried are buggy sometimes in what glyph widths they report
And what happened when you filed bug reports about this? Please link to them, I'll be interested to read your reports for more detail than none at all.
> If terminology does better in that regard, good news! Nice!
Well I don't know whether it does or not. Because you haven't bothered to actually describe the issue you claim exists in any detail. Or done anything more than make a vague and as-far-as-i-can-tell-incorrect assertion that terminals can't display emojis properly. As if that was somehow relevant to whether they should be able to display graphics or not.
> As an application developer, I still cannot assume that my users all have terminology, so it's still no solution
As an application developer, you have control over this thing called "system requirements" for your software. And you can do things like adding "requires terminology" or "feature X requires terminology" in there. Or you could put a note on the relevant issue in your issue tracker saying "you can work around this by using terminology, which doesn't have this issue". But of course we'd need to know whether that's true, first, and for that we'd need more than zero detail.
Or perhaps you should just make your application graphical, since you've said solves the problem you're having with emojis and repeatedly asserted that graphical software is inherently better.
Which of these is appropriate, i don't know, because you'd have to give more than zero detail for me to be able to tell.
Maybe when you're linking to more than zero detail you can also explain how it has anything to do with whether supporting graphics in terminals is a good idea.
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.