8 ms·

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

by 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 :)
- pino83 6mo ago
  > 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.
rasterman 6mo ago
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 even roll these escapes with echo's into your shell rc files... like you might change prompt colors with escapes when you su/sudo as root or you ssh into another machine and change the terminal title to alert you - you can use images and video to do this too. you can just not use the feature. fine. up to you. why should your lack of desire for it mean no one else gets a useful feature for them? it was not like adding the support was drastically difficult and i had to write an entire video codec engine. i re-used existing support that already wrapped it up in a nice little bow (i also wrote most of that support code in efl btw so i know what it can do, what it does and how it does it). i can ALSO use my gui in the normal way. i wrote a video player too: rage. plays video (and music too - snarfs album art for music if you have none too). i wrote a file manager or 2 or 3... they show thumbnails of files... can even pop up a video and play it in a tooltip popup... same libraries behind terminology do all the hard work. i can choose whatever workflow works for me at the time. i'm not limited to one way only. 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". 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 putting an icon next to it.. and it'll just run the command with those arguments... this is the inverse of terminology - it's bringing some terminal workflow into a gui filemanager. it softens the boundaries. it allows you to use muscle memory you already have for more things. that's the point. terminology has other handy features that piggyback off the same extended escapes. tysend will do a zmodem-like transfer of a file via the terminal. and btw - the libraries that deal with images and video.. they can also load xls files... and pdf too - as images. it's how the filemangager can generate thumbnails for them... they can actually access arbitrary pages in a pdf - it's just a feature of the image loader. so a little wrapper and you can flip through rendered pages of a pdf... i just didn't do a "paged interface" in terminology like i did a video/audio one with play/pause etc. controls... i could pretty easily. :) easy enough to add though... but i'm busy with the filemanager work at the moment.

by pino83 6mo ago

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

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

rasterman 6mo ago

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 even roll these escapes with echo's into your shell rc files... like you might change prompt colors with escapes when you su/sudo as root or you ssh into another machine and change the terminal title to alert you - you can use images and video to do this too. you can just not use the feature. fine. up to you. why should your lack of desire for it mean no one else gets a useful feature for them? it was not like adding the support was drastically difficult and i had to write an entire video codec engine. i re-used existing support that already wrapped it up in a nice little bow (i also wrote most of that support code in efl btw so i know what it can do, what it does and how it does it). i can ALSO use my gui in the normal way. i wrote a video player too: rage. plays video (and music too - snarfs album art for music if you have none too). i wrote a file manager or 2 or 3... they show thumbnails of files... can even pop up a video and play it in a tooltip popup... same libraries behind terminology do all the hard work. i can choose whatever workflow works for me at the time. i'm not limited to one way only. 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". 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 putting an icon next to it.. and it'll just run the command with those arguments... this is the inverse of terminology - it's bringing some terminal workflow into a gui filemanager. it softens the boundaries. it allows you to use muscle memory you already have for more things. that's the point. terminology has other handy features that piggyback off the same extended escapes. tysend will do a zmodem-like transfer of a file via the terminal. and btw - the libraries that deal with images and video.. they can also load xls files... and pdf too - as images. it's how the filemangager can generate thumbnails for them... they can actually access arbitrary pages in a pdf - it's just a feature of the image loader. so a little wrapper and you can flip through rendered pages of a pdf... i just didn't do a "paged interface" in terminology like i did a video/audio one with play/pause etc. controls... i could pretty easily. :) easy enough to add though... but i'm busy with the filemanager work at the moment.