pino83

Oh, yeah, these discussions as well... Precisely.

Good that some people are able to translate my thoughts into actual English... :D

Reminds me of Facebook engagement bait

If you say so. I don't know. I was never an active part of that big problem (so btw I also had nothing to "solve"). You were?

One unfortunate aspect of the entire problem: Go back, let's say 10, 15 or 20 years, when forces were a bit more balanced than today. When all these issues were already quite obvious, but probably somewhat easier to solve. The same people that cry loudly today were completely ignoring all these issues. Actively. And when someone came up with them, that guy was just an idi*t, disturbing the good mood. Right? I can still remember all the conversations that I had, or that I read. Today, they'll deny that and still call me an idiot. Anyways...

PS: Sure, there always were a handful of exceptions. If you are one of them, you know what I'm talking about. I don't refer to you. But to the other 99.x%.

Either it was there since day 1, together with Facebook and some others, or your blacklist is a pointless show.

What nobody started discussing so far: Every user actively pushed these shady sites. They are/were all active parts of the problem. And usually they somehow knew it. They'll come with lame excuses, as if the issue ever was a technical one, and too difficult to get, but in fact, no, things cannot be more obvious. To everyone who ever got in touch with other human beings. It never was a tech problem.

I'm excited when this discussion will start. But we are far away from it yet.

You see here how smart they are. And here you definitely read from the smarter one, compared to some average John Doe.

So, no, there is no chance. Whenever you think "this might now finally help to make enough people understand", they'll quickly prove the opposite.

On the one hand, this really sounds frustrated, and I know why you are (bcs we both know that I'm right).

But beyond that unhappy story, your comment actually made me smile. Linguistically, let's say. And there is no sarcasm at all. It was funny to read!!

Just quickly, because I have to leave:

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.

Oooof... Okay, but quicker, bcs I need to leave at some point in time. I'll skip most of the parts where we are in a loop anyways.

Could that be because you haven't tried it and don't understand what you're talking about?

Admittedly, yes, I'm still trying to understand that.

So your suggestion is to add a terminal to every gui program in existence?

Interesting idea in some way, no? Not each one individually, please. That would be equally bonkers. But in the end, looking at the final result, that sounds a bit like how I'd interpret your hybrid approach.

> About your list what Dolphin needs to do but terminal apps don't: Yes, sure. A lot is going on. In the background. I don't have to wait for it to generate thumbnails. You do if you want to see them

Sure, but then you are comparing apples and oranges. You compared it to pressing Tab.

> I would avoid having so many files in a single directory. For organizational purposes. So in other words, dolphin, [...] fuck [...] My music directory [...]

You are doing everything in that very quick way, right? "For organizational purposes."

I just gave it a try; Dolphin has no trouble at all with 100000 files in a directory. Yes, it took a second longer. Whatever you'd do with these files will be by a few magnitudes slower.

But just as an experiment, why don't you "instantly" select the file named zcat.

Yes, did so. And now?

Someone has never looked at a directory with subdirectories containing 100K files or more in a graphical file manager.

It only does that (with subdirectories) if you explicitly ask it to do so, by opening some Properties dialog. You are here definitely starting to make things up.

Such as?

Nono, I'm fine with Dolphin. :-P

...Is your complaint here that you can't run these graphical terminal programs without having some sort of graphical environment running?

Why else should sane developers start to spend any serious efforts into applications based on this ancient tech stack? They would (obviously) of course just make a graphical application if it's graphical.

When was the last time you used a terminal in an environment where you didn't have hardware for graphics support?

Welllll, not sooo often, fortunately. Virtually never, and when I do, I definitely don't need previews of cat pictures. Most of the times I just use graphical applications. Even some Java based ones! Boy, you wouldn't guess what they all do while loading, and how long that takes. It's actually wild. But I'm not using my PC for starting applications, right. I do that once. And then they run. ;)

By the way, a bunch of actual "text-only" dumb terminals have had graphics support since the 1980s [1], and konsole has supported graphics for at least 5 years [2], and since 2022 it has supported the kitty graphics protocol [3]. Of course I'm sure you knew none of this

