7 ms·

well why video in a terminal? 1. it's "free" because the toolkit already offers video objects - feature is there... why not expose it. you just call 2 lines of

well why video in a terminal? 1. it's "free" because the toolkit already offers video objects - feature is there... why not expose it. you just call 2 lines of code or so and and tell it to play. it's similar amount of code for an image, so it's basically free really. why do still images and NOT video? why stop there when video is only a little more code. sure. if you want a movie as a background: probably a bad choice, but if it's one of those zen videos with just trees swaying in the breeze as a background or a mountain lake rippling in the wind with very little motion but enough to make it "come to life", why not? but ok - for real usability? example: you're browsing through your dirs. cd ~/xxx/yyy; ls; cd zz; ls ... oh there's cat-sunning.mp4 there... i have 87 videos of cats sunning themselves.. which was that? tycat cat-sunning.jpg -> boom. video appears in terminal - you cat'd it.. it plays (tycat is just a tiny cmdline tool that emits the right escapes to terminology. you could make it a shell alias or script too and not use tycat. escapes are documented in the readme. this works even in a dumb framebuffer without wayland or x display systems (because the toolkit handles auto-detecting its environment and if in just a tty/vt it'll fall back to fbcon or kms/drm and render there). so you get a mouse and a full-screen graphical terminal that can do splits/tiles/tabs and so on with no windowing system and you can happily still explore all your files there even if they are videos... you aren't forced to use the feature... but it's there if you need it or want it.

pino83 6mo ago
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...
- antisol 6mo ago
  > or whatever the tycat thingy understands You're missing the point, which is that the EFL library just has media playback built into it - for a lot of different formats. Like Carsten mentioned, tycat doesn't do anything special, it just emits the right escape sequences to tell the terminal "display file X". And then terminology just says "hey media library, give me a player for file X". tycat doesn't need to know or care about file formats, nor does terminology. > 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. You (rightly) say this sarcastically. But people have done things like this. I was playing around a while back with embedding GUI elements like buttons inside terminology. I've got a library (which I should finish) to display gorgeous GUI-style progressbars in terminology. This also works for things like buttons - it's possible to display an actual GUI button inside the terminal, and to have it emit events that you can respond to. Limited real-world practical value, perhaps, but interesting IMO. > But: What is it for? Why not use your graphical environment in a direct way? Rasterman and I have both given examples of how this improves the terminal experience. Being able to preview media files in your terminal is a direct, measurable enhancement to usability: it removes the context switch and time of having to fire up a media player to preview a file, and the need to move your hand from keyboard to mouse and back. > 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? I'm not sure what you mean by "at least as strong as your terminal can ever get"? We do also use our graphical environment. It's just that our terminal also happens to not be stuck in the 1970s and pretending it's running on a teletype. Decades ago someone could have made a very similar argument to the one you're making that we shouldn't have added colours to terminals because real dumb terminals are all green or amber screen. It's at least partially about pushing the envelope, not accepting the status quo, and trying to improve things. Terminal emulators tend to have a fixed feature set and there's a bunch of things they can't do that would be nice to have. 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! I'm glad these people are experimenting with things even if they turn out to not be very useful (and many terminology improvements are great!) Another great example of this type of thing is the tysend command, which lets you download files without starting a new ssh session: you're ssh'd into some remote machine and you want a file. You can switch to another terminal and scp, or (as long as the host you're logged into has tysend), you can just do 'tysend /path/to/file'. Terminology pops up a (very pretty) save dialog asking where you want to save the file, and then displays a (very pretty) progress bar while the transfer happens. I think maybe you need to try terminology to understand the many, many ways it's superior to a more conventional terminal emulator. For me, terminology is definitely enlightenment's "killer app". You can try it just by installing it, btw - you don't need to be running enlightenment :)
antisol 6mo ago
hey Carsten! o/ Haha, you beat me to it. Basically the same example.
- pino83 6mo ago
  This is maybe because it's quite hard to find some?! ^^
  - antisol 6mo ago
    more "just the best, first example that springs to mind" - Great minds something something.
BeetleB 6mo ago
For those who don't know, rasterman was the original creator of Enlightenment. His last comment before today was in 2016. And he came on today just to comment. Thanks for making Enlightenment! I really enjoyed it for the brief time I used it!
- pino83 6mo ago
  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. ;)
mech422 6mo ago
Hey! Thanks for E! It was my daily driver back in the day :-) Pretty cool to see it could run on cell phones as well! Thats some pretty tight code! :-D

pino83 6mo ago

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

antisol 6mo ago
> or whatever the tycat thingy understands You're missing the point, which is that the EFL library just has media playback built into it - for a lot of different formats. Like Carsten mentioned, tycat doesn't do anything special, it just emits the right escape sequences to tell the terminal "display file X". And then terminology just says "hey media library, give me a player for file X". tycat doesn't need to know or care about file formats, nor does terminology. > 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. You (rightly) say this sarcastically. But people have done things like this. I was playing around a while back with embedding GUI elements like buttons inside terminology. I've got a library (which I should finish) to display gorgeous GUI-style progressbars in terminology. This also works for things like buttons - it's possible to display an actual GUI button inside the terminal, and to have it emit events that you can respond to. Limited real-world practical value, perhaps, but interesting IMO. > But: What is it for? Why not use your graphical environment in a direct way? Rasterman and I have both given examples of how this improves the terminal experience. Being able to preview media files in your terminal is a direct, measurable enhancement to usability: it removes the context switch and time of having to fire up a media player to preview a file, and the need to move your hand from keyboard to mouse and back. > 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? I'm not sure what you mean by "at least as strong as your terminal can ever get"? We do also use our graphical environment. It's just that our terminal also happens to not be stuck in the 1970s and pretending it's running on a teletype. Decades ago someone could have made a very similar argument to the one you're making that we shouldn't have added colours to terminals because real dumb terminals are all green or amber screen. It's at least partially about pushing the envelope, not accepting the status quo, and trying to improve things. Terminal emulators tend to have a fixed feature set and there's a bunch of things they can't do that would be nice to have. 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! I'm glad these people are experimenting with things even if they turn out to not be very useful (and many terminology improvements are great!) Another great example of this type of thing is the tysend command, which lets you download files without starting a new ssh session: you're ssh'd into some remote machine and you want a file. You can switch to another terminal and scp, or (as long as the host you're logged into has tysend), you can just do 'tysend /path/to/file'. Terminology pops up a (very pretty) save dialog asking where you want to save the file, and then displays a (very pretty) progress bar while the transfer happens. I think maybe you need to try terminology to understand the many, many ways it's superior to a more conventional terminal emulator. For me, terminology is definitely enlightenment's "killer app". You can try it just by installing it, btw - you don't need to be running enlightenment :)

antisol 6mo ago

hey Carsten! o/ Haha, you beat me to it. Basically the same example.

pino83 6mo ago
This is maybe because it's quite hard to find some?! ^^
- antisol 6mo ago
  more "just the best, first example that springs to mind" - Great minds something something.

BeetleB 6mo ago

For those who don't know, rasterman was the original creator of Enlightenment. His last comment before today was in 2016. And he came on today just to comment. Thanks for making Enlightenment! I really enjoyed it for the brief time I used it!

pino83 6mo ago
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. ;)

mech422 6mo ago

Hey! Thanks for E! It was my daily driver back in the day :-) Pretty cool to see it could run on cell phones as well! Thats some pretty tight code! :-D