Live data from Hacker News

Fixing a 20-year-old bug in Enlightenment E16

iczelia.net

171–180 of 193 posts

Re: Fixing a 20-year-old bug in Enlightenment E16

#171
post #92

Earlier quoted context omitted.

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…

there are in fact ways of drawing raw bitmap data in terminals - look up sixel for starters... but that's not what this is about. the escapes to do images and video are very simple and very lean in terms of i/o from pty to terminal - unlike sixel. i added this because it's useful. to me. and apparently to quite a few other people. as i've explained. a quick tycat file.mp4 or typop file.jpg or tybg file.mpg etc. - or…

this softens the boundaries between workflows and brings some features of of workflow into another. it creates less of an abrupt "i have to switch" and more of a "i can just keep going for a while doing what i was doing".

some time last year i tried out that terminal plugin for the nautilus/nemo filemanagers, and it has changed how i work quite a lot. i always love doing things within a greater context. that's why i use tmux with a dozen sessions and half a dozen terminals in each. because instead of changing directories, each terminal is in a specific context and used for a specific purpose.

combining a graphical filemanager with a terminal likewise puts that terminal into a context.

unfortunately the integration is not great. the terminal keeps track of the directory if i use the filemanager to switch, but the filemanager does not track the directory of the terminal if i use the cd command to switch there.

i can select files in the filemanager and drag them into the terminal to use as arguments to a command. but i'd also like the opposite: type a wildcard in the terminal to select files in the filemanager. the filemanager has that as an independent feature, but that's not convenient. how about i run a command that lists some files, and then have those files shown in the graphical filemanager. these things could all be better integrated.

i have been looking for other filemanagers to offer terminal support, but i could only find dolphin, which unfortunately only shares one terminal between tabs. that doesn't work for me. i need a separate terminal per tab.

the efm feature is cool. i just tried it by running e in a nested X server (Xephyr). but it doesn't go far enough. i'd like that combined with a real terminal so i can do any commandline action with the selected files.

Re: Fixing a 20-year-old bug in Enlightenment E16

#172
post #142
post #18

Earlier quoted context omitted.

I remember fondly of a raster talk at FOSDEM about 20 years ago: playing videos inside a terminal. Amazing!

Wow, I think I remember that talk, too. And I remember thinking, "why would anyone want to run a video inside a terminal?!" I still don't want to do that, but it was cool that enabling that feature only required a few lines of code, since EFL(?) already supported it, was already linked in, and the code to start it was minimal.

i found this one from 2012:

https://video.fosdem.org/2012/maintracks/k.1.105/EFL.webm or https://youtu.be/HfcFbHQWqu8?list=PL31210579EDD785E7

in an interview from that time he says the previous time he was at fosdem was 10 or 11 years earlier. there seem to be no recordings from that time.

Re: Fixing a 20-year-old bug in Enlightenment E16

#173
post #158

Earlier quoted context omitted.

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…

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…

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

Re: Fixing a 20-year-old bug in Enlightenment E16

#174

Earlier quoted context omitted.

practically everything in GTK 4. It removed menu bars ffs

As far as I can tell, every major version of GTK should be thought of as an entirely separate project, and nothing in GTK 4 made GTK 3 or GTK 2 harder to use.

what does make GTK2 harder to use is that it is not supported anymore. you can't build or run GKT2 based apps on new systems without building the GTK2 libraries yourself.

Re: Fixing a 20-year-old bug in Enlightenment E16

#175
post #173

Earlier quoted context omitted.

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…

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 ar…

I just get a headache tbh

why?

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.

i wrote in my own comment that i want to go even further and integrate a full terminal: https://news.ycombinator.com/item?id=47801068

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.

Re: Fixing a 20-year-old bug in Enlightenment E16

#176
post #113

Earlier quoted context omitted.

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

> 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 projec…

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

Re: Fixing a 20-year-old bug in Enlightenment E16

#177

Earlier quoted context omitted.

(lol, split for length, 1/2) > But how often do I spontaneously need previews of something? I don't know. Or care. I use it a bunch. Maybe you're conditioned not to do that because every time you do it, it takes you 10+ seconds rather then 1. Who knows? Who cares? > can it show me the TOC of some pdf and allows me to navigate to some chapter? I've already responded to this spurious scenario. Go read my previous respo…

(2/2) > it's there while I'm releasing the Enter key 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. > 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, gn…

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

Re: Fixing a 20-year-old bug in Enlightenment E16

#178
post #175
post #173

Earlier quoted context omitted.

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 ar…

I just get a headache tbh why? 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. i wrote in my own comment that i want to go even further and integrate a full terminal: https://news.ycombinator.com/item?id=47801068 ttyphoon on the other hand is a terminal project that approaches this from the other side,…

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.

Re: Fixing a 20-year-old bug in Enlightenment E16

#179
post #171

Earlier quoted context omitted.

there are in fact ways of drawing raw bitmap data in terminals - look up sixel for starters... but that's not what this is about. the escapes to do images and video are very simple and very lean in terms of i/o from pty to terminal - unlike sixel. i added this because it's useful. to me. and apparently to quite a few other people. as i've explained. a quick tycat file.mp4 or typop file.jpg or tybg file.mpg etc. - or…

this softens the boundaries between workflows and brings some features of of workflow into another. it creates less of an abrupt "i have to switch" and more of a "i can just keep going for a while doing what i was doing". some time last year i tried out that terminal plugin for the nautilus/nemo filemanagers, and it has changed how i work quite a lot. i always love doing things within a greater context. that's why i…

This is just a demo right now - buttons surrounding the file view are for testing:

http://www.rasterman.com/files/efm-typebuf-ex.webm

Re: Fixing a 20-year-old bug in Enlightenment E16

#180

Earlier quoted context omitted.

there are in fact ways of drawing raw bitmap data in terminals - look up sixel for starters... but that's not what this is about. the escapes to do images and video are very simple and very lean in terms of i/o from pty to terminal - unlike sixel. i added this because it's useful. to me. and apparently to quite a few other people. as i've explained. a quick tycat file.mp4 or typop file.jpg or tybg file.mpg etc. - or…

> my new rewrite of efm (e's built-in filemanagger) also has a terminal-like worklflow. i can literally in the efm window type "ls ./dir" and it will liteally change to that dir and list/show it. same with "cd .." or "rm a.jpg b.txt *.png" and it will delete those files. you can even just run apps like "gimp file.png" .... and it knows gimp is a command and there is a desktop file for it and will let you know by putt…

This is just a demo right now - buttons surrounding the file view are for testing:

http://www.rasterman.com/files/efm-typebuf-ex.webm

Post reply on HN