[antisol]

(1/2)

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

[antisol]

(2/2)

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