No. I'm sure it can do another 100 things that I'll never use. If you're in such a hurry all the time, you'll understand that I don't spend a lot of time in these things.

[...] the graphics support that's been there without your knowledge for half a decade has probably caused a bunch of bugs that you've been having trouble with [...]

Read again what I wrote (hint: it was not equal to "sixel support will definitely break a terminal")! But, yeah, we'll never know. To what should we compare it with? The good news here for me is: The danger is already mostly over then, and if there were issues, at least big ones, they're then already sorted...

Also, as you can maybe already infer from our conversation so far: I don't use Konsole that often. Slightly more often I use the terminal integrated in Jetbrains IDE. That is even worse, unfortunately. Although without Sixel support. ^^

Ooh I'm so impressed!

That's nice to hear. I just tried to answer your question, though.

And then you thought windows 3 was good and never went back to a terminal.

No no, that narration would skip quite some decades and would make me sound smarter than I actually am. Sure, in the first Linux years, you are definitely vulnerable to the terminal cult, and you assume that you talk to very very smart persons instead of just priests, and you believe them a lot, before you understand that a lot of it is just an odd cult. And in a lot of cases (even today) you just sometimes have to use a terminal; particularly on Linux.

But really not for image thumbnails, and neither for management of my music collection. That actually never happened.

> Even they made use of the 16 colors (or 8?!) ...and you don't even know what your DOS machine was capable of or what it could and couldn't do.

No. That was when I was in elementary school. Just barely. I was happy when I was able to collect these things in other .bat files and were clever enough to combine these findings to something that somehow worked.

This depended on a few factors, not least what type of graphics card (if any) you had and whether you were using a colour screen or an amber/green one.

Without colour screen/card, there would be no question whether it was 8 or 16 colors, right? It would then be 2.

[...] 2. This is a false and contrived example - a "hello world" program is intentionally extremely minimal [...]

If you need more complexity (e.g. for layout of more complex content), your terminal app also has to deal with that in some way.

This is empirically, demonstrably untrue, because the "launch application" action does not begin until the "key release" event has fired. Which is something you'd know if you understood how your interface works.

No, not at all. What are you "demonstrating" here. I've never seen the behavior you describe on ANY platform tbh. Also not in any terminal.

> there are very basic image viewers without any features ...No features at all, huh? Please provide examples.

I'll not do your web search for you. For some reason, I've imagemagick installed here, which seems to ship a very basic image viewer. It starts (at least for the image I've tried with) as instantly as the hello world apps.

And just for the case you still don't understand: I mean "instantly" in a practical meaning. You don't have to explain me once more that it can't be exactly 0 sec in a scientific meaning. ;)

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. :-/

Argle bargle snerf blu carn delg bling blong blu barg sneh bork mert.

I wish you a nice weekend too!

Two times some guys at Mastodon tried to convince me to try Bluesky.

I explicitly told them that I want something distributed and that's a high priority, not a nice-to-have.

Yesss, there's definitely some very cheeky marketing going on.

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... :)

My simplified model always was: If you give it to Google (or MS, Amazon, Meta, ...) you basically already gave it to all these agencies.

Was that ever wrong?

Oh, thanks for the hint! Last time this happened to me was with one of the Gnome or GTK guys. And it felt a little bit less bad, because I really hated their decisions. Here, I feel now a bit bad because my wording was very direct. Let's say: Implementing all that was probably quite an achievement, even if I didn't like all the visual decisions. ;)

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.

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".

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.

Ohh, I've never seen that wallpaper before... Looks so year 2000-ish... :)

And then you start some actual (non-E) applications...

Which look completely different (i.e. not like something that MS Frontpage has desperately assembled out of Java Applets and weird color choices)...

And then, even if you liked the original look, you'll not be satisfied at all anymore, will you?

Yeah, okay, on the other hand, you could probably find Qt and GTK themes that somehow looked similar enough...

No no, it always tried to do something, with a lot of self-confidence, but then constantly failed.

