No, no, you rejoice, a deterministic bug is the best sort of bug. because now you have a test case and a solid method to know when it is fixed. The sad bugs are the ones you can't find a test case for.
I also got a bittersweet chuckle out of how the author considers it a lightweight environment, I mean, they are not wrong, but think of how far we have fallen when e, the ultimate bling desktop environment is considered lightweight.
Back in the early 2000's, I used Enlightenment. I wouldn't have called it "lightweight", but it definitely was not heavy. It ran smoothly on my not-so-great-hardware. And definitely lighter than DEs like KDE/Gnome.
I stopped using it for other WMs. I remember how it was taking forever to release E17 and totally forgot about it. E16 was definitely awesome in those days.
> because now you have a test case and a solid method to know when it is fixed.
And where is fun in that? Where are now the nights in trying to reproduce it? Where are the doubts in the moments of rest "have i really fixed it, or is it still there"? Boring.
As someone who remembers E making the rounds among the BSD and Linux users in my college dorm when it first came out, there's no way he's only 21 if he was a baby in the late '90s.
"Hello! I’m Kamila Szewczyk (iczelia). I am 21 years old. I’m an expert programmer and aspiring mathematician, primarily interested in compiler construction, data compression, esoteric languages, statistics and numerical algorithms. ... Currently I am a full-time student based in Germany." [1]
And the start of the post:
"The editor in chief of this blog was born in 2004. She uses the 1997 window manager, Enlightenment E16, daily."
I guess they wanted to keep working on their slides (at least for the moment) and not be forced to go debugging. Sadly, the hang was deterministic, so they didn't have another option.
But it is light weight. Fabulously so. The "bling" just comes from the ability to write theme files to customize the appearance of window decorations and menus. IIRC it was a fork of fvwm from way back in the day, and similarities can still be seen in the config files. I use it on everything including old 32-bit systems, and it's snappy and responsive everywhere.
GP means that 25 years ago, it was definitely not lightweight compared to many of the alternatives (GNOME and KDE being notable exceptions; I wouldn't have called them "light" back then either). Toady it's certainly light.
Enlightenment up to e16 always was light weight. There was eye candy that could be enabled like transparent/wobbly windows and whatnot, which could drag down a weak system, along with the ability to add high resolution wallpaper that took up a lot of memory, etc, but the core of the window manager doesn't have any kind of bloat or slowness. It was always configurable to be snappy and low resource. Just like fvwm.
This is a flash from an almost forgotten past. I'm happy people are still using and even improving Enlightenment.
I used to run Enlightenment in the late nineties and early 2000s, first by itself, then with Gnome bar. At some point Gnome turned hostile on power users and I switched to KDE, leaving also Enlightenment behind, as well as any extensive customization of my desktop. At that time, the ubiquitous themes.org also got in disarray, and I feel it was a bit an end of an era of design and theming experiments on the early Linux (and *BSD) desktop.
Wasn't Enlightenment something that just looked good in screenshots (compared to Win XP or even earlier ones)? I love desktop environments that look nice, I love effects and animations, if done well, and I love to be able to customize things (KDE/Plasma is doing a really good job in that regard imho). But Enlighenment? Whenever some screenshots excited me, I gave it another try for some hours, and then went back to KDE or Gnome.
It's what you call "ricing" today? You need it for some nice screenshots (or screencasts nowadays), you post them, and then you log off and use something else (i.e. the smartphone, the gaming console, Windows, KDE/Gnome, ...) because that just actually works.
Nah, e is great! It works just fine - it's better at a lot of things because it's fairly low-spec and doesn't require a terabyte of ram and 47 quintillion floating point operations just to open a menu. And if you're using a current version they're responsive to bug reports and whatnot. It does most everything you could want. And it looks damn fine while it's doing it.
Someone showed me the kitty terminal emulator a while ago. They made a big deal about how it can display images! Right there in the terminal! Wow! I was compelled to point out that terminology has had that (and video playback, too) for a LONG time.
One of my favourite features of enlightenment is that it has this thing from back in the day called "configurability", where behaviours tend to be optional and you can decide for yourself whether you want them enabled or not. I know it's not fashionable anymore and maybe not for everyone but personally I think it's a better approach than the gnome-style "You'll take what we give you and be happy about it" approach which is in vogue these days.
In a lot of cases, configurability is just a workaround for the issue that devs were unable to implement sth that just works 'fine'. So you could turn it on and live with its defects, or you turned it off and live without the feature. Linux Desktop was always full of that.
But yeah, I also do not like Gnome, because they more and more just removed the switches, but without spending effort to make things fine for everyone.
Plasma is so configurable, I've never seen anything more configurable. On any OS that I've seen.
My personal experience: Yes, you can also build your own environment out of blocks. And then you configure a lot. But not in order to customize it better, but in order to somehow glue these components together in a way that somehow remotely makes sense. :-/
And what's the point of video clips in the terminal? What weakness are you trying to workaround with that? E is a graphical desktop, no? Based on X11 or Wayland. There are actual media players!! A lot. Not a single one is really great, but most will be better than the terminal, I guess. VLC is that bad?
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.
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. ;)
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
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...
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.
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.
> 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
Oh, damn, that sounds cool. I might have to give that a try.
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 :)
> 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.
Whatever desktop environment you're referring to probably uses some of the same underlying third-party libraries for file format support as EFL, so what's the difference?
Why would being able to display graphical elements in my terminal program only be useful if it were supported on the Linux virtual console or some other terminal program I don't use?
Why would you expect "the same folks" to stop working on projects they find interesting or useful in favor of fixing your problems with entirely different applications?
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 discrepancy between the 16 colors support, where users can typically decide freely how exactly each color should look like (up to the point of having the background in white instead of black), and then the additional 256-color support, which adds 240 more colors (or sth like that?!), but with really fixed color values...
Everything is just a historically grown mess. And I've just mentioned a few points that came to my mind spontaneously, and there are probably a lot of further problems that I've never even heard about.
With that in mind, when I hear about the idea of hacking full graphics support into that, as a professional software developer my first instinct is to understand whether that's really worth the trouble. And what the rationale behind is. And whether it actually makes sense, from an architecture perspective if you want to call it this way. And all the arguments that I've read here made no sense to me at all. It feels more like a cult when I talk to terminal-centric users.
I don't have any privileges to decide for any involved project, though. If e.g. Konsole starts supporting that tomorrow, well, I'd doubt this was a useful thing, but then that's what it is. I could then only hope that they didn't break other things.
As a Linux user since 20 years, my experience tells me that all these things always break something else.
And then it's basically for people who say that basic image viewers start too slow for them. Either that's trivially fixable (and then we'd all be better off doing _that_ instead!), or just an illusion/cult, or the EFL previews will not be faster. There is just no way they could be faster. A basic graphical image viewer would do the same thing, just without all these indirection, translation to escape sequences, interpreting them again, etc.
Similar for the matters of proper keyboard support.
> 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 project which uses that control - I'm sure they'd be happy to look at your pull request.
> 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?
What?? so you open your preferred office tool. From terminology if you want to. I don't see why this is so difficult to understand? What about what I'm describing inhibits you from editing a spreadsheet in your spreadsheet editor?
> 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?
And all what? Raster already explained that it's like 3 lines of code.
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.
Did I say "editing the thing" or "working with the thing"? No, no I didn't say that. Because I didn't mean "Editing" or "working with".
> Fine. Just replace tycat with EFL in what I wrote before
OK so just to clarify: your complaint is that in order to be able to view a file of a particular format, EFL needs to be able to... parse that file format? ...Like every piece of PC software ever made?
> 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).
You don't know what you're talking about. It does indeed solve a problem. 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.
> 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! ;)
By your analogy, a GUI application is somehow better than a terminal one. Which it just isn't. You've got things backwards. A car that's stripped down to feel like a horse??? What the fuck are you on about?
> What context switch are you talking about
For the fifty-thousandth time: launching an entirely new application, waiting a geological age while it gets its shit together, switching to it, getting my bearings, and finally actually viewing the file.
> Why can't the same folks not improve keyboard support in e.g. VLC?
How would that relieve me of the need to start VLC in your suggested workflow?
> I would be surprised if VLC is worse in that regard than some terminal thingy
Who said anything about running a media player in a terminal?
(btw, off-subject, but there are a couple of really great terminal-based media players. And I can pretty much guarantee their keyboard controls are superior to vlc. But I'm not sure because I don't really try to keyboard control VLC. Because I don't have to. Because I don't have to launch it to preview a media file)
> You fire up a new tycat instance instead. Here VLC takes, idk, 500ms?!
I just fired up VLC. It took about 3 seconds (that's 3000ms, but what's 600% between friends?) from launch to a window being visible. According to htop, that empty VLC window with no file opened used up about 100Mb of my memory.
conversely:
$ time tycat /path/to/some_video.mp4
real 0m0.142s
user 0m0.117s
sys0m0.043s
I wasn't able to easily determine the ram used by tycat, because it closes so fast. But given how complicated it isn't, I'd expect it to be measured in kilobytes. I can (and have) written a bash script which is a very close equivalent to tycat as part of my command not found handle. It's 1.3Kb.
> What's the difference?
Well, about 2858ms, give or take. Or if you prefer: about 95.2%. And about 100Mb of RAM, give or take. And a context switch. And me taking my hand off the keyboard.
> Yeah, make them universally work on any virtual terminals, and then it'd be at least an interesting discussion
Feel free to submit a PR to the makers of your preferred terminal. Or you could switch to a terminal that's less shit than the one you're using.
Why do you expect me to care what terminal you're using? Do you think I write software in the hope that you in particular will use it? If you want to use worse software and not be supported by my terminology-specific stuff, be my guest.
> As long as I need some E terminal, or a particular terminal that is "popular with the kids"
When did anyone say you needed it or had to use it? I encouraged you to try it so that you might come off as less totally ignorant, but you're free to keep using your less-capable terminals and the worse software that works on them if you like. I don't actually care what you use.
> I really don't see at all why this is a good idea to spend any efforts for
No, you really don't.
Just remember to go and set your terminal to not support colour - after all it's not supported by any of those amber-screens! And while you're at it you better disable those extended unicode characters and switch back to baudot code. You can probably find a punchcard reader if you look around.
> 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.
Your analogy is so hilariously flawed and backwards. It's very clear you don't understand. "disabling the engine"? Lol.
No.
Your terminal emulator is a horse. A tired, old horse. That's gray and boring and totally uninteresting. So uninteresting that you haven't even noticed it's got an infection in its foot.
Meanwhile, my terminal emulator is a horse with cybernetic legs and wings that allow it to break the sound barrier, and also fly. And if I keep messing around a bit I might be able to get it to do even more cool stuff. Who knows what exactly? Will all of it be groundbreaking and super useful immediately? Maybe not. But it'll be fun and interesting and it can already do shit you never even imagined was possible and can't even comprehend when I tell you about it, insisting on asking backwards questions like "well yeah but if it's flying then what happens with the horseshoes?"
Have fun with your old nag!
> Give Dolphin a chance!
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.
"patched terminal font"?? What the fuck are you talking about?? It's almost like you don't understand what you're talking about.
> Bonus: It can display emojis
Your file manager can display emojis? Whoop-de-doo. Welcome to like, idk, 2010? Probably earlier tbh. Or are you bragging that your teminal emulator can display emojis? Like every terminal emulator I've seen for a very long time can, and like terminology could i don't even know how long ago because I've never seen it not do it.
> 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.
I'm just going to respond to this with something exactly as sensible and coherent. Here goes:
> 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. :-/
> In a lot of cases, configurability is just a workaround for the issue that devs were unable to implement sth that just works 'fine'.
No - You're making the assumption that everyone wants everything to be the same. Which is the same faulty assumption responsible for so many horrible horrible user interface choices made since smartphones became a thing.
For instance, there's a setting in enlightenment to allow you to choose how scrollbars work - you can:
a) Have sensible scrollbars like graphical applications have had for 40+ years, or
b) Have 'hover at the right to show the scrollbar and make it virtually impossible to select the last item in a list' behaviour, like the gtk-bros insist you want, or
c) Have no scrollbars at all if you prefer. Maybe you've got a touchscreen or a wheel mouse and a tiny screen, or whatever.
In e, this is just a setting where the user gets to choose what their computer does.
I know, it's a pretty revolutionary idea. So I'll just say it again: the user is the one who chooses what their computer does.
I haven't played with KDE seriously since the days of Corel Linux. I tried KDE4 back when it was a new thing, observed my desktop running at <1fps for the 10 minutes it took me to exit, and never tried it again. I've since heard good things about plasma. One day maybe I'll try it.
> And what's the point of video clips in the terminal? What weakness are you trying to workaround with that?
Aha, I can tell you haven't tried it! :)
It's a fantastic way to preview videos. You type "ls", and it gives you a list of files. And you say to yourself "Huh, I don't remember what 'video_clip_1280p.mp4' is. So you right-click on the filename and choose 'preview', and the video pops up in your terminal window and starts playing. And once I know what the file is I press escape and I'm back to where I was. It's marvellous! The only way I could think of improving this would be if there was some way to do it without any mouse interaction... like for example by typing 'typop video_clip_1280p.mp4'.
I do watch my movies in either vlc or mpv, usually - nobody is actually sitting around watching movies in their terminal (I hope!). For that, you use a media player. But for quickly previewing videos / images / audio (yes, audio too!), it's :chef-kiss:
I also have a custom command_not_found_handle which displays a randomly-chosen animated gif from a list I've built up (things like picard facepalming and people shaking their heads), along with a nice ascii art message in the vein of "You suck!" when I type an invalid command [1]. The reason I have that is........................................because it's fun!
Well, I explicitly said that I dislike Gnome for that. Sure, there are switches that are fine for actual customization, in order to actually adapt to personal preferences instead of work around technical weaknesses. I love how configurable Plasma is.
When I read further, about your scrollbar example, I wasn't sure if I would consider that a good example for your point or for my point... ^^ Anyways... Maybe it's a corner case. Fine. Not the worst one I've ever seen.
> I know, it's a pretty revolutionary idea. So I'll just say it again: the user is the one who chooses what their computer does.
That's obviously just the 2nd part of the story. At least so far. In some years, sure, every user (of FOSS software at least) can vibecode her own creepy set of features...
> It's a fantastic way to preview videos.
What you describe sounds exactly like what I would do, but I would start Dolphin instead. It's another shortcut for closing it. That's it. On the other hand: Here I can start arbitrary applications. For a LO-spreadsheet, LO would start! For a Blender model, Blender would start! VLC starts so quickly, and can read any remotely valid video file. I still don't really understand what I'm missing tbh...
> I also have a custom command_not_found_handle which displays a randomly-chosen animated gif from a list
Well, okay, that's far away from my taste how a system should behave... Maybe I'm just too old... ^^
> personal preferences instead of work around technical weaknesses
These are the same thing. Your personal preference is my technical weakness. Everybody has different requirements. The scrollbar is a great example: There might be a use-case for the (absolutely abysmal IMO) disappearing scrollbar pattern gnome wants to push on people. Maybe it's screen real estate. Having a scrollbar on a tiny screen could be argued as a technical weakness (and the mobile UI crowd did just that). But I don't have a screen real estate shortage on my 5760x1080 workspace. And people with certain mobility or perhaps vision issues might find the disappearing scrollbar to be completely unusable. It's actually an excellent example of my point. - there's no way to implement something as simple as scrollbars that will make everyone happy. AND THIS IS FINE! and good! as long as the user can choose.
> What you describe sounds exactly like what I would do, but I would start Dolphin instead
Then it's not "exactly like" what I would do at all - you'd take your hand off your keyboard and switch to your mouse to use a graphical file manager tool. And you'd wait for however long dolphin takes to start and enumerate the thousand files in that directory, and you'd watch your disk spin and your ram usage shoot up while it previews all the image files and videos in the directory, and counts items in the subdirectories. And then you'd wait while vlc starts up and click around to control that. Meanwhile I've already done 'typop cat_s' in the software I already had running and am half way through viewing the video without my hand leaving my keyboard.
> On the other hand: Here I can start arbitrary applications. For a LO-spreadsheet, LO would start! For a Blender model, Blender would start!
Um........... wow! I guess. That's pretty revolutionary! Starting programs! Gee, I guess it must not have been possible to start programs from a terminal since before GUIs were a thing! and xdg-open is not a thing, either. This seems like a bizarro-world argument to me.
> VLC starts so quickly
VLC absolutely does not start as quickly as terminology can pop up a preview. And it especially can't do it as seamlessly as terminology. Notice how you're starting a thousand different things in your examples? Yeah, I'm just doing all that from a single program. One that I already had running. It's fantastic. The only time I need to start a different program is if EFL doesn't support that filetype. And then it's trivial to do what you would do with xdg-open or libreoffice or blender.
> that's far away from my taste how a system should behave... Maybe I'm just too old
No, I feel you - it is (intentionally!) a bit obnoxious. But it's also a fun, makes me chuckle all the time. To each their own. Sort of like the user preferences thing: You might not like it, but that doesn't mean nobody could ever want it.
> Then it's not "exactly like" what I would do at all - you'd take your hand off your keyboard and switch to your mouse to use a graphical file manager tool.
Definitely yes. That's what I'd definitely do. But there is no inherent reason for that. It just feels superior to me. Why should graphical applications be fundamentally worse (e.g. in terms of keyboard support) than terminal applications when terminal emulators are a graphical application?
> And you'd wait for however long dolphin takes
Yes. All these 800ms! Every single day!
> And you'd wait for however long dolphin takes to start and enumerate the thousand files in that directory, and you'd watch your disk spin and your ram usage shoot up while it previews all the image files and videos in the directory, and counts items in the subdirectories.
Yeah, well, technically, of course. It just never felt like "waiting". It's a matter of milliseconds. And while it enumerates the thousands of files, I can already start working with the first ones. I don't have to wait for some software from the 80s that blocks user input meanwhile. BTW, terminal applications don't need to enumerate directories when they deal with it? How does that work? Even if you just press "tab" in your shell, it will probably do exactly that, no? I really don't see why terminal applications should be fundamentally faster than graphical applications in that regard (again: your terminal emulator is a graphical application, right?). If you know the file name starts with "cat_s", then you can also find it this way in Dolphin.
There are corner cases where I really search in a trickier, more dynamic way. Maybe with "find". Or five lines of Python scripting. But not hundred times a day. Definitely it's not worth rewriting every application now as a terminal app (that tries to be a graphical app via niche-in-niche technologies).
> Notice how you're starting a thousand different things in your examples? Yeah, I'm just doing all that from a single program.
Yes, that's one of the things that I feel so spooky with that approach. It cannot work... Not in general. Maybe for a handful of persons that constantly search for jpeg/png/mpeg files, in bulk mode, and need quick previews. For whatever actual job they are doing there...
PS: When can terminal apps get mouse coordinates in pixel granularity?
Then Qt and GTK can have backends for terminal( emulator)s and I can finally run a graphical terminal emulator inside a terminal emulator? tmux and screen will be dead!!! :D
And when do the terminal hacks for AR glasses start to appear? I still cannot walk through vimacs? Doing ":q!" with just some head gesture? Why not??
I used E17 for a while and the killer feature for me were independent virtual desktops accross monitors, meaning switching virtual desktop would only switch it on the monitor your focus was on.
I ultimately switched back to KDE despite that ergonomic advantage because it crashed too often and then to Gnome because KDE also crashed too often. Gnome has been rock solid ever since.
People have different tastes and opinions, and I don't remember how GNOME looked in 1998, but KDE 1? 2? wasn't so great imho (saying that as a huge fan of plasma, and intermittent KDE user for the last 25y).
I used enlightenment for a bit and was very happy with it - just like some things on a desktop at home don't matter, but do on a laptop. I've more than once mangled i3 and gnome or xfce or kde together to have the "desktop environment" things like wifi and power management and so on.. whereas in the 90s on a desktop I cared about neither of these things.
And while this was all very much a long time ago, I don't see how enlightenment would have changed - it's just a bit barebones compared to a DE, just like i3.
E16 was the hook that caught me and landed me, flopping and writhing, on the decks of Linux - I saw a black and white printout of someone’s desktop, and immediately set about figuring out how to get this unbelievable coolness working on my laptop. By the time I was done I was muttering modelines in my sleep, and had already committed my first patches to a kernel module.
I wonder how many other teenagers got catfished into becoming software devs and sysadmins by the siren song of rasterman.
It's such an underrated advantage of open source operating systems that if you like some bit of software, you'll likely be able to use it for decades to come. Even a core bit of software like a window manager. I grew to hate how you need to conform to someone's whim at Apple or Microsoft, or else you get locked out of new features.
The amount of abuse I hurled at Carsten Haitzler (Raster) during our time at VA Linux (where he worked on E as well as other stuff) was a complete sitcom unto itself; at one point he debated making a "zeruch insult generator" just to streamline the verbal abuse process.
I loved using the environment but would regularly harangue him for being glib on resource usage. It really was otherwise very ahead of the curve.
I liked the author's pragmatic take on the stability. Indeed that running bleeding edge now has implications to greater attack surface as the supply-chain attacks getting more and more common.
A nice and sincere excerpt from the recent past...
> Back when the XZ backdoor was introduced, I was scrolling through news on my Debian Sid laptop with some code compiling in the background. I learned of a backdoor in XZ Utils, potentially introduced by a state actor in version v5.6.0. Thinking back to the fact that I do, indeed, run a bleeding edge distro and update often, I immediately ran apt list --upgradable | grep xz-utils. Sure enough, the stains on my laptop from the coffee I spat out through the nose2 were pretty tough to deal with.
I really enjoy a good bug report like this. More people should write up their fixes and publish them!
But the really weird thing is that I could basically copy and paste that code into an open–source game that I occasionally work on. I have an open bug or two about game items with long names that cause the UI to look weird where ellipsization is the obvious solution. With only a few trivial tweaks Enlightenment’s code would just work. It’s almost like we should have a library for that sort of thing.
Enlightenment is pretty cool. Some years ago though I realised
that I just want the computer to be a fast and simple workstation
at all times. That's when I kind of stopped using KDE (and GNOME3
but I did not use it to begin with, it always felt like an opinionated
smartphone-UI pushed onto the desktop).
I think only few people use Enlightenment, so the resources to fix
bugs must also be small.
I love Enlightenment still, even the new ones. The most important component of it to me is Terminology. What a gorgeous and functional Terminal emulator.
Oh wow didn't expect someone my age to try out Enlightenment. Every so often I try to use Enlightenment (either e16/moksha or the latest version) but I always leave because it requires Connman and setting it up properly is a pain imo. Might try it again because of this blogpost.
Whenever I try something else, I always seem to keep going back to E16. Back in the day, it worked well in Gnome 2.x; these days I tend to use it in XFCE, but it feels a bit less integrated.
These are exactly the kinds of posts I love. It seems technical posts like this are less and less on the internet. Is this a result of "vibe coding"? We don't feel like writing up posts like this when a machine did the work? Maybe it's a result of fewer and fewer people blogging. Maybe I'm just old and yelling about things changing.
187 comments
No, no, you rejoice, a deterministic bug is the best sort of bug. because now you have a test case and a solid method to know when it is fixed. The sad bugs are the ones you can't find a test case for.
I also got a bittersweet chuckle out of how the author considers it a lightweight environment, I mean, they are not wrong, but think of how far we have fallen when e, the ultimate bling desktop environment is considered lightweight.
I stopped using it for other WMs. I remember how it was taking forever to release E17 and totally forgot about it. E16 was definitely awesome in those days.
> because now you have a test case and a solid method to know when it is fixed.
And where is fun in that? Where are now the nights in trying to reproduce it? Where are the doubts in the moments of rest "have i really fixed it, or is it still there"? Boring.
It _is_ lightweight in that context. I also love the fact that XaoS knowledge is useful in the context of "real software" programming!
"Hello! I’m Kamila Szewczyk (iczelia). I am 21 years old. I’m an expert programmer and aspiring mathematician, primarily interested in compiler construction, data compression, esoteric languages, statistics and numerical algorithms. ... Currently I am a full-time student based in Germany." [1]
And the start of the post:
"The editor in chief of this blog was born in 2004. She uses the 1997 window manager, Enlightenment E16, daily."
[1] https://iczelia.net/cv/
edit: added the [1] at the end of the first quote
I used to run Enlightenment in the late nineties and early 2000s, first by itself, then with Gnome bar. At some point Gnome turned hostile on power users and I switched to KDE, leaving also Enlightenment behind, as well as any extensive customization of my desktop. At that time, the ubiquitous themes.org also got in disarray, and I feel it was a bit an end of an era of design and theming experiments on the early Linux (and *BSD) desktop.
It's what you call "ricing" today? You need it for some nice screenshots (or screencasts nowadays), you post them, and then you log off and use something else (i.e. the smartphone, the gaming console, Windows, KDE/Gnome, ...) because that just actually works.
Someone showed me the kitty terminal emulator a while ago. They made a big deal about how it can display images! Right there in the terminal! Wow! I was compelled to point out that terminology has had that (and video playback, too) for a LONG time.
One of my favourite features of enlightenment is that it has this thing from back in the day called "configurability", where behaviours tend to be optional and you can decide for yourself whether you want them enabled or not. I know it's not fashionable anymore and maybe not for everyone but personally I think it's a better approach than the gnome-style "You'll take what we give you and be happy about it" approach which is in vogue these days.
But yeah, I also do not like Gnome, because they more and more just removed the switches, but without spending effort to make things fine for everyone.
Plasma is so configurable, I've never seen anything more configurable. On any OS that I've seen.
My personal experience: Yes, you can also build your own environment out of blocks. And then you configure a lot. But not in order to customize it better, but in order to somehow glue these components together in a way that somehow remotely makes sense. :-/
And what's the point of video clips in the terminal? What weakness are you trying to workaround with that? E is a graphical desktop, no? Based on X11 or Wayland. There are actual media players!! A lot. Not a single one is really great, but most will be better than the terminal, I guess. VLC is that bad?
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!
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...
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.
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.
http://www.rasterman.com/files/efm-typebuf-ex.webm
http://www.rasterman.com/files/efm-typebuf-ex.webm
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 :)
> 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.
Whatever desktop environment you're referring to probably uses some of the same underlying third-party libraries for file format support as EFL, so what's the difference?
Why would being able to display graphical elements in my terminal program only be useful if it were supported on the Linux virtual console or some other terminal program I don't use?
Why would you expect "the same folks" to stop working on projects they find interesting or useful in favor of fixing your problems with entirely different applications?
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 discrepancy between the 16 colors support, where users can typically decide freely how exactly each color should look like (up to the point of having the background in white instead of black), and then the additional 256-color support, which adds 240 more colors (or sth like that?!), but with really fixed color values...
Everything is just a historically grown mess. And I've just mentioned a few points that came to my mind spontaneously, and there are probably a lot of further problems that I've never even heard about.
With that in mind, when I hear about the idea of hacking full graphics support into that, as a professional software developer my first instinct is to understand whether that's really worth the trouble. And what the rationale behind is. And whether it actually makes sense, from an architecture perspective if you want to call it this way. And all the arguments that I've read here made no sense to me at all. It feels more like a cult when I talk to terminal-centric users.
I don't have any privileges to decide for any involved project, though. If e.g. Konsole starts supporting that tomorrow, well, I'd doubt this was a useful thing, but then that's what it is. I could then only hope that they didn't break other things.
As a Linux user since 20 years, my experience tells me that all these things always break something else.
And then it's basically for people who say that basic image viewers start too slow for them. Either that's trivially fixable (and then we'd all be better off doing _that_ instead!), or just an illusion/cult, or the EFL previews will not be faster. There is just no way they could be faster. A basic graphical image viewer would do the same thing, just without all these indirection, translation to escape sequences, interpreting them again, etc.
Similar for the matters of proper keyboard support.
But if you want to be able to preview libreoffice spreadsheets or PDFs in terminology - and also incidentally and for free every other EFL project which uses that control - I'm sure they'd be happy to look at your pull request.
What?? so you open your preferred office tool. From terminology if you want to. I don't see why this is so difficult to understand? What about what I'm describing inhibits you from editing a spreadsheet in your spreadsheet editor? And all what? Raster already explained that it's like 3 lines of code.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.
Did I say "editing the thing" or "working with the thing"? No, no I didn't say that. Because I didn't mean "Editing" or "working with".
OK so just to clarify: your complaint is that in order to be able to view a file of a particular format, EFL needs to be able to... parse that file format? ...Like every piece of PC software ever made? You don't know what you're talking about. It does indeed solve a problem. 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. By your analogy, a GUI application is somehow better than a terminal one. Which it just isn't. You've got things backwards. A car that's stripped down to feel like a horse??? What the fuck are you on about? For the fifty-thousandth time: launching an entirely new application, waiting a geological age while it gets its shit together, switching to it, getting my bearings, and finally actually viewing the file. How would that relieve me of the need to start VLC in your suggested workflow? Who said anything about running a media player in a terminal?(btw, off-subject, but there are a couple of really great terminal-based media players. And I can pretty much guarantee their keyboard controls are superior to vlc. But I'm not sure because I don't really try to keyboard control VLC. Because I don't have to. Because I don't have to launch it to preview a media file)
> You fire up a new tycat instance instead. Here VLC takes, idk, 500ms?!
I just fired up VLC. It took about 3 seconds (that's 3000ms, but what's 600% between friends?) from launch to a window being visible. According to htop, that empty VLC window with no file opened used up about 100Mb of my memory.
conversely:
I wasn't able to easily determine the ram used by tycat, because it closes so fast. But given how complicated it isn't, I'd expect it to be measured in kilobytes. I can (and have) written a bash script which is a very close equivalent to tycat as part of my command not found handle. It's 1.3Kb. Well, about 2858ms, give or take. Or if you prefer: about 95.2%. And about 100Mb of RAM, give or take. And a context switch. And me taking my hand off the keyboard. Feel free to submit a PR to the makers of your preferred terminal. Or you could switch to a terminal that's less shit than the one you're using.Why do you expect me to care what terminal you're using? Do you think I write software in the hope that you in particular will use it? If you want to use worse software and not be supported by my terminology-specific stuff, be my guest.
When did anyone say you needed it or had to use it? I encouraged you to try it so that you might come off as less totally ignorant, but you're free to keep using your less-capable terminals and the worse software that works on them if you like. I don't actually care what you use. No, you really don't.Just remember to go and set your terminal to not support colour - after all it's not supported by any of those amber-screens! And while you're at it you better disable those extended unicode characters and switch back to baudot code. You can probably find a punchcard reader if you look around.
Your analogy is so hilariously flawed and backwards. It's very clear you don't understand. "disabling the engine"? Lol.No.
Your terminal emulator is a horse. A tired, old horse. That's gray and boring and totally uninteresting. So uninteresting that you haven't even noticed it's got an infection in its foot.
Meanwhile, my terminal emulator is a horse with cybernetic legs and wings that allow it to break the sound barrier, and also fly. And if I keep messing around a bit I might be able to get it to do even more cool stuff. Who knows what exactly? Will all of it be groundbreaking and super useful immediately? Maybe not. But it'll be fun and interesting and it can already do shit you never even imagined was possible and can't even comprehend when I tell you about it, insisting on asking backwards questions like "well yeah but if it's flying then what happens with the horseshoes?"
Have fun with your old nag!
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."patched terminal font"?? What the fuck are you talking about?? It's almost like you don't understand what you're talking about.
Your file manager can display emojis? Whoop-de-doo. Welcome to like, idk, 2010? Probably earlier tbh. Or are you bragging that your teminal emulator can display emojis? Like every terminal emulator I've seen for a very long time can, and like terminology could i don't even know how long ago because I've never seen it not do it. I'm just going to respond to this with something exactly as sensible and coherent. Here goes:Argle bargle snerf blu carn delg bling blong blu barg sneh bork mert.
> 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!
Haha, you beat me to it. Basically the same example.
> that devs were unable to implement sth that just works 'fine'.
Just like today. But we lost the option to make it work.
For instance, there's a setting in enlightenment to allow you to choose how scrollbars work - you can:
a) Have sensible scrollbars like graphical applications have had for 40+ years, or
b) Have 'hover at the right to show the scrollbar and make it virtually impossible to select the last item in a list' behaviour, like the gtk-bros insist you want, or
c) Have no scrollbars at all if you prefer. Maybe you've got a touchscreen or a wheel mouse and a tiny screen, or whatever.
In e, this is just a setting where the user gets to choose what their computer does.
I know, it's a pretty revolutionary idea. So I'll just say it again: the user is the one who chooses what their computer does.
I haven't played with KDE seriously since the days of Corel Linux. I tried KDE4 back when it was a new thing, observed my desktop running at <1fps for the 10 minutes it took me to exit, and never tried it again. I've since heard good things about plasma. One day maybe I'll try it.
Aha, I can tell you haven't tried it! :)It's a fantastic way to preview videos. You type "ls", and it gives you a list of files. And you say to yourself "Huh, I don't remember what 'video_clip_1280p.mp4' is. So you right-click on the filename and choose 'preview', and the video pops up in your terminal window and starts playing. And once I know what the file is I press escape and I'm back to where I was. It's marvellous! The only way I could think of improving this would be if there was some way to do it without any mouse interaction... like for example by typing 'typop video_clip_1280p.mp4'.
I do watch my movies in either vlc or mpv, usually - nobody is actually sitting around watching movies in their terminal (I hope!). For that, you use a media player. But for quickly previewing videos / images / audio (yes, audio too!), it's :chef-kiss:
I also have a custom command_not_found_handle which displays a randomly-chosen animated gif from a list I've built up (things like picard facepalming and people shaking their heads), along with a nice ascii art message in the vein of "You suck!" when I type an invalid command [1]. The reason I have that is........................................because it's fun!
[1] https://imgur.com/a/tL9h8Xs
When I read further, about your scrollbar example, I wasn't sure if I would consider that a good example for your point or for my point... ^^ Anyways... Maybe it's a corner case. Fine. Not the worst one I've ever seen.
> I know, it's a pretty revolutionary idea. So I'll just say it again: the user is the one who chooses what their computer does.
That's obviously just the 2nd part of the story. At least so far. In some years, sure, every user (of FOSS software at least) can vibecode her own creepy set of features...
> It's a fantastic way to preview videos.
What you describe sounds exactly like what I would do, but I would start Dolphin instead. It's another shortcut for closing it. That's it. On the other hand: Here I can start arbitrary applications. For a LO-spreadsheet, LO would start! For a Blender model, Blender would start! VLC starts so quickly, and can read any remotely valid video file. I still don't really understand what I'm missing tbh...
> I also have a custom command_not_found_handle which displays a randomly-chosen animated gif from a list
Well, okay, that's far away from my taste how a system should behave... Maybe I'm just too old... ^^
> Then it's not "exactly like" what I would do at all - you'd take your hand off your keyboard and switch to your mouse to use a graphical file manager tool.
Definitely yes. That's what I'd definitely do. But there is no inherent reason for that. It just feels superior to me. Why should graphical applications be fundamentally worse (e.g. in terms of keyboard support) than terminal applications when terminal emulators are a graphical application?
> And you'd wait for however long dolphin takes
Yes. All these 800ms! Every single day!
> And you'd wait for however long dolphin takes to start and enumerate the thousand files in that directory, and you'd watch your disk spin and your ram usage shoot up while it previews all the image files and videos in the directory, and counts items in the subdirectories.
Yeah, well, technically, of course. It just never felt like "waiting". It's a matter of milliseconds. And while it enumerates the thousands of files, I can already start working with the first ones. I don't have to wait for some software from the 80s that blocks user input meanwhile. BTW, terminal applications don't need to enumerate directories when they deal with it? How does that work? Even if you just press "tab" in your shell, it will probably do exactly that, no? I really don't see why terminal applications should be fundamentally faster than graphical applications in that regard (again: your terminal emulator is a graphical application, right?). If you know the file name starts with "cat_s", then you can also find it this way in Dolphin.
There are corner cases where I really search in a trickier, more dynamic way. Maybe with "find". Or five lines of Python scripting. But not hundred times a day. Definitely it's not worth rewriting every application now as a terminal app (that tries to be a graphical app via niche-in-niche technologies).
> Notice how you're starting a thousand different things in your examples? Yeah, I'm just doing all that from a single program.
Yes, that's one of the things that I feel so spooky with that approach. It cannot work... Not in general. Maybe for a handful of persons that constantly search for jpeg/png/mpeg files, in bulk mode, and need quick previews. For whatever actual job they are doing there...
Then Qt and GTK can have backends for terminal( emulator)s and I can finally run a graphical terminal emulator inside a terminal emulator? tmux and screen will be dead!!! :D
And when do the terminal hacks for AR glasses start to appear? I still cannot walk through vimacs? Doing ":q!" with just some head gesture? Why not??
SCNR
I ultimately switched back to KDE despite that ergonomic advantage because it crashed too often and then to Gnome because KDE also crashed too often. Gnome has been rock solid ever since.
I used enlightenment for a bit and was very happy with it - just like some things on a desktop at home don't matter, but do on a laptop. I've more than once mangled i3 and gnome or xfce or kde together to have the "desktop environment" things like wifi and power management and so on.. whereas in the 90s on a desktop I cared about neither of these things.
And while this was all very much a long time ago, I don't see how enlightenment would have changed - it's just a bit barebones compared to a DE, just like i3.
I wonder how many other teenagers got catfished into becoming software devs and sysadmins by the siren song of rasterman.
I loved using the environment but would regularly harangue him for being glib on resource usage. It really was otherwise very ahead of the curve.
> Sadly, the hang was deterministic:
Huh, someone's in it for the thrill of the hunt, I see...
There was some kind of editing snafu though, the loop header in the big (first) code block reads:
But the references to it in the text, and updated versions in the patches, show it as just That was confusing me a bit.A nice and sincere excerpt from the recent past...
> Back when the XZ backdoor was introduced, I was scrolling through news on my Debian Sid laptop with some code compiling in the background. I learned of a backdoor in XZ Utils, potentially introduced by a state actor in version v5.6.0. Thinking back to the fact that I do, indeed, run a bleeding edge distro and update often, I immediately ran apt list --upgradable | grep xz-utils. Sure enough, the stains on my laptop from the coffee I spat out through the nose2 were pretty tough to deal with.
My last time I used it was still in the 1990's, before I settled into Afterstep and soon afterwards Windowmaker.
In what concerns my use of GNU/Linux, it was CDE on others.
Apparently nothing big came out of Enlightenment and Tizen.
I had the classic setup with the apache helicopter on the background and virtual desktops with preview. On MacOS however.
To this day i am still using a single screen, with virtual desktops ordered the same way.
But the really weird thing is that I could basically copy and paste that code into an open–source game that I occasionally work on. I have an open bug or two about game items with long names that cause the UI to look weird where ellipsization is the obvious solution. With only a few trivial tweaks Enlightenment’s code would just work. It’s almost like we should have a library for that sort of thing.
I think only few people use Enlightenment, so the resources to fix bugs must also be small.
> It’s themable, hackable, lightweight
Certainly wasn't considered lightweight back then :-)
I never saw the appeal of Enlightenment, but a very nice write-up regardless.
Coincidence, or collateral hug?
The documentation is there: https://www.enlightenment.org/contrib/enlightenment-debug
Why re-attaching and not just resume then ctrl+c ? Is this some kind of clever hack I dont know about.
I've been going backwards to Afterstep and Window Maker theming. Maybe I'll get back to E in a few years.