| > 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! |
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!
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. 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. 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. 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? Yep Maybe it'd help if you pulled your head out of your ass and actually read what I wrote. 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"? 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 look forward to seeing your patch that does this without breaking compatibility with ~50 years of legacy software. 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. 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.
When did I say that? 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.