I can spontaneously remember k3b (CD burning tool) constantly failing because the CLI tools behind it (cdrecord, mkisofs, ...) replied in some way that k3b hasn't expected (e.g. because the locale was non-english, or the CLI tool devs changed the strings slightly, or there was a pointless warning text that k3b did not expect, ..., ...).

Admittedly, k3b was later... KDE3 era? But this is exactly how KDE1 felt... And in very bad days it still does today... You click on something, the developers assumed that the file manager can deal with it, but instead you just see the file manager saying "Unknown protocol" or similar. All the problems that arise when your system is very modular, but every module is a separate hobby project with no coordination.

I definitely loved KDE3 and was sooo excited about KDE4. And it was a pretty terrible disappointment. Nowadays I'm again fine with Plasma. Since mid KDE5 days.

for some reason Wayland sessions crash

That's definitely a mess, too. I'm not fundamentally against Wayland. I'm using it right now. Even if it is still slightly broken today (yes, Wayland is a protocol; here I mean: the biggest implementations). But the entire Wayland story is very very sad. It took ages before it was at least usable for five minutes. And then everywhere the X11 support already gets disabled, while Wayland is still in a somewhat immature state. Sure, I somewhat understand what the devs say, and I can't force them anyways. But it's really not a success story for the Linux desktop.

Then it's not "exactly like" what I would do at all - you'd take your hand off your keyboard and switch to your mouse to use a graphical file manager tool.

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...

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.

KDE 4 was indeed a huge mess... All 4.x version. Even if every changelog had the sound of "Now the glitches are fixed; you can now start using it". It never was...

KDE 1?

Yeah, compared to Win 95 at least, it looked interesting in a positive way...

Problem was: Whenever you clicked on something, some message box appeared, with some one-line error message that contained the word "unknown" or "unexpected"... :)

I know that people never want to hear such remarks... At least I never want... But I risk being the idiot anyways: KDE/Plasma doesn't crash here so often. I've seen it actually happening in the last years. Unfortunately!!!! Maybe two or three times... And then, it just restarted in a matter of a second. It did not affect anything. No running apps crashed. Just the task bar and the desktop went away for a second.

How long have you tried, and how long are you now trying Gnome?

This is maybe because it's quite hard to find some?! ^^

Well, I explicitly said that I dislike Gnome for that. Sure, there are switches that are fine for actual customization, in order to actually adapt to personal preferences instead of work around technical weaknesses. I love how configurable Plasma is.

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... ^^

I have absolutely no doubt that this is possible to do, particularly if you assume that you already have all kinds of libraries available, and if you don't care at all about the terminal ecosystem in general.

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...

PS: When can terminal apps get mouse coordinates in pixel granularity?

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

In a lot of cases, configurability is just a workaround for the issue that devs were unable to implement sth that just works 'fine'. So you could turn it on and live with its defects, or you turned it off and live without the feature. Linux Desktop was always full of that.

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?

In my personal experience - as far as I can remember - it always stopped to be good looking when it wasn't a screenshot anymore but a running process on my machine. In motion, all the eye-candy became ugly and foolish and visibly hobbyist, and as soon as I began using some applications outside of the E-ecosystem, the last sparks of fanciness went away anyways.

But that was... idk... E16 or so?! I really cannot remember. Maybe it had better times earlier, or maybe (surely) people are different and have different criteria for choosing such things.

Was E13 before they started trying to be a klingon starship UI?

Wasn't Enlightenment something that just looked good in screenshots (compared to Win XP or even earlier ones)? I love desktop environments that look nice, I love effects and animations, if done well, and I love to be able to customize things (KDE/Plasma is doing a really good job in that regard imho). But Enlighenment? Whenever some screenshots excited me, I gave it another try for some hours, and then went back to KDE or Gnome.

It's what you call "ricing" today? You need it for some nice screenshots (or screencasts nowadays), you post them, and then you log off and use something else (i.e. the smartphone, the gaming console, Windows, KDE/Gnome, ...) because that just actually works.

Well, what's the sarcasm?

If someone already has MS Teams installed, and their Authenticator App, there is no compelling reason to not install Copilot. Unless the system permissions they ask differ substantially, let's say.

Either you trust MS or you better have nothing installed from them on your (personal) devices at all. No?