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.
the cost of launching a new process with a gui is not cheap. there's a lot of setup before you even get a window up ... when that process is already there (terminal) with all of that cost paid for it is actually provably cheaper in terms of cpu cycles, latency etc. to pop up an image/video in your terminal. and cheaper not by 1 or 2 ms... but by 100's ms or more. that new window is not cheap. you also have the visual disconnect - the window pops up somewhere else with your wm having no idea that that new window is related to the terminal you ran it from because there will be no transient_for hints set to say that. relying on process tree hunting to figure this out is a crapshoot at best and will probably give you more misses than hits. we can go down that rabbit hole if you want but trust me - it is measurably less overhead to pop it up in a terminal with a few dozen chars worth of escapes sent to the terminal to do it.
In terms of wall clock time, on my system, it costs nothing. I can start a "Hello World" application based on Qt or GTK, and the window is there while I'm still releasing the Enter key. Technically, sure, a lot of things happen... But it's not happening on a P-90 anymore... :) BTW: My machine wasn't particularly strong or expensive either, when I bought it 6 years ago. ;)
When I read (in your other reply) that you are trying "soften the boundaries between workflows and bring some features of of workflow into another", well, that probably sounds nice... I just get a headache tbh...
I'm sure it was fun and a big achievement to implement that. And there obviously is a fan-base for that. So where am I... :)
it is effectively a keyboard driven GUI. you potentially get the full power of the commandline to do your actions without giving up a graphical view of your system.
ttyphoon on the other hand is a terminal project that approaches this from the other side, getting even more graphics and structured data support into the terminal: https://github.com/lmorg/ttyphoon
both have a similar goal: get away from the old limitations that terminals have but keep the power they offer.
I actually do somewhat like the paradigm, from a user perspective. If done well, why not, could be cool... If done very well, it could be very very cool...
But please let's not invent these new kinds of applications based on terminal tech. I still don't see why one would go this pointless detour, instead of just start as a graphical application, tech-wise.
let's not invent these new kinds of applications based on terminal tech
i agree with that. the terminal with its escape sequences needs to go away, it is old and limited. however the commandline will not go away. nor should we give up text based applications. both are too powerful for that.
so what we want is a modernization of the commandline. this is happening with alternative shells, but also with ttyphoon and other projects. and efm brings the power of the commandline to the gui directly. i'd like to see more projects like that.
i see a large spectrum here. some projects try small incremental changes (sixels for example, a wierd concept, and i ask myself why, but ok). others try to bring more powerful datastructures to the commandline. good, because those are terminal independent. on the GUI side there have been various attempts to send objects between applications already for decades. none of them achieved broad acceptance. there is a lot of potential still. a GUI for data pipes for example would be nice. there is one for the terminal. tmux is a terminal manager, it is gaining GUI support. doesn't get rid of the terminal, but modernizes it. small incremental steps. 10 years ago i would not even have believed that alternative shells would gain acceptance. but they are. half a dozen projects that break bash compatibility and are gaining popularity.
Aah, I see. So then I guess that wasn't a demand that people who have their own perfectly functional terminals with graphics support that they've been using for years and are perfectly happy with patch graphics functionality into every other terminal in existence just in case you might happen to try to use a terminal program that requires graphics support. I guess I must have misunderstood. Silly me.
> can only comment things and add my 2 ct.
Perhaps it would be wise to do some basic reading and perhaps even testing to understand some of the basics about how the technology works before making comments about them. This is an excellent method to not come across as totally uninformed and ignorant.
> 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 rail
????
My terminal displays emojis just fine and they align just fine as far as I know. Have you considered trying software that isn't shit? Or filing a bug report containing more than zero detail on the issue?
> Or that conceptual discrepancy between the 16 colors support, where users can typically decide freely how exactly each color should look like
This is actually extremely straightforward if you spend 5 minutes understanding how it works, particularly with regards to backwards compatibility with terminals that don't support it. Which are few - it's incredibly well-supported in almost all terminals. I don't know what you're talking about...
> (or sth like that?!)
...and neither do you.
Damn, your nose is going to get right out of joint if you ever learn about RGB terminal colours. Shhh, nobody tell him!
> Everything is just a historically grown mess
Indeed! Finally something we agree on!
And people working to improve terminals with efforts like terminology and kitty are trying to do what they can to address some of these issues without breaking anything. Which is hard. It's really quite an admirable effort worthy of respect.
But first you'd need to understand what they're doing.
> there are probably a lot of further problems that I've never even heard about.
I have no doubt that there's lots that you haven't heard about
> 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
Ooh, appeal to authority. I'm so impressed.
Perhaps, as "a professional software developer", you should take the time to understand the tech that you're talking about. Doing so will help you form an informed opinion and will help you to avoid wasting everyone's time reading ignorant, uninformed, assumption-laden nonsense.
> And what the rationale behind is
Excellent! So go back and try actually reading my previous posts. That'll help a lot with this.
> And whether it actually makes sense, from an architecture perspective
Excellent! So go and read the docs and form an actual opinion that isn't "I don't like the sound of this herp derp". I'm sure once it's not immediately obvious that you have no clue what you're talking about and have spent zero seconds attempting to understand the architecture, people will be happy to discuss your pull requests making all the revolutionary improvements that I'm sure you'll make.
> And all the arguments that I've read here made no sense to me at all
Then maybe you should try actually reading them
> It feels more like a cult when I talk to terminal-centric users.
Aah! And the penny drops! You don't know how to use the terminal and don't understand its benefits. So of course you don't understand the arguments I've repeatedly outlined for why this functionality is desirable.
> As a Linux user since 20 years, my experience tells me that all these things always break something else
Ooh, appeal to authority #2. I'm so impressed! Meanwhile I've been using linux since last century.
Enlighten me, then, o great software developer and 20-year Linux user: What does the graphics support in terminology / kitty break?
Maybe you should spend 5 minutes understanding how it works before you go making assumptions.
> people who say that basic image viewers start too slow for them
You. Do. Not. Understand. My. Point. Because you don't understand how I operate. Because you don't know how to use a terminal.
> Either that's trivially fixable (and then we'd all be better off doing _that_ instead!),
Please explain, in excruciating detail, exactly how you plan to "trivially" prevent the need to load in the qt library to get VLC to start and show its qt interface. I look forward to reading your technical paper.
> or just an illusion/cult, or the EFL previews will not be faster
I already provided you with hard timing data demonstrating that previewing videos in terminology is more than 90% faster than the way you'd do it. If you have something other than completely uninformed assumptions based on nothing at all to back up your claim that previewing in terminology is not faster, please present your data here.
But as I've alluded to repeatedly and you've completely ignored, speed is actually not the primary issue. It's the context change. It's that "taking my hand off the keyboard" thing. Even more, it's the "staying in the same application" thing. And it's also more than all those factors. It's a similar phenomenon to how I can't really explain to you just exactly how pipes are amazing and one of the most incredibly powerful paradigms you could ever learn. I can't really explain it to you properly because IMO the only way that it will really click in your head is in the moment that you really actually understand pipes, and to do that you have to actually learn and work with pipes.
You're just fixated on the speed because you don't understand the cost of the context change because you don't understand how terminal people work, because you don't know how to use a terminal and think that switching contexts constantly and twiddling your thumbs while GUIs initialise is normal and fine. And that's fine, if you want to work like a windows user. You do you, and more power to you. Just stay the fuck away from making suggestions about how terminals should or shouldn't work.
> There is just no way they could be faster
I have already explained in excruciating detail some of the major reasons why they are. If you still don't understand, I'd suggest reading my previous responses where I explain that. Or, you know, doing some further reading to understand the technology you're talking about.
> A basic graphical image viewer would do the same thing, just without all these indirection, translation to escape sequences, interpreting them again
Maybe you should spend 5 minutes reading and understanding the technology you're commenting about, so that you don't make wildly incorrect assumptions, and don't come off as totally ignorant and uninformed.
Who translates what exactly into escape sequences that you think is more expensive than loading up the gtk/qt/wx widget libraries and instantiating a new window?
> Similar for the matters of proper keyboard support
Without some detail of what you're talking about this is just a non sequitur. Terminology works fine with my keyboard, as has...let me think... every terminal I've used in the last 30+ years.
Since we're doing non sequiturs, allow me to retort: Avatar 3 was shit.
> 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. :-/
> 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. [...] Hell, I basically want to just have Blender there.
I'm sure the enlightenment folks will be happy to look at your patches for these features you want. I'm not sure how you plan to integrate blender, but you've been programming professionally since 20 years, so I'm sure you have a plan and understand in ways that I simply can't comprehend.
Raster already pointed out, and you ignored, that actually it does support pdfs, and libreoffice already. Seems it just never occurred to me to try them. So you actually won't need to patch that in at all!
> We all know this is oversimplified in so many ways... ;)
Do we? I don't. Maybe you can point me to the relevant lines of source code, where it's more than 3 lines. I'll look forward to seeing your link.
> 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?
No, it does both graphics and video with the same 3 lines of code. As has already been explained and you ignored and/or failed to understand.
> 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.
So, to summarise: you bring up an argument that it shouldn't be done due to code complexity, then when that is rebuked because the additional code complexity is very close to zero, just say "the code isn't even my primary concern at all", without elaborating any further to outline what your concern actually is. And to summarise the summary: you don't actually have any reasoning, you just don't like it because you don't like it.
> But just the repetition doesn't make it sound more reasonable to me tbh
Then why do you seem to think that saying "herp derp, I don't understand therefore it's a cult" over and over is going to sound more reasonable to me at some point?
> That might very much be my fault!
Yep
> Unfortunately, you didn't help me in that regard either so far.
Maybe it'd help if you pulled your head out of your ass and actually read what I wrote.
> Well, if you have a superior approach, which is quicker and more seamless, I'd definitely want us to see it using for everything!
We're talking about previewing. I have a superior approach for previewing. Which leads me to re-state my previous question: Did I say "editing the thing" or "working with the thing"?
> 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?
I suspect it'll be much more complex than that, but you're a professional programmer since 20 years who has never looked at the code or even run the software, so you probably know better than I do.
I'm sure the e folks will be happy to look at the patches you provide for this functionality you want.
I suspect there might be a bit of discussion about things like "is this desirable" and "does this break compatibility with existing things" because this is a bizarro thing that you've invented out of nowhere based on nothing anybody said anywhere ever. But I'm sure they'll be happy to discuss it once you submit a patch.
> I 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.
I look forward to seeing your patch that does this without breaking compatibility with ~50 years of legacy software.
> three or four file formats (or whatever EFL supports)
Again, EFL supports a lot of formats. Including ones I didn't even know about, like the pdf and libreoffice docs you wanted. I guess you didn't bother reading that before.
> 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.
So what's your point? How is it relevant that my terminal emulator runs on X? I'm not talking about the environment that runs my terminal, I'm talking about things that run in my terminal.
As for "terminal-based X11 emulators:, there's a fairly prominent one you might have heard of, it's called xorg. If you try to run 'startx' inside an X session you'll have problems.
> Ahh, you're also one of the authors of some parts of that software stack?
When did I say that?
> Either way, no I don't expect anything
You demanded that support for terminology's graphics sequences needed to be patched into every terminal emulator that exists in order for you to consider it valid for some reason.
By doing so, you're saying that people who write software that supports these graphical protocols (or maybe the authors of the terminals? It's unclear who you expected to do this for you) should jump through huge, unnecessary hoops just so that you can run their software (that you claim you don't want to run), rather than you..........simply running their software in the environment it requires.
> 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.
Maybe you don't tend to use all your machine's resources, but the way I use my machine, it's constantly at near or over 100% capacity. I'm constantly fighting against swap, no matter how much ram I have. Right now my machine is using about 113% of available ram. I'll have to flush it out and clean it up soon to prevent too much swapping. I probably wouldn't want to start vlc right now without closing something else first - if I wanted to watch a video right now I'd use something more lightweight (or something I already have loaded, like my terminal). This is a normal state of affairs for me.
> A useful baseline seems to be the actual Linux terminal. It can do 16 colors. Unfortunately, it doesn't even support emojis, though.
In what way is this "a useful baseline"? Useful for what? Why is the extremely-well-supported 256 colour set or RGB not more useful? Who uses linux in text-only mode or with a display that can't do rgb in 2026 in any situation that isn't headless or exotic? Why can't they just run more complex stuff on the framebuffer with rgb colour if they want it? Why, given the above, is emoji support in text-only mode important? to whom? For what?
> 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.
Why would anybody who isn't working with extremely exotic legacy hardware care about this in 2026?
> And even more so all the applications that I know that I could run inside it.
Which ones don't run in terminology?
> Again, I'm always open for something exciting.
...as long as it's not the heresy of displaying graphics in a a teminal.
> for all the comfort I get back,
See this is the point right here. You consider it comfort. I consider it nuisance. So go use your GUI applications and enjoy them and let others enjoy their preference. Like I said a hundred thousand years ago.
> But yeah, my basic point was not actually to evangelize for Dolphin or VLC or any particular app.
No, it was to say - without having even bothered to try it yourself - that there's no use for a thing that I use all the time. And then in order to support your thesis you started evangelising the massive pile of software that you'd use to achieve what I can do better with one program that I always have running.
> Well, how do "the kids" get their Git icons etc? As far as I can remember, they call it "Nerd Fonts".
How are nerd fonts at all relevant to any part of the discussion?
Oh, I see: You said "[dolphin] even can render actual icons without a patched terminal font!"...
...you mean like terminology and other graphics-supporting terminals can? If they were using terminology or kitty, they wouldn't need to patch the nerd font icons into their terminal font - they could just display the icon they want.
So your point was to sarcastically suggest another actually-pretty-good use-case for the functionality you're arguing against. Got it.
> But all I've tried are buggy sometimes in what glyph widths they report
And what happened when you filed bug reports about this? Please link to them, I'll be interested to read your reports for more detail than none at all.
> If terminology does better in that regard, good news! Nice!
Well I don't know whether it does or not. Because you haven't bothered to actually describe the issue you claim exists in any detail. Or done anything more than make a vague and as-far-as-i-can-tell-incorrect assertion that terminals can't display emojis properly. As if that was somehow relevant to whether they should be able to display graphics or not.
> As an application developer, I still cannot assume that my users all have terminology, so it's still no solution
As an application developer, you have control over this thing called "system requirements" for your software. And you can do things like adding "requires terminology" or "feature X requires terminology" in there. Or you could put a note on the relevant issue in your issue tracker saying "you can work around this by using terminology, which doesn't have this issue". But of course we'd need to know whether that's true, first, and for that we'd need more than zero detail.
Or perhaps you should just make your application graphical, since you've said solves the problem you're having with emojis and repeatedly asserted that graphical software is inherently better.
Which of these is appropriate, i don't know, because you'd have to give more than zero detail for me to be able to tell.
Maybe when you're linking to more than zero detail you can also explain how it has anything to do with whether supporting graphics in terminals is a good idea.
> 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<tab><enter>' 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...
> Why should graphical applications be fundamentally worse (e.g. in terms of keyboard support) than terminal applications when terminal emulators are a graphical application?
Why don't you ask the makers of gui software?
> Yes. All these 800ms!
For you. This one time that you tested. It took almost an entire second. Or, another way you could say that would be "longer than it takes terminology to pop up a preview".
> Yeah, well, technically, of course. It just never felt like "waiting". It's a matter of milliseconds
Well then either dolphin is by some miracle orders of magnitude faster than any file browser I have ever seen (which includes earlier versions of dolphin that presumably have fewer features than the current one), or you're not viewing folders containing many files. Or maybe you just have the fastest and most powerful computer ever built. Or perhaps you just don't have any expectation of a performant UI and consider twiddling your thumbs to be no big deal.
> terminal applications don't need to enumerate directories when they deal with it? How does that work?
They do need to enumerate files, obviously, but they don't need to - for each and every file and subdirectory:
1. determine the mimetype for the tile, which may involve actually opening and reading the file
2. look up that mimetype in their "mime type -> friendly description" table
3. look up the default application that needs to be opened if you double-click on said file based on that mimetype
4. if the mimetype is "video" or "image", look in their cache for a thumbnail for the file, and if that doesn't exist fire up a thumbnailer to generate one, which likely involves opening and reading in the entire file.
6. load the aforementioned thumbnail into memory and display it in the appropriate place
7. as previously mentioned, enumerate and count the number of items in directories
8. I'm sure a bunch of other similar things that I can't even be bothered trying to remember right now.
> Even if you just press "tab" in your shell, it will probably do exactly that, no?
...interrogate every single file for its mimetype, load up a thumbnail for every single media file, and count the number of items in every single subdirectory? No, it will not do that when I press tab.
> I really don't see why terminal applications should be fundamentally faster than graphical applications in that regard
..........um, what?
Seems to me like maybe you've never used a terminal program? Or perhaps you've never used a gui program? I'm not sure what to say to this. I don't think I've ever seen a piece of GUI software which comes close to the speed of its terminal-based equivalent. I'll grant you there are outliers, but those are rare and every single example I can think of doesn't use a GUI toolkit.
There are a few factors at play here. One big one (maybe the biggest?) is simply the complexity of the interface: Terminal emulators are built and optimised to display a whole bunch of text very quickly. They have one job: display text. GUIs and GUI toolkits, on the other hand, are huge complex libraries with a large number of different controls that they need to draw in the right place, do layout, have to deal with mouse interaction and event systems and the windowing system, deal with weird input methods and accessibility, etc etc etc etc etc etc etc. They're orders of magnitude more complex just in their interfaces. And that's before you start doing things like loading icons for every little button you're displaying and thumbnailing every media file in a directory so that you can load it as a pretty icon in your file manager. And before you start taking into account that a lot of gui software is just poorly written trash seemingly written by morons under the CADT model (Hi, gnome!).
GUIs are fine, and the best option for a bunch of things. But they're much MUCH less efficient than terminal-based programs.
I don't know what else to say. Go talk to every single GUI application author ever, I guess?
> your terminal emulator is a graphical application, right?
Yes. One that's using a very limited set of GUI widgets compared to almost any other graphical program, and which has one job: display text. Indeed, the speed of terminals does have a marked effect on the speed of program execution in many cases: just try doing `time cp -Rv /usr /some/new/disk` - you'll spend a LOT of time just listing the hundreds of thousands of kilobyte-sized files you're copying, and the amount of text you're spitting out and scrolling your terminal emulator needs to do will slow down the file copying. If you compare this with `time cp -R /usr /some/new/disk` you'll find the non-verbose incantation to be much faster. Part of this is the fact that it doesn't need to run the printf statements, but much more of it is the time the terminal takes to output what is being printed, and especially scrolling. You'll also notice a pretty significant difference depending on which terminal you use - xterm will be faster than gnome-terminal, for example, because it's not bloated trash. KDE's terminal might be better than gnome's, but it will almost certainly not beat xterm. Nor will terminology. Similarly, running the verbose copy in a screen session and then switching to another 'window' in screen will speed up the copy, because even though it's verbose and running the printf statements, the terminal doesn't actually have to do the work of displaying the huge stream of text. Similarly, you can do a crude benchmark of your terminal's efficiency with bash by just spitting out a long line of text a million times and timing how long that takes.
> If you know the file name starts with "cat_s", then you can also find it this way in Dolphin.
Sure. After you've waited almost an entire second, if you're lucky, for dolphin to start, and waited for it to enumerate all the files, and waited for it to count subdirectories, and waited for it to check its cache for thumbnails, etc etc etc etc etc etc.
Meanwhile, like I said, I'll already be half way through previewing the video, and my workflow won't involve switching to some worse program.
> 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).
I'm not even sure what point you're trying to make here - that sometimes your preferred method is even more shit, and so you sometimes have to fall back to the one I default to? Who said anything about rewriting all programs for the terminal? Why would you do that? I already specifically said that "We do also use our graphical environment". Who said terminology is "trying to be a graphical app"?
> Yes, that's one of the things that I feel so spooky with that approach.
I'm not sure why you insist on making this so complicated or acting like it's scary somehow.
> It cannot work...
I've already told you that it does, in fact, work. Very very well. Maybe you should try it out so that you have some idea what you're talking about before you start telling me that things I do all the time "cannot work".
> Maybe for a handful of persons that constantly search for jpeg/png/mpeg files, in bulk mode, and need quick previews.
Did I say I use it "constantly"? I don't recall saying that. I use it as often as I need to. Because I can. Because it's there.
And it's a better experience in literally every way imaginable than firing up fucking dolphin and waiting for three ice ages and also an image/video viewer.
> It took almost an entire second. Or, another way you could say that would be "longer than it takes terminology to pop up a preview".
Yes. But how often do I spontaneously need previews of something? And how often is it then enough to get what this EFL lib can give me? In terms of format support, and in terms of functionality (e.g. can it show me the TOC of some pdf and allows me to navigate to some chapter?). Well, there seem to be some use cases... Obviously... I still cannot imagine how they look like, though.
> Well then either dolphin is by some miracle orders of magnitude faster than any file browser I have ever seen [...] Or [...] Or [...]
Maybe a combination of all of them... :) I don't know. The performance was always good enough to be much faster than I am.
My point was also: Before we now start to shoehorn graphical functionality into terminals, which we then only can use in graphical environments anyways, shouldn't we better just improve the graphical apps? There is no inherent reason for them to be any worse than your terminal apps (that are eventually hosted by just an ordinary graphical app).
About your list what Dolphin needs to do but terminal apps don't: Yes, sure. A lot is going on. In the background. I don't have to wait for it to generate thumbnails. It's not bash, which completely freezes then, e.g. when the network drive has a slow day, and I blatantly pressed Tab. Same for most of the other things you wrote. Win 98 did it as well (not the mimetype-detection, though). Even that was okay for most practical purposes. But look what machines we had back then! I've just navigated to /bin. At least around 3000 files. I would avoid having so many files in a single directory. For organizational purposes. Anyways. I instantly see it listing the files, and it felt finished instantly, and i was able to scroll around. No waiting time that would have blocked me.
BTW: All the thumbnail stuff is done on demand, as soon as you scroll down.
And finally: You can just turn it off! ;)
Counting the files, and determining which application is associated with a file type, are quite cheap operations. That's nothing, even compared to the very bare directory enumeration, right?
> No, it will not do that when I press tab.
Yes, well, sure... But that's not because a terminal is the superior environment (how could it be if you just emulate it with the "bad" one). If all that 'modern' (win98) Dolphin magic is too slow, there are probably more lightweight alternatives that are still graphical. I still don't see the point in patching graphical features into something text-based, which you then need to run in an actual graphical environment anyways, instead of just getting the graphical apps right.
>> I really don't see why terminal applications should be fundamentally faster than graphical applications in that regard
> ..........um, what?
Yeah, I'm assuming terminal applications that you run in your graphical terminal emulator. But that's obvious, right? If I would be wrong, then, of course, let's today start porting all our graphical apps into that E terminal thing. Maybe we then can get even faster by putting that again inside an E terminal. And again, and again...
A terminal application that you run in an emulator, which is just some graphical application, cannot fundamentally be faster than just directly running graphical applications without that indirection, right? That would make no sense at all...
> Seems to me like maybe you've never used a terminal program?
I was a child when I got regular access to my first PC... It ran MS-DOS 5. I played more with command.com than with the actual games installed, I suspect... My friends played NES, while I tried to hack custom program launchers as .bat files. :-/ Even they made use of the 16 colors (or 8?!) you could have, though. ^^ No idea where I found out how to do that, a decade before my first internet connection... But at least as much I loved my first Windows 3.0 installation! Sure, command.com was probably quicker than Windows File Manager, strictly speaking. It was never so bad that I opened a terminal window for file management, though.
> GUIs and GUI toolkits, on the other hand, are huge complex libraries
Technically, I can just agree again. But all that happens so quickly nowadays, in terms of wall clock time, that I really doubt the practical relevance. A "hello world" app in either Qt or GTK starts instantly on my machine. No waiting time that a human being could recognize. I press Enter, and it's there while I'm releasing the Enter key.
> And before you start taking into account that a lot of gui software is just poorly written trash seemingly written by morons under the CADT model (Hi, gnome!).
We can definitely agree here!!! :)
> I don't know what else to say. Go talk to every single GUI application author ever, I guess?
Better than reinventing a whole new kind of terminal applications which aren't actual terminal applications, but only work in an environment emulated by the very thing they want to replace. The same morons will come and screw up with all kinds of things there again, once that'd get more momentum. But now, since they also have to maintain EFL plugins or other graphical-to-terminal translations for their apps and file formats, they will even screw up heavier.
>> If you know the file name starts with "cat_s", then you can also find it this way in Dolphin.
> Sure. After you've waited almost an entire second, [...]
On an average day, I open a Dolphin window maybe once or twice... Often not even once (e.g. I just open my IDE and stay there, or the browser, or a game, you name it). You don't need a new one for every operation! I mean, if your workflow is seriously superior, then be happy that EFL and all that exists and supports all the file formats that you want to preview, and be happy that it provides all the features you need. I'm happy with you then. I have the feeling that it's a very special workflow for a very special task at best, though.
> I'm not even sure what point you're trying to make here - that sometimes your preferred method is even more shit, and so you sometimes have to fall back to the one I default to?
If you want to understand it that way, that's fine... And you type "xdg-open" while I can just press Enter (or double-click ^^). Why should I constantly want previews of something, so often that I'd care about a second of waiting time once in preparation, so much that I should avoid Dolphin, which just gives me these previews without any user intervention needed, just because it take a second to start?! Couldn't you just leave it open then?! Yeah, you'll definitely have some reasons...
> I already specifically said that "We do also use our graphical environment".
Sure you do! I know! Terminology is one of them. That's exactly the point. For an actual (virtual)terminal, it would at least remotely make some sense to me. Because there it's not an option to just use a common X11/Wayland image viewer.
> Who said terminology is "trying to be a graphical app"?
No; it already is of course. It's trying to make terminal apps graphical, right? And all that technical complexity is just there because you don't have to move your eyes to another window (there are very basic image viewers without any features; I've no idea why they should be slower than the EFL previewers - and if you want a video thumbnail, just write an ffmpeg oneliner as an alias). Again, I'm happy for you that it's available, but I'd definitely dislike to see all that arriving in major desktop environments. And I'm still optimistic in that regard. If it does, at least there might be ways to integrate the Dolphin thumbnailers. :)
> I'm not sure why you insist on making this so complicated or acting like it's scary somehow.
In some way that's exactly what I'm wondering about when people have terminal-centric workflows in an environment that could actually just do graphics. In particular when they then start to patch graphics support inside their terminals.
> But how often do I spontaneously need previews of something?
I don't know. Or care. I use it a bunch. Maybe you're conditioned not to do that because every time you do it, it takes you 10+ seconds rather then 1. Who knows? Who cares?
> can it show me the TOC of some pdf and allows me to navigate to some chapter?
I've already responded to this spurious scenario. Go read my previous responses.
> Well, there seem to be some use cases... Obviously...
Ooh, what a great concession.
> I still cannot imagine how they look like, though.
Could that be because you haven't tried it and don't understand what you're talking about?
> The performance was always good enough to be much faster than I am.
So in other words, you are slow.
> Before we now start to shoehorn graphical functionality into terminals, which we then only can use in graphical environments anyways,
Who shoehorned what? Where? You haven't read the specs for how it works, so you don't know what you're talking about. Still.
> shouldn't we better just improve the graphical apps?
So your suggestion is to add a terminal to every gui program in existence? I could point out how that's objectively worse in about a thousand ways, but instead I think I'll just let the absurdity of your entire premise sit.
> There is no inherent reason for them to be any worse than your terminal apps (that are eventually hosted by just an ordinary graphical app).
I've already explained, in great detail, that there is indeed an inherent reason why they're worse than terminal applications. Maybe you should consider reading the thing you're responding to.
> About your list what Dolphin needs to do but terminal apps don't: Yes, sure. A lot is going on. In the background. I don't have to wait for it to generate thumbnails.
You do if you want to see them
> It's not bash, which completely freezes then, e.g. when the network drive has a slow day, and I blatantly pressed Tab.
Dolphin does exactly nothing for exactly the same length of time (actually longer, due to all the extra shit it does) in this scenario.
> At least around 3000 files
So a tiny, trivial list of binaries then. That's about 40% the size of the directory where my binaries live.
> I would avoid having so many files in a single directory.
So in other words, dolphin, like every other graphical file manager, is slow as fuck working with directories with lots of files (where "lots" is a colloquial term for "really not very many at all"), and you adjust your workflow to compensate for how dog-slow your shitty gui file manager is.
My music directory contains over 80,000 files. Try opening that in dolphin, you'll learn the meaning of "slow".
> I instantly see it listing the files, and it felt finished instantly, and i was able to scroll around. No waiting time that would have blocked me.
No, you don't "instantly" see it listing files, because it has to open a window first, which you've already said takes ~800ms. You're just not aware of the wait time because you've conditioned yourself to accept constant context switches and thumb-twiddling in your slow DE.
But just as an experiment, why don't you "instantly" select the file named zcat.
> BTW: All the thumbnail stuff is done on demand, as soon as you scroll down.
So in other words: "in advance", while you wait, before you can see them.
> And finally: You can just turn it off! ;)
Dolphin has the ability to disable it's "double click to open file in the preferred editor" functionality, to avoid the need to determine mimetypes, does it?
> Counting the files, and determining which application is associated with a file type, are quite cheap operations
Someone has never looked at a directory with subdirectories containing 100K files or more in a graphical file manager.
Someone has never looked at his disk usage while that happens.
> But that's not because a terminal is the superior environment (how could it be if you just emulate it with the "bad" one).
Actually that's exactly why - terminals are the superior environment.
"emulate it with the 'bad' one?" What are you talking about? Who said guis were bad? When?
> If all that 'modern' (win98) Dolphin magic is too slow, there are probably more lightweight alternatives that are still graphical.
Such as?
I look forward to seeing your list of graphical file managers that are faster (or even within an order of magnitude as fast as) ls. Please be exhaustive, I want to try them all!
> I still don't see the point in patching graphical features into something text-based, which you then need to run in an actual graphical environment
No, you don't see the point. We've already established this.
...Is your complaint here that you can't run these graphical terminal programs without having some sort of graphical environment running? i.e that it won't run on an actual text-only dumb terminal?
When was the last time you used a terminal in an environment where you didn't have hardware for graphics support?
And let's say you're one of the seven people on earth who does use a text-only dumb terminal daily: When did anybody advocate phasing out CLI software that doesn't use graphics features? How do you know that a bunch of this software with graphics support can't fall back to non-graphical options in non-graphical terminals? (hint: many/most can)
By the way, a bunch of actual "text-only" dumb terminals have had graphics support since the 1980s [1], and konsole has supported graphics for at least 5 years [2], and since 2022 it has supported the kitty graphics protocol [3]. Of course I'm sure you knew none of this because it took me >0 seconds of searching to look up the konsole support. I'm also sure this means konsole is broken and doesn't work, and the graphics support that's been there without your knowledge for half a decade has probably caused a bunch of bugs that you've been having trouble with, so I guess you should probably change terminals. Maybe to xterm... oh wait that's had sixel support for 6 years [4].
Here you go: phosphor [5]. I'm 90% sure this doesn't support graphics. And As a bonus, you'll be thrilled to know that it also doesn't support colour!
> let's today start porting all our graphical apps into that E terminal thing
I don't understand where you've gotten this idiotic idea that nobody advocated and which I have repeatedly stated that nobody advocated from. Constructed strawman, much?
> A terminal application that you run in an emulator, which is just some graphical application, cannot fundamentally be faster than just directly running graphical applications without that indirection, right? That would make no sense at all...
I've already explained how it is indeed far far more efficient and faster. If you think it doesn't make sense, that's because you don't understand. I'd suggest doing some reading. For example of my previous explanation.
> I played more with command.com than with the actual games installed, I suspect... My friends played NES, while I tried to hack custom program launchers as .bat files
Ooh I'm so impressed! By that time, I was already editing command.com itself.
editing .bat files, huh? And then you thought windows 3 was good and never went back to a terminal.
So, another way to say it would be that you don't know how to use a modern unix terminal - which is what I mean when I say "terminal", because dos was always a toy OS.
> Even they made use of the 16 colors (or 8?!)
...and you don't even know what your DOS machine was capable of or what it could and couldn't do. This depended on a few factors, not least what type of graphics card (if any) you had and whether you were using a colour screen or an amber/green one.
> Sure, command.com was probably quicker than Windows File Manager, strictly speaking
So, in other words: text-based software is faster than graphical software.
> But all that happens so quickly nowadays, in terms of wall clock time, that I really doubt the practical relevance.
...because you've conditioned yourself not to notice the time you spend waiting around for your shit software to initialise.
> A "hello world" app in either Qt or GTK starts instantly on my machine. No waiting time that a human being could recognize. I press Enter, and it's there while I'm releasing the Enter key.
1. It absolutely does not start instantly. Go write a "hello world" in qt/gtk that exits instantly as soon as it's displayed its main window. Then time how long it takes. It's going to be >0. Or, in other words, "not instant"
2. This is a false and contrived example - a "hello world" program is intentionally extremely minimal and explicitly does not involve initialising a complex interface - it's literally a single control - how many "hello world" programs do you use on a daily basis for productivity? Please link me to a "hello world" program that can preview video for me, and that starts up instantly.
This is empirically, demonstrably untrue, because the "launch application" action does not begin until the "key release" event has fired. Which is something you'd know if you understood how your interface works.
> And before you start taking into account that a lot of gui software is just poorly written trash seemingly written by morons under the CADT model (Hi, gnome!).
We can definitely agree here!!! :)
*cough* Whoosh!
> Better than reinventing a whole new kind of terminal applications which aren't actual terminal applications,
OMG you're totally right! Let's just stay using 1970s tech and never improve anything! Just remember to never ever update your browser!
Why are they not actual terminal applications? What terminal functionality do they lack? Please provide excruciating technical detail on this subject about which you know nothing.
> but only work in an environment emulated by the very thing they want to replace.
I know right! It's so rare and exotic for people in 2026 to have hardware capable of graphics! And in colour, too! Such an onerous requirement! And also it's obviously totally impossible to ever detect whether a program is running in an environment where graphics are supported and fall back to a text-only mode! Oh noes! What will we do when they force graphical output into the kernel with no option to disable it?!?!
For the umpteenth time, who said anything about replacing guis? I have repeatedly stated that they have their uses and are the best option for a bunch of things.
> The same morons will come and screw up with all kinds of things there again, once that'd get more momentum. But now, since they also have to maintain EFL plugins or other graphical-to-terminal translations for their apps and file formats, they will even screw up heavier.
Why are these people writing gui programs that run in a terminal in your contrived fantasy scenario? Again, for the 50th time, who suggested this or advocated for it? When?
EFL plugins? Graphical to terminal translations? What are you talking about? It's almost like you don't understand the technology and have invented some fantasy architecture for all this stuff which is nothing like the actual architecture that exists and has been described here and elsewhere.
> On an average day, I open a Dolphin window maybe once or twice... Often not even once (e.g. I just open my IDE and stay there, or the browser, or a game, you name it). You don't need a new one for every operation!
Right, but we're not talking about an average day. We're talking about a specific scenario where you have described a specific workflow which you are claiming is somehow superior to the one which I have outlined, and which is demonstrably superior by several metrics which I and others care about. I don't actually give a fuck what you do on an average day, or how often you start dolphin. You're the one who claimed that you would start dolphin, and then another program like vlc, to do what I can do without starting anything. If you're now claiming that you don't actually need to start dolphin, then why did you waste my time by advocating that workflow?
> if your workflow is seriously superior, then be happy that EFL and all that exists and supports all the file formats that you want to preview, and be happy that it provides all the features you need. I'm happy with you then. I have the feeling that it's a very special workflow for a very special task at best, though.
Your "feeling" about my workflow is worth less than nothing. Because, yet again, you don't know what my workflow is. Because you don't understand it. Because you haven't bothered to try to understand it. And that's fine for you, if you prefer your worse windows-like UI then go and enjoy writing trash in visual studio. I'm happy for you. But don't think that that means you're somehow qualified to talk about terminals and their pros and cons.
> And you type "xdg-open" while I can just press Enter (or double-click ^^)
Well, it's actually only 'xo' for me, I set up an alias a long time ago. I said "xdg-open" because not everybody has that alias.
> Why should I constantly want previews of something, so often that I'd care about a second of waiting time once in preparation,
As I've said elsewhere, you don't understand the point and you're fixated on the speed thing. Because you don't understand the point.
> Couldn't you just leave it open then?! Yeah, you'll definitely have some reasons...
I have a bunch of reasons.
Have you ever left dolphin open for 160+ hours in a directory containing 80,000 mp3s? How'd that work out for you? How did it handle it? How much ram did it use? What was your system load like?
> Sure you do! I know! Terminology is one of them. That's exactly the point.
...that you don't understand my point and the problems I have with the flow you suggest?
> For an actual (virtual)terminal, it would at least remotely make some sense to me. Because there it's not an option to just use a common X11/Wayland image viewer.
Again, do you mean "running outside of a graphical environment"? That oh-so-common situation that so many of us deal with on a daily basis in 2026?
Let's say you do mean that: You still have no clue what you're talking about. For instance it's trivially easy to view an image or play a video with no graphical environment running*, as long as you have hardware that can do a framebuffer. Like, for example, every graphics card made in the last 30+ years. And if you have that hardware, then you can run terminology on it, too. As raster already mentioned and you failed to understand.
* (one of my machines is indeed set up to play video 24x7 and does not run a windowing system or graphical environment at all)
> It's trying to make terminal apps graphical, right?
Terminology doesn't give a shit what software you run on it. It's non-sentient, you see. It doesn't care either way. It's definitely not trying to convert terminal programs into gui programs, or the other way around, like you seem to think because you haven't bothered to understand what I'm talking about.
If you think it might be, you might want to look into that. Ascribing motivations to inanimate objects seems like it might not be healthy.
> And all that technical complexity is just there
All what technical complexity? Where is the complexity, exactly? Please be precise and detailed.
You don't know. Because you don't understand how it works, and you've ignored the people who tried to tell you.
> because you don't have to move your eyes to another window
You. Do. Not. Understand. My. Point.
Please try re-reading my other responses and this time try to comprehend what I'm saying if you'd like to continue this discussion.
> there are very basic image viewers without any features
...No features at all, huh? Please provide examples.
So then, you're saying they don't open up a window? They don't decode jpeg?
I question the usefulness of this software. But I can't wait to see your list.
> I've no idea why they should be slower than the EFL previewers
Then I'd suggest you re-read and this time try to comprehend my detailed explanation in a previous message explaining how they are and always will be fundamentally slower and cannot help but to be so due to how software and physics work.
> I'd definitely dislike to see all that arriving in major desktop environments. And I'm still optimistic in that regard
Oh noes! It's already been in KDE and konsole for more than 5 years! I'm so so so so so so so so so so so sad for you! How this must ruin your day and impact very negatively on everything you do in daily life! And the bugs! All those bugs that the shoddy implementation and extreme technical complexity have caused for you! Do you need a hug?
> If it does, at least there might be ways to integrate the Dolphin thumbnailers. :)
What. the fuck. are you talking about???
Are you saying that you wish lsix[6] existed? And that it worked in konsole? And that you wish you could use it right now with literally 3 seconds of effort to install it? Are you saying that, after typing a hundred thousand words railing against the inclusion of any graphical features in any terminal ever?
> In some way that's exactly what I'm wondering about when people have terminal-centric workflows in an environment that could actually just do graphics.
Some people value being able to get stuff efficiently. Apparently, you're not one of them.
I love how, after having the massive complexity of gui applications explained to you, you just brush that off and say "just do graphics". That's pretty good trolling right there.
> In particular when they then start to patch graphics support inside their terminals
For what I really really really really hope is the final time: if you bothered to try to understand the point which I have made to you repeatedly and in several different ways, then you might understand. But that would require more than zero effort on your part, so it's not going to happen.
Oooof... Okay, but quicker, bcs I need to leave at some point in time. I'll skip most of the parts where we are in a loop anyways.
> Could that be because you haven't tried it and don't understand what you're talking about?
Admittedly, yes, I'm still trying to understand that.
> So your suggestion is to add a terminal to every gui program in existence?
Interesting idea in some way, no? Not each one individually, please. That would be equally bonkers. But in the end, looking at the final result, that sounds a bit like how I'd interpret your hybrid approach.
>> About your list what Dolphin needs to do but terminal apps don't: Yes, sure. A lot is going on. In the background. I don't have to wait for it to generate thumbnails.
> You do if you want to see them
Sure, but then you are comparing apples and oranges. You compared it to pressing Tab.
>> I would avoid having so many files in a single directory. For organizational purposes.
> So in other words, dolphin, [...] fuck [...] My music directory [...]
You are doing everything in that very quick way, right? "For organizational purposes."
I just gave it a try; Dolphin has no trouble at all with 100000 files in a directory. Yes, it took a second longer. Whatever you'd do with these files will be by a few magnitudes slower.
> But just as an experiment, why don't you "instantly" select the file named zcat.
Yes, did so. And now?
> Someone has never looked at a directory with subdirectories containing 100K files or more in a graphical file manager.
It only does that (with subdirectories) if you explicitly ask it to do so, by opening some Properties dialog. You are here definitely starting to make things up.
> Such as?
Nono, I'm fine with Dolphin. :-P
> ...Is your complaint here that you can't run these graphical terminal programs without having some sort of graphical environment running?
Why else should sane developers start to spend any serious efforts into applications based on this ancient tech stack? They would (obviously) of course just make a graphical application if it's graphical.
> When was the last time you used a terminal in an environment where you didn't have hardware for graphics support?
Welllll, not sooo often, fortunately. Virtually never, and when I do, I definitely don't need previews of cat pictures. Most of the times I just use graphical applications. Even some Java based ones! Boy, you wouldn't guess what they all do while loading, and how long that takes. It's actually wild. But I'm not using my PC for starting applications, right. I do that once. And then they run. ;)
> By the way, a bunch of actual "text-only" dumb terminals have had graphics support since the 1980s [1], and konsole has supported graphics for at least 5 years [2], and since 2022 it has supported the kitty graphics protocol [3]. Of course I'm sure you knew none of this
No. I'm sure it can do another 100 things that I'll never use. If you're in such a hurry all the time, you'll understand that I don't spend a lot of time in these things.
> [...] the graphics support that's been there without your knowledge for half a decade has probably caused a bunch of bugs that you've been having trouble with [...]
Read again what I wrote (hint: it was not equal to "sixel support will definitely break a terminal")! But, yeah, we'll never know. To what should we compare it with? The good news here for me is: The danger is already mostly over then, and if there were issues, at least big ones, they're then already sorted...
Also, as you can maybe already infer from our conversation so far: I don't use Konsole that often. Slightly more often I use the terminal integrated in Jetbrains IDE. That is even worse, unfortunately. Although without Sixel support. ^^
> Ooh I'm so impressed!
That's nice to hear. I just tried to answer your question, though.
> And then you thought windows 3 was good and never went back to a terminal.
No no, that narration would skip quite some decades and would make me sound smarter than I actually am. Sure, in the first Linux years, you are definitely vulnerable to the terminal cult, and you assume that you talk to very very smart persons instead of just priests, and you believe them a lot, before you understand that a lot of it is just an odd cult. And in a lot of cases (even today) you just sometimes have to use a terminal; particularly on Linux.
But really not for image thumbnails, and neither for management of my music collection. That actually never happened.
>> Even they made use of the 16 colors (or 8?!)
> ...and you don't even know what your DOS machine was capable of or what it could and couldn't do.
No. That was when I was in elementary school. Just barely. I was happy when I was able to collect these things in other .bat files and were clever enough to combine these findings to something that somehow worked.
> This depended on a few factors, not least what type of graphics card (if any) you had and whether you were using a colour screen or an amber/green one.
Without colour screen/card, there would be no question whether it was 8 or 16 colors, right? It would then be 2.
> [...] 2. This is a false and contrived example - a "hello world" program is intentionally extremely minimal [...]
If you need more complexity (e.g. for layout of more complex content), your terminal app also has to deal with that in some way.
> This is empirically, demonstrably untrue, because the "launch application" action does not begin until the "key release" event has fired. Which is something you'd know if you understood how your interface works.
No, not at all. What are you "demonstrating" here. I've never seen the behavior you describe on ANY platform tbh. Also not in any terminal.
>> there are very basic image viewers without any features
> ...No features at all, huh? Please provide examples.
I'll not do your web search for you. For some reason, I've imagemagick installed here, which seems to ship a very basic image viewer. It starts (at least for the image I've tried with) as instantly as the hello world apps.
And just for the case you still don't understand: I mean "instantly" in a practical meaning. You don't have to explain me once more that it can't be exactly 0 sec in a scientific meaning. ;)
I'll skip all the parts where you don't understand my point, or where you're just saying nonsense, and jump right to the heart of the thing (other than "you don't get it"):
> I mean "instantly" in a practical meaning. You don't have to explain me once more that it can't be exactly 0 sec in a scientific meaning
So, in other words, when you say "instantly", you mean "not instantly".
That's a pretty great metaphor for your entire line of argumentation.
I would respond to the rest - there's a million things there that I'd love to dissect, e.g the admission that you haven't even tried the thing you're so against - but why would I bother? When you say things, you mean things that aren't the thing you said. Case closed.
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.
Awesome! I might try it again, tbh I have KDE on one computer but I don't use it much as my muscle memory is very gnomy and I haven't taken the time to tried to switch back in long term and I admit until hearing about that very little strong incentive to do so.
I know that people never want to hear such remarks... At least I never want... But I risk being the idiot anyways: KDE/Plasma doesn't crash here so often. I've seen it actually happening in the last years. Unfortunately!!!! Maybe two or three times... And then, it just restarted in a matter of a second. It did not affect anything. No running apps crashed. Just the task bar and the desktop went away for a second.
How long have you tried, and how long are you now trying Gnome?
That experience was almost 20years ago, between 2006 and 2009 (I had to check linkedin because I only remember which employer I was working for) so based on wikipedia it was still KDE 4 wich was very unstable.
I tried a few times KDE 5 over the years out of curiosity then more recently KDE6. I have it on one computer but I rarely use it as it is the gaming machine and I very rarely play videogames. The thing is I got so used to the ergonomy and shortcuts of gnome and i3/sway that whenever I use KDE I need either a lot of time to get used to the default keyboard shortcuts and layout and/or I need to take time to modify/configure it. But since I have been fairly happy with gnome and sway I don't really have much insentive to switch again. No hater really.
KDE 4 was indeed a huge mess... All 4.x version. Even if every changelog had the sound of "Now the glitches are fixed; you can now start using it". It never was...
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.
KDE1 had some very nice themes! I remember using one that drew inspiration from the visuals of Bryce on the Mac. Dark mode theme - and animated window titles which would scroll gently if the window title was too long to fit.
Yeah, compared to Win 95 at least, it looked interesting in a positive way...
Problem was: Whenever you clicked on something, some message box appeared, with some one-line error message that contained the word "unknown" or "unexpected"... :)
With KDE1 is was most likely "Not yet implemented" :-)
I never used KDE2, KDE3.x was rock solid though. It wasn't until KDE4 where things took a massive nosedive and everything was crashing if you looked at it wrong - something that lasted until most of KDE5's lifetime, though by late KDE5 and now KDE6 it seems to be fine.
Well, "fine", for some reason Wayland sessions crash and restart the entire session whenever i press any key (doesn't happen with Xorg sessions), so i guess there are still some minor bugs to be fixed :-P
No no, it always tried to do something, with a lot of self-confidence, but then constantly failed.
I can spontaneously remember k3b (CD burning tool) constantly failing because the CLI tools behind it (cdrecord, mkisofs, ...) replied in some way that k3b hasn't expected (e.g. because the locale was non-english, or the CLI tool devs changed the strings slightly, or there was a pointless warning text that k3b did not expect, ..., ...).
Admittedly, k3b was later... KDE3 era? But this is exactly how KDE1 felt... And in very bad days it still does today... You click on something, the developers assumed that the file manager can deal with it, but instead you just see the file manager saying "Unknown protocol" or similar. All the problems that arise when your system is very modular, but every module is a separate hobby project with no coordination.
I definitely loved KDE3 and was sooo excited about KDE4. And it was a pretty terrible disappointment. Nowadays I'm again fine with Plasma. Since mid KDE5 days.
> for some reason Wayland sessions crash
That's definitely a mess, too. I'm not fundamentally against Wayland. I'm using it right now. Even if it is still slightly broken today (yes, Wayland is a protocol; here I mean: the biggest implementations). But the entire Wayland story is very very sad. It took ages before it was at least usable for five minutes. And then everywhere the X11 support already gets disabled, while Wayland is still in a somewhat immature state. Sure, I somewhat understand what the devs say, and I can't force them anyways. But it's really not a success story for the Linux desktop.
> Wasn't Enlightenment something that just looked good in screenshots
Yea, this was my memory of it, too. I remember installing it, and making a theme that looked all "elite" and cool. I added an anime character desktop background, as was required at the time. Took a few screenshots, basked in how cool I was, and then just switched back to whatever I was using before (I think Gnome).
It worked, at least 25+ years ago when I last used it; early versions weren't a model of stability, but that wasn't nearly as important as an X server or a Wayland compositor not crashing, since you can simply restart an X window manager when it crashes (from a terminal window, virtual terminal, automatically from a script, etc.).
Lots of teenagers were using it back then judging by the old themes, 95% of which suck. As an adult I made a simple, attractive theme, enabled only the most basic and useful eye candy, and just use it. None of the other alternatives interest me, and I've tried them all.
In my personal experience - as far as I can remember - it always stopped to be good looking when it wasn't a screenshot anymore but a running process on my machine. In motion, all the eye-candy became ugly and foolish and visibly hobbyist, and as soon as I began using some applications outside of the E-ecosystem, the last sparks of fanciness went away anyways.
But that was... idk... E16 or so?! I really cannot remember. Maybe it had better times earlier, or maybe (surely) people are different and have different criteria for choosing such things.
Was E13 before they started trying to be a klingon starship UI?
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.
Yeah that was the reason for me too, in order to get the distro CD ROMS I had to mail $10 to some random address and wait 4 weeks for them to be mailed back!
I tell people you used to have to post a cheque when you bought stuff online and they just look at me like I’m nuts. It was basically just mail order, but on the web.
Modelines are one of those skills that I thought would get obsoleted, but in fact taught me the mechanics of video timing that I was able to use in unrelated contexts. Such as years later where I was asked to fix a driver for a point of sale system which had a 1024x200 (or thereabouts, extremely wide nonstandard ratio) secondary screen.
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.
Well, unless you decided to use GNOME, then you get rugpulled by a bunch of people that think they know better than user what user wants and actively ignore any feedback
As far as I can tell, every major version of GTK should be thought of as an entirely separate project, and nothing in GTK 4 made GTK 3 or GTK 2 harder to use.
what does make GTK2 harder to use is that it is not supported anymore. you can't build or run GKT2 based apps on new systems without building the GTK2 libraries yourself.
Please link me to the python3 gtk2 library so that I can migrate all my python2 gtk2 software to python3 without rewriting the entire UI. Thanks in advance!
There are forks though. The only version i don't think that has a fork is GNOME 1 but... the code is out there (and there is an actively maintained GTK1-based toolkit that was posted here not too long ago, though you may need to make some modifications to the GNOME 1 code to work with it as IIRC it isn't backwards compatible).
People made CDE to work on modern systems and IIRC CDE wasn't even compatible with Linux when the code was first released.
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 still remember how cool I thought raster was with his vaio and everything. This was the future! Transparent eterms and tasteful backgrounds everywhere.
Wow, I think I remember that talk, too. And I remember thinking, "why would anyone want to run a video inside a terminal?!" I still don't want to do that, but it was cool that enabling that feature only required a few lines of code, since EFL(?) already supported it, was already linked in, and the code to start it was minimal.
Certainly not everywhere. I definitely remember plenty of tasteless ones, some deliberately so and others just cases of other people's taste differing from mine!
I think the author meant that she was just trying to work on her slides, and was hoping that by quitting/restarting, the bug would temporarily go away, so she could continue working on what she actually wanted to work on, and not go down a debugging rabbit hole.
Certainly the determinism made it easier to fix, but the determinism also meant that she had to stop what she was doing and fix it right now, which is... "sadly".
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.
To put a finer point on it: running bleeding edge does not just now have implications of a greater attack surface, it always has had such implications.
It's just that a tiny fragment of people are suddenly becoming aware of this fact (the masses always remain clueless), whereas others have known it for some time. These people are referred to as "crazy tinfoil hat nutters."
Eh, there are two competing drives occurring here.
Back in the day before security was the biggest driver of updating software most people stayed a version or two back to ensure they weren't getting the last corruption bug of the day or whatever other insect was coded in.
But modern internet connected systems have pushed customers into more of an issue. It switched from, stay a version behind to see what bugs are there to, if you don't update now you're going to get hacked.
Enlightenment always had a pretty weird value proposition. In the very beginning, there was "fvwm-xpm" and early "E" prototypes. They were graphically crazy with a heavy focus on shaped Windows. There's still nothing quite like that weird steampunk/Brazil-ish theme they had. Probably for a reason.
Then they went both visually rather tame and scope-creepy (own graphical libraries etc.). At the beginning I was hoping that we'd get some kind of Amiga-influenced design sensibilities on X (basically a more "artsy" MUI), but that never manifested.
Yeah, I saw that back in the day, and it's great, but that was too faithful. I liked the eye candy of Enlightenment, but with a nod to the nostalgia...
There is still a lot of things I miss from the Amiga, but I'm acutely aware that a lot of what I wish for are based on rather rose-tinted memories.
> There is still a lot of things I miss from the Amiga, but I'm acutely aware that a lot of what I wish for are based on rather rose-tinted memories.
Yes! I have often wondered what it would be like trying to daily drive an OS4 amiga for modern stuff. I suspect it probably wouldn't be super awesome, mainly due to lack of software for modern things. But I'd really like to try it - if only I could run OS4 on an x86 PC*. I would definitely try it out.
(* yes, I know I can run it in an emulator, but that's not the same)
One thing I'd particularly love to see is something like ARexx adopted in modern OS's and software. It would be super-useful to have most applications expose something like an arexx port, would make a lot of cool things very easy to do.
The odd thing is that a lot of Linux software does have Dbus support, but it somehow feels like the barrier is a lot higher and buy-in a lot worse. Just throwing together ad-hoc scripts w/dbus feels like it has a higher barrier.
Datatypes is another obvious one - present-day Amiga's can support modern image formats in apps that haven't seen updates for 25+ years...
I recently added hacky assigns to my (very hacky) little shell, as an experiment, as it's one of those features that feels like it's "just" link symlinks setting an environment variable to a path, but as it turns out it really is a lot more ergonomic (to me at least).
I've settled on a tiling wm w/one floating desktop to sort-of emulate how I typically used my Amiga screens, and that I like.
> if only I could run OS4 on an x86 PC*. I would definitely try it out.
AROS would be the closest thing. E.g. AROS One (a distribution)
It's been many years since I spent any time on AROS, so I don't know what it's like at the moment. Back then I could boot the Linux-hosted version of AROS with a startup-sequence that booted straight into FrexxEd (editor w/extensive AREXX support co-written by the author of Curl) faster than a default install of Emacs would start on the same machine.
You make a good point about dbus. It is sooooort of similar if you squint. But I think both your points are correct. I feel like the buy-in factor is probably the big one - I think if there was lots of buy in the tooling would probably get easier.
How did I not think of datatypes? Yeah, omg they were do great. I'll never forget my amazement when I installed one (I think for jpeg) and now just everything supported jpeg.
I think IIRC beos did something similar to that.
Oh yeah I've seen AROS, but like you I haven't actually fired it up in a long time. The last time I did it was "Amiga Research Operating System".
I just noticed on their wikipedia:
there is also an ARM port for the Raspberry Pi series
That sounds like a good excuse to break out one of these pis I have sitting around!
I still install it and play with it for a bit every other year. I really appreciate that it's held true to its own core. Yes it works with Wayland now, but it's still using its e-foundation libraries. I still wish I had screenshots of my desktop from 1998/1999. Downloading cool software from Freshmeat, hitting up Slashdot (news for nerds... stuff that matters) to see what was going on. Kinda wish I was into IRC back then but I was more of an ICQ->AIM chatter. It's an era I wish we could have back.
AV Linux uses Enlightenment 0.27.1. The creator of that distribution also offers a version based on Moksha 0.4.2, the E17 fork mentioned elsewhere in this thread.
I was also a huge fan of WindowMaker. Simple, effective, stylish without getting in the way. Also allowed me to have a vertical taskbar, which I stuck with even on Windows until Win11 has taken that from me - because Mac is the arbiter of taste and everyone must copy it.
Win 11 has some niceties, however many of those could have been provided on Windows 10 as well, for example the security stuff like VBS and secured kernel were already available, even if disabled by default.
I still use Windowmaker in places like VNC desktops where GDM gets grumpy and breaks a lot of the functionality. It also works much better over X displays on high latency networks like the Internet, where it is using the X drawing primitives as intended instead of constantly doing client side rendering and blitting the results over.
Kind of similar story, eventually I ended up on GNOME, as I favoured Gtkmm over how KDE was at the time, but then GNOME 3.0 happened, and my travel netbook got migrated into Unity, and when it went away, XFCE.
Due to similar realisation, my main working devices became Window 7 with Virtual Box/VMWare Worstation, nowadays WSL.
> At the time I had no idea it resembled NeXTStep, but it was great.
I used (and still use) Window Maker for almost a decade before learning what NeXTSTEP actually was (i heard about the name occasionally but never looked into it), then for several years before even trying one. I remember having a heavy sense of uncanny valley because the thing in front of me looked almost exactly like what i was using for years but it behaved in very odd ways (and lacked most of the window management features i came to expect) :-P. It made me realize what people who were used to Mac OS X felt when they tried the various Aqua GNOME/KDE themes that were popular on Linux desktops some years ago.
And detractors of Emacs used to claim that it stood for "Eight Megabytes And Constant Swapping" meaning that even on a then-huge machine with eight megabytes of RAM Emacs would use up all the memory. Now it is a tiny program compared to things like Visual Studio Code.
one of the more interesting things to think about is the big push to rendering all window manager stuff through a gpu, because we were sure we needed drop shadows and geometry transforms for windows....
Now, what we actually do in a window manager could easily be done in software in realtime, just farmed out to some cpu core.
> because we were sure we needed drop shadows and geometry transforms for windows
As screens get larger, the amount of pixels you need to push to composite windows gets larger-squared. It makes sense to move the pixel pushing away from the CPU and more importantly away from CPU-RAM and on to a separate RAM bus.
The "single buffer with invalidation" model of Win16 (I cannot remember how it works in X) saves memory at the cost of more redraws. The composition model allows you to do things like drag window A over window B without forcing a repaint of window B every frame.
It also allows for better process isolation. I think in both Win16 and X11 you could just get a handle to the "root window" and draw wherever you wanted?
> The "single buffer with invalidation" model of Win16 (I cannot remember how it works in X)
Same way, they both come from Macintosh (which, if i remember the apocrypha correctly, was Bill Atkinson's idea based on what he thought Xerox Smalltalk was doing even if it turned out it wasn't working like that).
eh, there is nothing a gpu can do here within the concept of composition that a cpu could not also do.
the gpu simply has buffers that it compsits, the cpu can do that as well. with the benefit of less complexity leading to not needing to worry about driver crashes.
on sane architectures its all the same ram anyway
> eh, there is nothing a gpu can do here within the concept of composition that a cpu could not also do.
True, but which is more efficient?
> on sane architectures its all the same ram anyway
Opinions differ. The main benefit of splitting RAM is not having to share the bus. As I said, this lets you use the CPU for CPU things without having to spend precious DRAM bandwidth shovelling pixels.
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.
No kidding. Last time I used Enlightenment back in the late 90s, both KDE 1.x and GNOME 1.x were orders of magnitude more usable on my lowly Pentium MMX 166 with 16 MB of RAM.
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.
that was literally me... i stopped it because... well.. short version - chasing bug in efl that blurted out an invalid object stdout errors when http requests for the forecasts module failed - the module relies on a caching proxy service on e.org to get weather forecasts. i simulated it a bit brute-force by temporarily taking down apache :) it's back and bug is fixed in git. it's silent now not complaining about invalid objects.
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.
"Sadly, the hang was deterministic"
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.
I remember trying to use it and getting constant segfaults.
> 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.
The author is 21 (which I find incredibly impressive) and is using a DE that was written when they were a baby.
It _is_ lightweight in that context. I also love the fact that XaoS knowledge is useful in the context of "real software" programming!
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.
From her "Short CV"
"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
The author's name is Kamilla. She was born in 2004 (according to the article).
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.
For those who don't know, rasterman was the original creator of Enlightenment.
His last comment before today was in 2016. And he came on today just to comment.
Thanks for making Enlightenment! I really enjoyed it for the brief time I used it!
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.
This is just a demo right now - buttons surrounding the file view are for testing:
http://www.rasterman.com/files/efm-typebuf-ex.webm
This is just a demo right now - buttons surrounding the file view are for testing:
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.
I don't understand your arguments.
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.
the cost of launching a new process with a gui is not cheap. there's a lot of setup before you even get a window up ... when that process is already there (terminal) with all of that cost paid for it is actually provably cheaper in terms of cpu cycles, latency etc. to pop up an image/video in your terminal. and cheaper not by 1 or 2 ms... but by 100's ms or more. that new window is not cheap. you also have the visual disconnect - the window pops up somewhere else with your wm having no idea that that new window is related to the terminal you ran it from because there will be no transient_for hints set to say that. relying on process tree hunting to figure this out is a crapshoot at best and will probably give you more misses than hits. we can go down that rabbit hole if you want but trust me - it is measurably less overhead to pop it up in a terminal with a few dozen chars worth of escapes sent to the terminal to do it.
In terms of wall clock time, on my system, it costs nothing. I can start a "Hello World" application based on Qt or GTK, and the window is there while I'm still releasing the Enter key. Technically, sure, a lot of things happen... But it's not happening on a P-90 anymore... :) BTW: My machine wasn't particularly strong or expensive either, when I bought it 6 years ago. ;)
When I read (in your other reply) that you are trying "soften the boundaries between workflows and bring some features of of workflow into another", well, that probably sounds nice... I just get a headache tbh...
I'm sure it was fun and a big achievement to implement that. And there obviously is a fan-base for that. So where am I... :)
I just get a headache tbh
why?
it is effectively a keyboard driven GUI. you potentially get the full power of the commandline to do your actions without giving up a graphical view of your system.
i wrote in my own comment that i want to go even further and integrate a full terminal: https://news.ycombinator.com/item?id=47801068
ttyphoon on the other hand is a terminal project that approaches this from the other side, getting even more graphics and structured data support into the terminal: https://github.com/lmorg/ttyphoon
both have a similar goal: get away from the old limitations that terminals have but keep the power they offer.
Just quickly, because I have to leave:
I actually do somewhat like the paradigm, from a user perspective. If done well, why not, could be cool... If done very well, it could be very very cool...
But please let's not invent these new kinds of applications based on terminal tech. I still don't see why one would go this pointless detour, instead of just start as a graphical application, tech-wise.
let's not invent these new kinds of applications based on terminal tech
i agree with that. the terminal with its escape sequences needs to go away, it is old and limited. however the commandline will not go away. nor should we give up text based applications. both are too powerful for that.
so what we want is a modernization of the commandline. this is happening with alternative shells, but also with ttyphoon and other projects. and efm brings the power of the commandline to the gui directly. i'd like to see more projects like that.
i see a large spectrum here. some projects try small incremental changes (sixels for example, a wierd concept, and i ask myself why, but ok). others try to bring more powerful datastructures to the commandline. good, because those are terminal independent. on the GUI side there have been various attempts to send objects between applications already for decades. none of them achieved broad acceptance. there is a lot of potential still. a GUI for data pipes for example would be nice. there is one for the terminal. tmux is a terminal manager, it is gaining GUI support. doesn't get rid of the terminal, but modernizes it. small incremental steps. 10 years ago i would not even have believed that alternative shells would gain acceptance. but they are. half a dozen projects that break bash compatibility and are gaining popularity.
My terminal displays emojis just fine and they align just fine as far as I know. Have you considered trying software that isn't shit? Or filing a bug report containing more than zero detail on the issue?
This is actually extremely straightforward if you spend 5 minutes understanding how it works, particularly with regards to backwards compatibility with terminals that don't support it. Which are few - it's incredibly well-supported in almost all terminals. I don't know what you're talking about... ...and neither do you.Damn, your nose is going to get right out of joint if you ever learn about RGB terminal colours. Shhh, nobody tell him!
Indeed! Finally something we agree on!And people working to improve terminals with efforts like terminology and kitty are trying to do what they can to address some of these issues without breaking anything. Which is hard. It's really quite an admirable effort worthy of respect.
But first you'd need to understand what they're doing.
I have no doubt that there's lots that you haven't heard about Ooh, appeal to authority. I'm so impressed.Perhaps, as "a professional software developer", you should take the time to understand the tech that you're talking about. Doing so will help you form an informed opinion and will help you to avoid wasting everyone's time reading ignorant, uninformed, assumption-laden nonsense.
Excellent! So go back and try actually reading my previous posts. That'll help a lot with this. Excellent! So go and read the docs and form an actual opinion that isn't "I don't like the sound of this herp derp". I'm sure once it's not immediately obvious that you have no clue what you're talking about and have spent zero seconds attempting to understand the architecture, people will be happy to discuss your pull requests making all the revolutionary improvements that I'm sure you'll make. Then maybe you should try actually reading them Aah! And the penny drops! You don't know how to use the terminal and don't understand its benefits. So of course you don't understand the arguments I've repeatedly outlined for why this functionality is desirable. Ooh, appeal to authority #2. I'm so impressed! Meanwhile I've been using linux since last century.Enlighten me, then, o great software developer and 20-year Linux user: What does the graphics support in terminology / kitty break?
Maybe you should spend 5 minutes understanding how it works before you go making assumptions.
You. Do. Not. Understand. My. Point. Because you don't understand how I operate. Because you don't know how to use a terminal. Please explain, in excruciating detail, exactly how you plan to "trivially" prevent the need to load in the qt library to get VLC to start and show its qt interface. I look forward to reading your technical paper. I already provided you with hard timing data demonstrating that previewing videos in terminology is more than 90% faster than the way you'd do it. If you have something other than completely uninformed assumptions based on nothing at all to back up your claim that previewing in terminology is not faster, please present your data here.But as I've alluded to repeatedly and you've completely ignored, speed is actually not the primary issue. It's the context change. It's that "taking my hand off the keyboard" thing. Even more, it's the "staying in the same application" thing. And it's also more than all those factors. It's a similar phenomenon to how I can't really explain to you just exactly how pipes are amazing and one of the most incredibly powerful paradigms you could ever learn. I can't really explain it to you properly because IMO the only way that it will really click in your head is in the moment that you really actually understand pipes, and to do that you have to actually learn and work with pipes.
You're just fixated on the speed because you don't understand the cost of the context change because you don't understand how terminal people work, because you don't know how to use a terminal and think that switching contexts constantly and twiddling your thumbs while GUIs initialise is normal and fine. And that's fine, if you want to work like a windows user. You do you, and more power to you. Just stay the fuck away from making suggestions about how terminals should or shouldn't work.
I have already explained in excruciating detail some of the major reasons why they are. If you still don't understand, I'd suggest reading my previous responses where I explain that. Or, you know, doing some further reading to understand the technology you're talking about. Maybe you should spend 5 minutes reading and understanding the technology you're commenting about, so that you don't make wildly incorrect assumptions, and don't come off as totally ignorant and uninformed.Who translates what exactly into escape sequences that you think is more expensive than loading up the gtk/qt/wx widget libraries and instantiating a new window?
Without some detail of what you're talking about this is just a non sequitur. Terminology works fine with my keyboard, as has...let me think... every terminal I've used in the last 30+ years.Since we're doing non sequiturs, allow me to retort: Avatar 3 was shit.
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!
(1/2)
I'm sure the enlightenment folks will be happy to look at your patches for these features you want. I'm not sure how you plan to integrate blender, but you've been programming professionally since 20 years, so I'm sure you have a plan and understand in ways that I simply can't comprehend.Raster already pointed out, and you ignored, that actually it does support pdfs, and libreoffice already. Seems it just never occurred to me to try them. So you actually won't need to patch that in at all!
Do we? I don't. Maybe you can point me to the relevant lines of source code, where it's more than 3 lines. I'll look forward to seeing your link. No, it does both graphics and video with the same 3 lines of code. As has already been explained and you ignored and/or failed to understand. So, to summarise: you bring up an argument that it shouldn't be done due to code complexity, then when that is rebuked because the additional code complexity is very close to zero, just say "the code isn't even my primary concern at all", without elaborating any further to outline what your concern actually is. And to summarise the summary: you don't actually have any reasoning, you just don't like it because you don't like it. Then why do you seem to think that saying "herp derp, I don't understand therefore it's a cult" over and over is going to sound more reasonable to me at some point? Yep Maybe it'd help if you pulled your head out of your ass and actually read what I wrote. We're talking about previewing. I have a superior approach for previewing. Which leads me to re-state my previous question: Did I say "editing the thing" or "working with the thing"? I suspect it'll be much more complex than that, but you're a professional programmer since 20 years who has never looked at the code or even run the software, so you probably know better than I do.I'm sure the e folks will be happy to look at the patches you provide for this functionality you want.
I suspect there might be a bit of discussion about things like "is this desirable" and "does this break compatibility with existing things" because this is a bizarro thing that you've invented out of nowhere based on nothing anybody said anywhere ever. But I'm sure they'll be happy to discuss it once you submit a patch.
I look forward to seeing your patch that does this without breaking compatibility with ~50 years of legacy software. Again, EFL supports a lot of formats. Including ones I didn't even know about, like the pdf and libreoffice docs you wanted. I guess you didn't bother reading that before. So what's your point? How is it relevant that my terminal emulator runs on X? I'm not talking about the environment that runs my terminal, I'm talking about things that run in my terminal.As for "terminal-based X11 emulators:, there's a fairly prominent one you might have heard of, it's called xorg. If you try to run 'startx' inside an X session you'll have problems.
When did I say that? You demanded that support for terminology's graphics sequences needed to be patched into every terminal emulator that exists in order for you to consider it valid for some reason.By doing so, you're saying that people who write software that supports these graphical protocols (or maybe the authors of the terminals? It's unclear who you expected to do this for you) should jump through huge, unnecessary hoops just so that you can run their software (that you claim you don't want to run), rather than you..........simply running their software in the environment it requires.
(2/2)
Maybe you don't tend to use all your machine's resources, but the way I use my machine, it's constantly at near or over 100% capacity. I'm constantly fighting against swap, no matter how much ram I have. Right now my machine is using about 113% of available ram. I'll have to flush it out and clean it up soon to prevent too much swapping. I probably wouldn't want to start vlc right now without closing something else first - if I wanted to watch a video right now I'd use something more lightweight (or something I already have loaded, like my terminal). This is a normal state of affairs for me. In what way is this "a useful baseline"? Useful for what? Why is the extremely-well-supported 256 colour set or RGB not more useful? Who uses linux in text-only mode or with a display that can't do rgb in 2026 in any situation that isn't headless or exotic? Why can't they just run more complex stuff on the framebuffer with rgb colour if they want it? Why, given the above, is emoji support in text-only mode important? to whom? For what? Why would anybody who isn't working with extremely exotic legacy hardware care about this in 2026? Which ones don't run in terminology? ...as long as it's not the heresy of displaying graphics in a a teminal. See this is the point right here. You consider it comfort. I consider it nuisance. So go use your GUI applications and enjoy them and let others enjoy their preference. Like I said a hundred thousand years ago. No, it was to say - without having even bothered to try it yourself - that there's no use for a thing that I use all the time. And then in order to support your thesis you started evangelising the massive pile of software that you'd use to achieve what I can do better with one program that I always have running. How are nerd fonts at all relevant to any part of the discussion?Oh, I see: You said "[dolphin] even can render actual icons without a patched terminal font!"...
...you mean like terminology and other graphics-supporting terminals can? If they were using terminology or kitty, they wouldn't need to patch the nerd font icons into their terminal font - they could just display the icon they want.
So your point was to sarcastically suggest another actually-pretty-good use-case for the functionality you're arguing against. Got it.
And what happened when you filed bug reports about this? Please link to them, I'll be interested to read your reports for more detail than none at all. Well I don't know whether it does or not. Because you haven't bothered to actually describe the issue you claim exists in any detail. Or done anything more than make a vague and as-far-as-i-can-tell-incorrect assertion that terminals can't display emojis properly. As if that was somehow relevant to whether they should be able to display graphics or not. As an application developer, you have control over this thing called "system requirements" for your software. And you can do things like adding "requires terminology" or "feature X requires terminology" in there. Or you could put a note on the relevant issue in your issue tracker saying "you can work around this by using terminology, which doesn't have this issue". But of course we'd need to know whether that's true, first, and for that we'd need more than zero detail.Or perhaps you should just make your application graphical, since you've said solves the problem you're having with emojis and repeatedly asserted that graphical software is inherently better.
Which of these is appropriate, i don't know, because you'd have to give more than zero detail for me to be able to tell.
Maybe when you're linking to more than zero detail you can also explain how it has anything to do with whether supporting graphics in terminals is a good idea.
hey Carsten! o/
Haha, you beat me to it. Basically the same example.
This is maybe because it's quite hard to find some?! ^^
more "just the best, first example that springs to mind" - Great minds something something.
> 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
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... ^^
> 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...
> Yes. All these 800ms!
For you. This one time that you tested. It took almost an entire second. Or, another way you could say that would be "longer than it takes terminology to pop up a preview".
> Yeah, well, technically, of course. It just never felt like "waiting". It's a matter of milliseconds
Well then either dolphin is by some miracle orders of magnitude faster than any file browser I have ever seen (which includes earlier versions of dolphin that presumably have fewer features than the current one), or you're not viewing folders containing many files. Or maybe you just have the fastest and most powerful computer ever built. Or perhaps you just don't have any expectation of a performant UI and consider twiddling your thumbs to be no big deal.
> terminal applications don't need to enumerate directories when they deal with it? How does that work?
They do need to enumerate files, obviously, but they don't need to - for each and every file and subdirectory:
1. determine the mimetype for the tile, which may involve actually opening and reading the file
2. look up that mimetype in their "mime type -> friendly description" table
3. look up the default application that needs to be opened if you double-click on said file based on that mimetype
4. if the mimetype is "video" or "image", look in their cache for a thumbnail for the file, and if that doesn't exist fire up a thumbnailer to generate one, which likely involves opening and reading in the entire file.
6. load the aforementioned thumbnail into memory and display it in the appropriate place
7. as previously mentioned, enumerate and count the number of items in directories
8. I'm sure a bunch of other similar things that I can't even be bothered trying to remember right now.
...interrogate every single file for its mimetype, load up a thumbnail for every single media file, and count the number of items in every single subdirectory? No, it will not do that when I press tab. ..........um, what?Seems to me like maybe you've never used a terminal program? Or perhaps you've never used a gui program? I'm not sure what to say to this. I don't think I've ever seen a piece of GUI software which comes close to the speed of its terminal-based equivalent. I'll grant you there are outliers, but those are rare and every single example I can think of doesn't use a GUI toolkit.
There are a few factors at play here. One big one (maybe the biggest?) is simply the complexity of the interface: Terminal emulators are built and optimised to display a whole bunch of text very quickly. They have one job: display text. GUIs and GUI toolkits, on the other hand, are huge complex libraries with a large number of different controls that they need to draw in the right place, do layout, have to deal with mouse interaction and event systems and the windowing system, deal with weird input methods and accessibility, etc etc etc etc etc etc etc. They're orders of magnitude more complex just in their interfaces. And that's before you start doing things like loading icons for every little button you're displaying and thumbnailing every media file in a directory so that you can load it as a pretty icon in your file manager. And before you start taking into account that a lot of gui software is just poorly written trash seemingly written by morons under the CADT model (Hi, gnome!).
GUIs are fine, and the best option for a bunch of things. But they're much MUCH less efficient than terminal-based programs.
I don't know what else to say. Go talk to every single GUI application author ever, I guess?
Yes. One that's using a very limited set of GUI widgets compared to almost any other graphical program, and which has one job: display text. Indeed, the speed of terminals does have a marked effect on the speed of program execution in many cases: just try doing `time cp -Rv /usr /some/new/disk` - you'll spend a LOT of time just listing the hundreds of thousands of kilobyte-sized files you're copying, and the amount of text you're spitting out and scrolling your terminal emulator needs to do will slow down the file copying. If you compare this with `time cp -R /usr /some/new/disk` you'll find the non-verbose incantation to be much faster. Part of this is the fact that it doesn't need to run the printf statements, but much more of it is the time the terminal takes to output what is being printed, and especially scrolling. You'll also notice a pretty significant difference depending on which terminal you use - xterm will be faster than gnome-terminal, for example, because it's not bloated trash. KDE's terminal might be better than gnome's, but it will almost certainly not beat xterm. Nor will terminology. Similarly, running the verbose copy in a screen session and then switching to another 'window' in screen will speed up the copy, because even though it's verbose and running the printf statements, the terminal doesn't actually have to do the work of displaying the huge stream of text. Similarly, you can do a crude benchmark of your terminal's efficiency with bash by just spitting out a long line of text a million times and timing how long that takes. Sure. After you've waited almost an entire second, if you're lucky, for dolphin to start, and waited for it to enumerate all the files, and waited for it to count subdirectories, and waited for it to check its cache for thumbnails, etc etc etc etc etc etc.Meanwhile, like I said, I'll already be half way through previewing the video, and my workflow won't involve switching to some worse program.
I'm not even sure what point you're trying to make here - that sometimes your preferred method is even more shit, and so you sometimes have to fall back to the one I default to? Who said anything about rewriting all programs for the terminal? Why would you do that? I already specifically said that "We do also use our graphical environment". Who said terminology is "trying to be a graphical app"? I'm not sure why you insist on making this so complicated or acting like it's scary somehow. I've already told you that it does, in fact, work. Very very well. Maybe you should try it out so that you have some idea what you're talking about before you start telling me that things I do all the time "cannot work". Did I say I use it "constantly"? I don't recall saying that. I use it as often as I need to. Because I can. Because it's there.And it's a better experience in literally every way imaginable than firing up fucking dolphin and waiting for three ice ages and also an image/video viewer.
> It took almost an entire second. Or, another way you could say that would be "longer than it takes terminology to pop up a preview".
Yes. But how often do I spontaneously need previews of something? And how often is it then enough to get what this EFL lib can give me? In terms of format support, and in terms of functionality (e.g. can it show me the TOC of some pdf and allows me to navigate to some chapter?). Well, there seem to be some use cases... Obviously... I still cannot imagine how they look like, though.
> Well then either dolphin is by some miracle orders of magnitude faster than any file browser I have ever seen [...] Or [...] Or [...]
Maybe a combination of all of them... :) I don't know. The performance was always good enough to be much faster than I am.
My point was also: Before we now start to shoehorn graphical functionality into terminals, which we then only can use in graphical environments anyways, shouldn't we better just improve the graphical apps? There is no inherent reason for them to be any worse than your terminal apps (that are eventually hosted by just an ordinary graphical app).
About your list what Dolphin needs to do but terminal apps don't: Yes, sure. A lot is going on. In the background. I don't have to wait for it to generate thumbnails. It's not bash, which completely freezes then, e.g. when the network drive has a slow day, and I blatantly pressed Tab. Same for most of the other things you wrote. Win 98 did it as well (not the mimetype-detection, though). Even that was okay for most practical purposes. But look what machines we had back then! I've just navigated to /bin. At least around 3000 files. I would avoid having so many files in a single directory. For organizational purposes. Anyways. I instantly see it listing the files, and it felt finished instantly, and i was able to scroll around. No waiting time that would have blocked me.
BTW: All the thumbnail stuff is done on demand, as soon as you scroll down.
And finally: You can just turn it off! ;)
Counting the files, and determining which application is associated with a file type, are quite cheap operations. That's nothing, even compared to the very bare directory enumeration, right?
> No, it will not do that when I press tab.
Yes, well, sure... But that's not because a terminal is the superior environment (how could it be if you just emulate it with the "bad" one). If all that 'modern' (win98) Dolphin magic is too slow, there are probably more lightweight alternatives that are still graphical. I still don't see the point in patching graphical features into something text-based, which you then need to run in an actual graphical environment anyways, instead of just getting the graphical apps right.
>> I really don't see why terminal applications should be fundamentally faster than graphical applications in that regard > ..........um, what?
Yeah, I'm assuming terminal applications that you run in your graphical terminal emulator. But that's obvious, right? If I would be wrong, then, of course, let's today start porting all our graphical apps into that E terminal thing. Maybe we then can get even faster by putting that again inside an E terminal. And again, and again...
A terminal application that you run in an emulator, which is just some graphical application, cannot fundamentally be faster than just directly running graphical applications without that indirection, right? That would make no sense at all...
> Seems to me like maybe you've never used a terminal program?
I was a child when I got regular access to my first PC... It ran MS-DOS 5. I played more with command.com than with the actual games installed, I suspect... My friends played NES, while I tried to hack custom program launchers as .bat files. :-/ Even they made use of the 16 colors (or 8?!) you could have, though. ^^ No idea where I found out how to do that, a decade before my first internet connection... But at least as much I loved my first Windows 3.0 installation! Sure, command.com was probably quicker than Windows File Manager, strictly speaking. It was never so bad that I opened a terminal window for file management, though.
> GUIs and GUI toolkits, on the other hand, are huge complex libraries
Technically, I can just agree again. But all that happens so quickly nowadays, in terms of wall clock time, that I really doubt the practical relevance. A "hello world" app in either Qt or GTK starts instantly on my machine. No waiting time that a human being could recognize. I press Enter, and it's there while I'm releasing the Enter key.
> And before you start taking into account that a lot of gui software is just poorly written trash seemingly written by morons under the CADT model (Hi, gnome!).
We can definitely agree here!!! :)
> I don't know what else to say. Go talk to every single GUI application author ever, I guess?
Better than reinventing a whole new kind of terminal applications which aren't actual terminal applications, but only work in an environment emulated by the very thing they want to replace. The same morons will come and screw up with all kinds of things there again, once that'd get more momentum. But now, since they also have to maintain EFL plugins or other graphical-to-terminal translations for their apps and file formats, they will even screw up heavier.
>> If you know the file name starts with "cat_s", then you can also find it this way in Dolphin. > Sure. After you've waited almost an entire second, [...]
On an average day, I open a Dolphin window maybe once or twice... Often not even once (e.g. I just open my IDE and stay there, or the browser, or a game, you name it). You don't need a new one for every operation! I mean, if your workflow is seriously superior, then be happy that EFL and all that exists and supports all the file formats that you want to preview, and be happy that it provides all the features you need. I'm happy with you then. I have the feeling that it's a very special workflow for a very special task at best, though.
> I'm not even sure what point you're trying to make here - that sometimes your preferred method is even more shit, and so you sometimes have to fall back to the one I default to?
If you want to understand it that way, that's fine... And you type "xdg-open" while I can just press Enter (or double-click ^^). Why should I constantly want previews of something, so often that I'd care about a second of waiting time once in preparation, so much that I should avoid Dolphin, which just gives me these previews without any user intervention needed, just because it take a second to start?! Couldn't you just leave it open then?! Yeah, you'll definitely have some reasons...
> I already specifically said that "We do also use our graphical environment".
Sure you do! I know! Terminology is one of them. That's exactly the point. For an actual (virtual)terminal, it would at least remotely make some sense to me. Because there it's not an option to just use a common X11/Wayland image viewer.
> Who said terminology is "trying to be a graphical app"?
No; it already is of course. It's trying to make terminal apps graphical, right? And all that technical complexity is just there because you don't have to move your eyes to another window (there are very basic image viewers without any features; I've no idea why they should be slower than the EFL previewers - and if you want a video thumbnail, just write an ffmpeg oneliner as an alias). Again, I'm happy for you that it's available, but I'd definitely dislike to see all that arriving in major desktop environments. And I'm still optimistic in that regard. If it does, at least there might be ways to integrate the Dolphin thumbnailers. :)
> I'm not sure why you insist on making this so complicated or acting like it's scary somehow.
In some way that's exactly what I'm wondering about when people have terminal-centric workflows in an environment that could actually just do graphics. In particular when they then start to patch graphics support inside their terminals.
(lol, split for length, 1/2)
I don't know. Or care. I use it a bunch. Maybe you're conditioned not to do that because every time you do it, it takes you 10+ seconds rather then 1. Who knows? Who cares? I've already responded to this spurious scenario. Go read my previous responses. Ooh, what a great concession. Could that be because you haven't tried it and don't understand what you're talking about? So in other words, you are slow. Who shoehorned what? Where? You haven't read the specs for how it works, so you don't know what you're talking about. Still. So your suggestion is to add a terminal to every gui program in existence? I could point out how that's objectively worse in about a thousand ways, but instead I think I'll just let the absurdity of your entire premise sit. I've already explained, in great detail, that there is indeed an inherent reason why they're worse than terminal applications. Maybe you should consider reading the thing you're responding to. You do if you want to see them Dolphin does exactly nothing for exactly the same length of time (actually longer, due to all the extra shit it does) in this scenario. So a tiny, trivial list of binaries then. That's about 40% the size of the directory where my binaries live. So in other words, dolphin, like every other graphical file manager, is slow as fuck working with directories with lots of files (where "lots" is a colloquial term for "really not very many at all"), and you adjust your workflow to compensate for how dog-slow your shitty gui file manager is.My music directory contains over 80,000 files. Try opening that in dolphin, you'll learn the meaning of "slow".
> I instantly see it listing the files, and it felt finished instantly, and i was able to scroll around. No waiting time that would have blocked me.
No, you don't "instantly" see it listing files, because it has to open a window first, which you've already said takes ~800ms. You're just not aware of the wait time because you've conditioned yourself to accept constant context switches and thumb-twiddling in your slow DE.
But just as an experiment, why don't you "instantly" select the file named zcat.
So in other words: "in advance", while you wait, before you can see them. Dolphin has the ability to disable it's "double click to open file in the preferred editor" functionality, to avoid the need to determine mimetypes, does it? Hahahahahaha. Hahahahahahahahahahahahahahahahahahaha!Someone has never looked at a directory with subdirectories containing 100K files or more in a graphical file manager.
Someone has never looked at his disk usage while that happens.
Actually that's exactly why - terminals are the superior environment."emulate it with the 'bad' one?" What are you talking about? Who said guis were bad? When?
Such as?I look forward to seeing your list of graphical file managers that are faster (or even within an order of magnitude as fast as) ls. Please be exhaustive, I want to try them all!
No, you don't see the point. We've already established this....Is your complaint here that you can't run these graphical terminal programs without having some sort of graphical environment running? i.e that it won't run on an actual text-only dumb terminal?
When was the last time you used a terminal in an environment where you didn't have hardware for graphics support?
And let's say you're one of the seven people on earth who does use a text-only dumb terminal daily: When did anybody advocate phasing out CLI software that doesn't use graphics features? How do you know that a bunch of this software with graphics support can't fall back to non-graphical options in non-graphical terminals? (hint: many/most can)
By the way, a bunch of actual "text-only" dumb terminals have had graphics support since the 1980s [1], and konsole has supported graphics for at least 5 years [2], and since 2022 it has supported the kitty graphics protocol [3]. Of course I'm sure you knew none of this because it took me >0 seconds of searching to look up the konsole support. I'm also sure this means konsole is broken and doesn't work, and the graphics support that's been there without your knowledge for half a decade has probably caused a bunch of bugs that you've been having trouble with, so I guess you should probably change terminals. Maybe to xterm... oh wait that's had sixel support for 6 years [4].
Here you go: phosphor [5]. I'm 90% sure this doesn't support graphics. And As a bonus, you'll be thrilled to know that it also doesn't support colour!
I don't understand where you've gotten this idiotic idea that nobody advocated and which I have repeatedly stated that nobody advocated from. Constructed strawman, much? I've already explained how it is indeed far far more efficient and faster. If you think it doesn't make sense, that's because you don't understand. I'd suggest doing some reading. For example of my previous explanation. Ooh I'm so impressed! By that time, I was already editing command.com itself.editing .bat files, huh? And then you thought windows 3 was good and never went back to a terminal.
So, another way to say it would be that you don't know how to use a modern unix terminal - which is what I mean when I say "terminal", because dos was always a toy OS.
...and you don't even know what your DOS machine was capable of or what it could and couldn't do. This depended on a few factors, not least what type of graphics card (if any) you had and whether you were using a colour screen or an amber/green one. So, in other words: text-based software is faster than graphical software. ...because you've conditioned yourself not to notice the time you spend waiting around for your shit software to initialise. 1. It absolutely does not start instantly. Go write a "hello world" in qt/gtk that exits instantly as soon as it's displayed its main window. Then time how long it takes. It's going to be >0. Or, in other words, "not instant"2. This is a false and contrived example - a "hello world" program is intentionally extremely minimal and explicitly does not involve initialising a complex interface - it's literally a single control - how many "hello world" programs do you use on a daily basis for productivity? Please link me to a "hello world" program that can preview video for me, and that starts up instantly.
(2/2)
This is empirically, demonstrably untrue, because the "launch application" action does not begin until the "key release" event has fired. Which is something you'd know if you understood how your interface works. *cough* Whoosh! OMG you're totally right! Let's just stay using 1970s tech and never improve anything! Just remember to never ever update your browser!Why are they not actual terminal applications? What terminal functionality do they lack? Please provide excruciating technical detail on this subject about which you know nothing.
I know right! It's so rare and exotic for people in 2026 to have hardware capable of graphics! And in colour, too! Such an onerous requirement! And also it's obviously totally impossible to ever detect whether a program is running in an environment where graphics are supported and fall back to a text-only mode! Oh noes! What will we do when they force graphical output into the kernel with no option to disable it?!?!For the umpteenth time, who said anything about replacing guis? I have repeatedly stated that they have their uses and are the best option for a bunch of things.
Why are these people writing gui programs that run in a terminal in your contrived fantasy scenario? Again, for the 50th time, who suggested this or advocated for it? When?EFL plugins? Graphical to terminal translations? What are you talking about? It's almost like you don't understand the technology and have invented some fantasy architecture for all this stuff which is nothing like the actual architecture that exists and has been described here and elsewhere.
Right, but we're not talking about an average day. We're talking about a specific scenario where you have described a specific workflow which you are claiming is somehow superior to the one which I have outlined, and which is demonstrably superior by several metrics which I and others care about. I don't actually give a fuck what you do on an average day, or how often you start dolphin. You're the one who claimed that you would start dolphin, and then another program like vlc, to do what I can do without starting anything. If you're now claiming that you don't actually need to start dolphin, then why did you waste my time by advocating that workflow? Your "feeling" about my workflow is worth less than nothing. Because, yet again, you don't know what my workflow is. Because you don't understand it. Because you haven't bothered to try to understand it. And that's fine for you, if you prefer your worse windows-like UI then go and enjoy writing trash in visual studio. I'm happy for you. But don't think that that means you're somehow qualified to talk about terminals and their pros and cons. Well, it's actually only 'xo' for me, I set up an alias a long time ago. I said "xdg-open" because not everybody has that alias. As I've said elsewhere, you don't understand the point and you're fixated on the speed thing. Because you don't understand the point. I have a bunch of reasons.Have you ever left dolphin open for 160+ hours in a directory containing 80,000 mp3s? How'd that work out for you? How did it handle it? How much ram did it use? What was your system load like?
...that you don't understand my point and the problems I have with the flow you suggest? Again, do you mean "running outside of a graphical environment"? That oh-so-common situation that so many of us deal with on a daily basis in 2026?Let's say you do mean that: You still have no clue what you're talking about. For instance it's trivially easy to view an image or play a video with no graphical environment running*, as long as you have hardware that can do a framebuffer. Like, for example, every graphics card made in the last 30+ years. And if you have that hardware, then you can run terminology on it, too. As raster already mentioned and you failed to understand.
* (one of my machines is indeed set up to play video 24x7 and does not run a windowing system or graphical environment at all)
Terminology doesn't give a shit what software you run on it. It's non-sentient, you see. It doesn't care either way. It's definitely not trying to convert terminal programs into gui programs, or the other way around, like you seem to think because you haven't bothered to understand what I'm talking about.If you think it might be, you might want to look into that. Ascribing motivations to inanimate objects seems like it might not be healthy.
All what technical complexity? Where is the complexity, exactly? Please be precise and detailed.You don't know. Because you don't understand how it works, and you've ignored the people who tried to tell you.
You. Do. Not. Understand. My. Point.Please try re-reading my other responses and this time try to comprehend what I'm saying if you'd like to continue this discussion.
...No features at all, huh? Please provide examples.So then, you're saying they don't open up a window? They don't decode jpeg?
I question the usefulness of this software. But I can't wait to see your list.
Then I'd suggest you re-read and this time try to comprehend my detailed explanation in a previous message explaining how they are and always will be fundamentally slower and cannot help but to be so due to how software and physics work. Oh noes! It's already been in KDE and konsole for more than 5 years! I'm so so so so so so so so so so so sad for you! How this must ruin your day and impact very negatively on everything you do in daily life! And the bugs! All those bugs that the shoddy implementation and extreme technical complexity have caused for you! Do you need a hug? What. the fuck. are you talking about???Are you saying that you wish lsix[6] existed? And that it worked in konsole? And that you wish you could use it right now with literally 3 seconds of effort to install it? Are you saying that, after typing a hundred thousand words railing against the inclusion of any graphical features in any terminal ever?
Some people value being able to get stuff efficiently. Apparently, you're not one of them.I love how, after having the massive complexity of gui applications explained to you, you just brush that off and say "just do graphics". That's pretty good trolling right there.
For what I really really really really hope is the final time: if you bothered to try to understand the point which I have made to you repeatedly and in several different ways, then you might understand. But that would require more than zero effort on your part, so it's not going to happen.[1] https://en.wikipedia.org/wiki/Sixel
[2] https://bugs.kde.org/show_bug.cgi?id=391781
[3] https://github.com/hpjansson/chafa/issues/78
[4] https://invisible-island.net/xterm/xterm.log.html#xterm_359
[5] https://man.archlinux.org/man/extra/xscreensaver/phosphor.6....
[6] https://github.com/hackerb9/lsix
Oooof... Okay, but quicker, bcs I need to leave at some point in time. I'll skip most of the parts where we are in a loop anyways.
> Could that be because you haven't tried it and don't understand what you're talking about?
Admittedly, yes, I'm still trying to understand that.
> So your suggestion is to add a terminal to every gui program in existence?
Interesting idea in some way, no? Not each one individually, please. That would be equally bonkers. But in the end, looking at the final result, that sounds a bit like how I'd interpret your hybrid approach.
>> About your list what Dolphin needs to do but terminal apps don't: Yes, sure. A lot is going on. In the background. I don't have to wait for it to generate thumbnails. > You do if you want to see them
Sure, but then you are comparing apples and oranges. You compared it to pressing Tab.
>> I would avoid having so many files in a single directory. For organizational purposes. > So in other words, dolphin, [...] fuck [...] My music directory [...]
You are doing everything in that very quick way, right? "For organizational purposes."
I just gave it a try; Dolphin has no trouble at all with 100000 files in a directory. Yes, it took a second longer. Whatever you'd do with these files will be by a few magnitudes slower.
> But just as an experiment, why don't you "instantly" select the file named zcat.
Yes, did so. And now?
> Someone has never looked at a directory with subdirectories containing 100K files or more in a graphical file manager.
It only does that (with subdirectories) if you explicitly ask it to do so, by opening some Properties dialog. You are here definitely starting to make things up.
> Such as?
Nono, I'm fine with Dolphin. :-P
> ...Is your complaint here that you can't run these graphical terminal programs without having some sort of graphical environment running?
Why else should sane developers start to spend any serious efforts into applications based on this ancient tech stack? They would (obviously) of course just make a graphical application if it's graphical.
> When was the last time you used a terminal in an environment where you didn't have hardware for graphics support?
Welllll, not sooo often, fortunately. Virtually never, and when I do, I definitely don't need previews of cat pictures. Most of the times I just use graphical applications. Even some Java based ones! Boy, you wouldn't guess what they all do while loading, and how long that takes. It's actually wild. But I'm not using my PC for starting applications, right. I do that once. And then they run. ;)
> By the way, a bunch of actual "text-only" dumb terminals have had graphics support since the 1980s [1], and konsole has supported graphics for at least 5 years [2], and since 2022 it has supported the kitty graphics protocol [3]. Of course I'm sure you knew none of this
No. I'm sure it can do another 100 things that I'll never use. If you're in such a hurry all the time, you'll understand that I don't spend a lot of time in these things.
> [...] the graphics support that's been there without your knowledge for half a decade has probably caused a bunch of bugs that you've been having trouble with [...]
Read again what I wrote (hint: it was not equal to "sixel support will definitely break a terminal")! But, yeah, we'll never know. To what should we compare it with? The good news here for me is: The danger is already mostly over then, and if there were issues, at least big ones, they're then already sorted...
Also, as you can maybe already infer from our conversation so far: I don't use Konsole that often. Slightly more often I use the terminal integrated in Jetbrains IDE. That is even worse, unfortunately. Although without Sixel support. ^^
> Ooh I'm so impressed!
That's nice to hear. I just tried to answer your question, though.
> And then you thought windows 3 was good and never went back to a terminal.
No no, that narration would skip quite some decades and would make me sound smarter than I actually am. Sure, in the first Linux years, you are definitely vulnerable to the terminal cult, and you assume that you talk to very very smart persons instead of just priests, and you believe them a lot, before you understand that a lot of it is just an odd cult. And in a lot of cases (even today) you just sometimes have to use a terminal; particularly on Linux.
But really not for image thumbnails, and neither for management of my music collection. That actually never happened.
>> Even they made use of the 16 colors (or 8?!) > ...and you don't even know what your DOS machine was capable of or what it could and couldn't do.
No. That was when I was in elementary school. Just barely. I was happy when I was able to collect these things in other .bat files and were clever enough to combine these findings to something that somehow worked.
> This depended on a few factors, not least what type of graphics card (if any) you had and whether you were using a colour screen or an amber/green one.
Without colour screen/card, there would be no question whether it was 8 or 16 colors, right? It would then be 2.
> [...] 2. This is a false and contrived example - a "hello world" program is intentionally extremely minimal [...]
If you need more complexity (e.g. for layout of more complex content), your terminal app also has to deal with that in some way.
> This is empirically, demonstrably untrue, because the "launch application" action does not begin until the "key release" event has fired. Which is something you'd know if you understood how your interface works.
No, not at all. What are you "demonstrating" here. I've never seen the behavior you describe on ANY platform tbh. Also not in any terminal.
>> there are very basic image viewers without any features > ...No features at all, huh? Please provide examples.
I'll not do your web search for you. For some reason, I've imagemagick installed here, which seems to ship a very basic image viewer. It starts (at least for the image I've tried with) as instantly as the hello world apps.
And just for the case you still don't understand: I mean "instantly" in a practical meaning. You don't have to explain me once more that it can't be exactly 0 sec in a scientific meaning. ;)
I'll skip all the parts where you don't understand my point, or where you're just saying nonsense, and jump right to the heart of the thing (other than "you don't get it"):
So, in other words, when you say "instantly", you mean "not instantly".That's a pretty great metaphor for your entire line of argumentation.
I would respond to the rest - there's a million things there that I'd love to dissect, e.g the admission that you haven't even tried the thing you're so against - but why would I bother? When you say things, you mean things that aren't the thing you said. Case closed.
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??
SCNR
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.
Funnily enough, KDE got this feature yesterday: https://invent.kde.org/plasma/kwin/-/merge_requests/8602
Awesome! I might try it again, tbh I have KDE on one computer but I don't use it much as my muscle memory is very gnomy and I haven't taken the time to tried to switch back in long term and I admit until hearing about that very little strong incentive to do so.
The one I really miss is WindowMaker[0], missed its powerful simplicity
[0]: https://www.windowmaker.org/
I know that people never want to hear such remarks... At least I never want... But I risk being the idiot anyways: KDE/Plasma doesn't crash here so often. I've seen it actually happening in the last years. Unfortunately!!!! Maybe two or three times... And then, it just restarted in a matter of a second. It did not affect anything. No running apps crashed. Just the task bar and the desktop went away for a second.
How long have you tried, and how long are you now trying Gnome?
That experience was almost 20years ago, between 2006 and 2009 (I had to check linkedin because I only remember which employer I was working for) so based on wikipedia it was still KDE 4 wich was very unstable.
I tried a few times KDE 5 over the years out of curiosity then more recently KDE6. I have it on one computer but I rarely use it as it is the gaming machine and I very rarely play videogames. The thing is I got so used to the ergonomy and shortcuts of gnome and i3/sway that whenever I use KDE I need either a lot of time to get used to the default keyboard shortcuts and layout and/or I need to take time to modify/configure it. But since I have been fairly happy with gnome and sway I don't really have much insentive to switch again. No hater really.
KDE 4 was indeed a huge mess... All 4.x version. Even if every changelog had the sound of "Now the glitches are fixed; you can now start using it". It never was...
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.
KDE1 had some very nice themes! I remember using one that drew inspiration from the visuals of Bryce on the Mac. Dark mode theme - and animated window titles which would scroll gently if the window title was too long to fit.
Wasn't it KDE 2 that introduced themes? I remember early versions of KDE and Qt only offering a choice between Windows and Motif look-and-feel.
> KDE 1?
Yeah, compared to Win 95 at least, it looked interesting in a positive way...
Problem was: Whenever you clicked on something, some message box appeared, with some one-line error message that contained the word "unknown" or "unexpected"... :)
With KDE1 is was most likely "Not yet implemented" :-)
I never used KDE2, KDE3.x was rock solid though. It wasn't until KDE4 where things took a massive nosedive and everything was crashing if you looked at it wrong - something that lasted until most of KDE5's lifetime, though by late KDE5 and now KDE6 it seems to be fine.
Well, "fine", for some reason Wayland sessions crash and restart the entire session whenever i press any key (doesn't happen with Xorg sessions), so i guess there are still some minor bugs to be fixed :-P
No no, it always tried to do something, with a lot of self-confidence, but then constantly failed.
I can spontaneously remember k3b (CD burning tool) constantly failing because the CLI tools behind it (cdrecord, mkisofs, ...) replied in some way that k3b hasn't expected (e.g. because the locale was non-english, or the CLI tool devs changed the strings slightly, or there was a pointless warning text that k3b did not expect, ..., ...).
Admittedly, k3b was later... KDE3 era? But this is exactly how KDE1 felt... And in very bad days it still does today... You click on something, the developers assumed that the file manager can deal with it, but instead you just see the file manager saying "Unknown protocol" or similar. All the problems that arise when your system is very modular, but every module is a separate hobby project with no coordination.
I definitely loved KDE3 and was sooo excited about KDE4. And it was a pretty terrible disappointment. Nowadays I'm again fine with Plasma. Since mid KDE5 days.
> for some reason Wayland sessions crash
That's definitely a mess, too. I'm not fundamentally against Wayland. I'm using it right now. Even if it is still slightly broken today (yes, Wayland is a protocol; here I mean: the biggest implementations). But the entire Wayland story is very very sad. It took ages before it was at least usable for five minutes. And then everywhere the X11 support already gets disabled, while Wayland is still in a somewhat immature state. Sure, I somewhat understand what the devs say, and I can't force them anyways. But it's really not a success story for the Linux desktop.
> Wasn't Enlightenment something that just looked good in screenshots
Yea, this was my memory of it, too. I remember installing it, and making a theme that looked all "elite" and cool. I added an anime character desktop background, as was required at the time. Took a few screenshots, basked in how cool I was, and then just switched back to whatever I was using before (I think Gnome).
> I added an anime character desktop background, as was required at the time
i always thought that "stone hand on desert island" was the #1 requirement for Linux desktop backgrounds of the time? ofc i can't find a pic of it now
edit: found it https://i.ibb.co/bgpRF6Y7/image.png
Ohh, I've never seen that wallpaper before... Looks so year 2000-ish... :)
And then you start some actual (non-E) applications...
Which look completely different (i.e. not like something that MS Frontpage has desperately assembled out of Java Applets and weird color choices)...
And then, even if you liked the original look, you'll not be satisfied at all anymore, will you?
Yeah, okay, on the other hand, you could probably find Qt and GTK themes that somehow looked similar enough...
It worked, at least 25+ years ago when I last used it; early versions weren't a model of stability, but that wasn't nearly as important as an X server or a Wayland compositor not crashing, since you can simply restart an X window manager when it crashes (from a terminal window, virtual terminal, automatically from a script, etc.).
Lots of teenagers were using it back then judging by the old themes, 95% of which suck. As an adult I made a simple, attractive theme, enabled only the most basic and useful eye candy, and just use it. None of the other alternatives interest me, and I've tried them all.
I actually use my riced setups. Part of a good rice (at least for me) is it being ergonomic and usable. It should, of course, look good
E13 was a great, simple, good looking WM I used for years. Eventually moved to Fluxbox then back to macOS when it went Unixy.
In my personal experience - as far as I can remember - it always stopped to be good looking when it wasn't a screenshot anymore but a running process on my machine. In motion, all the eye-candy became ugly and foolish and visibly hobbyist, and as soon as I began using some applications outside of the E-ecosystem, the last sparks of fanciness went away anyways.
But that was... idk... E16 or so?! I really cannot remember. Maybe it had better times earlier, or maybe (surely) people are different and have different criteria for choosing such things.
Was E13 before they started trying to be a klingon starship UI?
same, especially compiz era after good drivers and accelerated compositing became ubiquitous was wild
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.
Me too! Looking at my old windows 98 machine and then at slackware Linux with enlightenment lured me to Linux and began a lifelong journey!
Same for me. Slackware (I guess 4.0) and E16 was my first proper Linux installation. Learned so much during that time.
Same for me. He definitely contributed to my fondness and wonder of Linux back then.
SuSE 5.1 for me, as it was what I could easily get the CD-ROMs for, as bandwidth was just a single 64k ISDN at school.
Yeah that was the reason for me too, in order to get the distro CD ROMS I had to mail $10 to some random address and wait 4 weeks for them to be mailed back!
I tell people you used to have to post a cheque when you bought stuff online and they just look at me like I’m nuts. It was basically just mail order, but on the web.
Modelines are one of those skills that I thought would get obsoleted, but in fact taught me the mechanics of video timing that I was able to use in unrelated contexts. Such as years later where I was asked to fix a driver for a point of sale system which had a 1024x200 (or thereabouts, extremely wide nonstandard ratio) secondary screen.
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.
Well, unless you decided to use GNOME, then you get rugpulled by a bunch of people that think they know better than user what user wants and actively ignore any feedback
You can always fork it if you don’t like the choices they make
That’s the point the OP is trying to make about the advantage of open source
That's happened like three times to the extent that the forks are more widely installed than the original
And people did but it is hard against Redhat that has actively made harder and harder to use Gtk+ outside GNOME.
What changes have been implemented in GTK that make it harder to use outside of a GNOME environment?
https://adrienplazas.com/blog/2021/03/31/introducing-libadwa...
practically everything in GTK 4. It removed menu bars ffs
As far as I can tell, every major version of GTK should be thought of as an entirely separate project, and nothing in GTK 4 made GTK 3 or GTK 2 harder to use.
what does make GTK2 harder to use is that it is not supported anymore. you can't build or run GKT2 based apps on new systems without building the GTK2 libraries yourself.
Please link me to the python3 gtk2 library so that I can migrate all my python2 gtk2 software to python3 without rewriting the entire UI. Thanks in advance!
There are forks though. The only version i don't think that has a fork is GNOME 1 but... the code is out there (and there is an actively maintained GTK1-based toolkit that was posted here not too long ago, though you may need to make some modifications to the GNOME 1 code to work with it as IIRC it isn't backwards compatible).
People made CDE to work on modern systems and IIRC CDE wasn't even compatible with Linux when the code was first released.
Hey! Someone sneaked into my brain and wrote down my exact comment!
But you can also use MATE still to this day, or even Cinnamon.
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.
It's a delicious irony that E is now a super-lightweight system compared with the mainstream environments that plauge our RAM chips today.
I still remember how cool I thought raster was with his vaio and everything. This was the future! Transparent eterms and tasteful backgrounds everywhere.
it’s not a valid enlightenment screenshot without a digital blasphemy wallpaper.
(digital blasphemy is still around and still selling art.)
Yes! Thank you. That’s a blast from the past
I remember fondly of a raster talk at FOSDEM about 20 years ago: playing videos inside a terminal. Amazing!
Wow, I think I remember that talk, too. And I remember thinking, "why would anyone want to run a video inside a terminal?!" I still don't want to do that, but it was cool that enabling that feature only required a few lines of code, since EFL(?) already supported it, was already linked in, and the code to start it was minimal.
i found this one from 2012:
https://video.fosdem.org/2012/maintracks/k.1.105/EFL.webm or https://youtu.be/HfcFbHQWqu8?list=PL31210579EDD785E7
in an interview from that time he says the previous time he was at fosdem was 10 or 11 years earlier. there seem to be no recordings from that time.
> tasteful backgrounds everywhere.
Certainly not everywhere. I definitely remember plenty of tasteless ones, some deliberately so and others just cases of other people's taste differing from mine!
This was the era of !hurl, after all …
> Sadly, the hang was deterministic:
Huh, someone's in it for the thrill of the hunt, I see...
I wonder about the sadly.
Luckily the hang was deterministic.
I think the author meant that she was just trying to work on her slides, and was hoping that by quitting/restarting, the bug would temporarily go away, so she could continue working on what she actually wanted to work on, and not go down a debugging rabbit hole.
Certainly the determinism made it easier to fix, but the determinism also meant that she had to stop what she was doing and fix it right now, which is... "sadly".
Sadly as in "Oh dear, I better start debugging this" I think.
Fun post! Very happy to see a 20-something year old find and fix bugs in an X11 wm from before they were born. Gives me hope.
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.In the article just before that code:
The loop is of paticular interest to us. Abridged:
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.
To put a finer point on it: running bleeding edge does not just now have implications of a greater attack surface, it always has had such implications.
It's just that a tiny fragment of people are suddenly becoming aware of this fact (the masses always remain clueless), whereas others have known it for some time. These people are referred to as "crazy tinfoil hat nutters."
Eh, there are two competing drives occurring here.
Back in the day before security was the biggest driver of updating software most people stayed a version or two back to ensure they weren't getting the last corruption bug of the day or whatever other insect was coded in.
But modern internet connected systems have pushed customers into more of an issue. It switched from, stay a version behind to see what bugs are there to, if you don't update now you're going to get hacked.
So this is the situation at hand.
If you don't update you're going to get hacked.
If you update you're going to get hacked.
The conclusion is, computer security does not actually exist.
Oh, people are still using Enlightenment.
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.
Enlightenment always had a pretty weird value proposition. In the very beginning, there was "fvwm-xpm" and early "E" prototypes. They were graphically crazy with a heavy focus on shaped Windows. There's still nothing quite like that weird steampunk/Brazil-ish theme they had. Probably for a reason.
Then they went both visually rather tame and scope-creepy (own graphical libraries etc.). At the beginning I was hoping that we'd get some kind of Amiga-influenced design sensibilities on X (basically a more "artsy" MUI), but that never manifested.
Yeah, I got introduced to it via some friends that were former Amiga users.
In '99 or so, I ran Enlightenment with Amiga-style draggable virtual desktops. As a former Amiga user, it made me very happy.
May I present: amiwm
https://www.lysator.liu.se/~marcus/amiwm.html
https://en.wikipedia.org/wiki/Amiwm
Yeah, I saw that back in the day, and it's great, but that was too faithful. I liked the eye candy of Enlightenment, but with a nod to the nostalgia...
There is still a lot of things I miss from the Amiga, but I'm acutely aware that a lot of what I wish for are based on rather rose-tinted memories.
I feel you. Same reason I don't use amiwm.
Yes! I have often wondered what it would be like trying to daily drive an OS4 amiga for modern stuff. I suspect it probably wouldn't be super awesome, mainly due to lack of software for modern things. But I'd really like to try it - if only I could run OS4 on an x86 PC*. I would definitely try it out.(* yes, I know I can run it in an emulator, but that's not the same)
One thing I'd particularly love to see is something like ARexx adopted in modern OS's and software. It would be super-useful to have most applications expose something like an arexx port, would make a lot of cool things very easy to do.
The odd thing is that a lot of Linux software does have Dbus support, but it somehow feels like the barrier is a lot higher and buy-in a lot worse. Just throwing together ad-hoc scripts w/dbus feels like it has a higher barrier.
Datatypes is another obvious one - present-day Amiga's can support modern image formats in apps that haven't seen updates for 25+ years...
I recently added hacky assigns to my (very hacky) little shell, as an experiment, as it's one of those features that feels like it's "just" link symlinks setting an environment variable to a path, but as it turns out it really is a lot more ergonomic (to me at least).
I've settled on a tiling wm w/one floating desktop to sort-of emulate how I typically used my Amiga screens, and that I like.
> if only I could run OS4 on an x86 PC*. I would definitely try it out.
AROS would be the closest thing. E.g. AROS One (a distribution)
https://sites.google.com/view/arosone
It's been many years since I spent any time on AROS, so I don't know what it's like at the moment. Back then I could boot the Linux-hosted version of AROS with a startup-sequence that booted straight into FrexxEd (editor w/extensive AREXX support co-written by the author of Curl) faster than a default install of Emacs would start on the same machine.
You make a good point about dbus. It is sooooort of similar if you squint. But I think both your points are correct. I feel like the buy-in factor is probably the big one - I think if there was lots of buy in the tooling would probably get easier.
How did I not think of datatypes? Yeah, omg they were do great. I'll never forget my amazement when I installed one (I think for jpeg) and now just everything supported jpeg.
I think IIRC beos did something similar to that.
Oh yeah I've seen AROS, but like you I haven't actually fired it up in a long time. The last time I did it was "Amiga Research Operating System".
I just noticed on their wikipedia:
That sounds like a good excuse to break out one of these pis I have sitting around!I still install it and play with it for a bit every other year. I really appreciate that it's held true to its own core. Yes it works with Wayland now, but it's still using its e-foundation libraries. I still wish I had screenshots of my desktop from 1998/1999. Downloading cool software from Freshmeat, hitting up Slashdot (news for nerds... stuff that matters) to see what was going on. Kinda wish I was into IRC back then but I was more of an ICQ->AIM chatter. It's an era I wish we could have back.
Moksha (a fork of e17) is the main desktop for Bodhi Linux, an unofficial Ubuntu-based distro:
https://www.bodhilinux.com/moksha-desktop/
https://github.com/JeffHoogland/moksha
AV Linux uses Enlightenment 0.27.1. The creator of that distribution also offers a version based on Moksha 0.4.2, the E17 fork mentioned elsewhere in this thread.
https://www.bandshed.net/
Latest Version Release Announcement:
https://www.bandshed.net/2026/03/01/av-linux-and-mx-moksha-2...
A few more details from and older release announcement:
"Both ISO’s are built on an MX Linux 25/Debian Trixie base with Liquorix kernels."
https://www.bandshed.net/2025/11/27/av-linux-and-mx-moksha-2...
I was also a huge fan of WindowMaker. Simple, effective, stylish without getting in the way. Also allowed me to have a vertical taskbar, which I stuck with even on Windows until Win11 has taken that from me - because Mac is the arbiter of taste and everyone must copy it.
MacOS definitely lets you put the dock wherever you prefer.
in fact most professionals I know who use mac prefer the dock on the left or right side
Win 11 has some niceties, however many of those could have been provided on Windows 10 as well, for example the security stuff like VBS and secured kernel were already available, even if disabled by default.
Oh man, that takes me back.
shell=C:\LiteStep\litestep.exe
I still use Windowmaker in places like VNC desktops where GDM gets grumpy and breaks a lot of the functionality. It also works much better over X displays on high latency networks like the Internet, where it is using the X drawing primitives as intended instead of constantly doing client side rendering and blitting the results over.
Funny, I was also one of those people who switched from E to WindowMaker. At the time I had no idea it resembled NeXTStep, but it was great.
After that I changed to KDE 3 which was a major milestone at the time. I think GNOME at the time was technically superior though.
Then shortly after I realized that desktop on Linux wasn't really going anywhere, so I switched to macOS (OS X at the time).
Kind of similar story, eventually I ended up on GNOME, as I favoured Gtkmm over how KDE was at the time, but then GNOME 3.0 happened, and my travel netbook got migrated into Unity, and when it went away, XFCE.
Due to similar realisation, my main working devices became Window 7 with Virtual Box/VMWare Worstation, nowadays WSL.
> At the time I had no idea it resembled NeXTStep, but it was great.
I used (and still use) Window Maker for almost a decade before learning what NeXTSTEP actually was (i heard about the name occasionally but never looked into it), then for several years before even trying one. I remember having a heavy sense of uncanny valley because the thing in front of me looked almost exactly like what i was using for years but it behaved in very odd ways (and lacked most of the window management features i came to expect) :-P. It made me realize what people who were used to Mac OS X felt when they tried the various Aqua GNOME/KDE themes that were popular on Linux desktops some years ago.
On the topic of lookalikes, remember good old fvwm95 ?
Yeah, although I very much prefered the orginal fvwm.
Funnily, E16 was considered a rather eye candy but heavy WM/environment back in the i486 / early pentium days, now it is considered lightweight!
And detractors of Emacs used to claim that it stood for "Eight Megabytes And Constant Swapping" meaning that even on a then-huge machine with eight megabytes of RAM Emacs would use up all the memory. Now it is a tiny program compared to things like Visual Studio Code.
one of the more interesting things to think about is the big push to rendering all window manager stuff through a gpu, because we were sure we needed drop shadows and geometry transforms for windows....
Now, what we actually do in a window manager could easily be done in software in realtime, just farmed out to some cpu core.
> because we were sure we needed drop shadows and geometry transforms for windows
As screens get larger, the amount of pixels you need to push to composite windows gets larger-squared. It makes sense to move the pixel pushing away from the CPU and more importantly away from CPU-RAM and on to a separate RAM bus.
The "single buffer with invalidation" model of Win16 (I cannot remember how it works in X) saves memory at the cost of more redraws. The composition model allows you to do things like drag window A over window B without forcing a repaint of window B every frame.
It also allows for better process isolation. I think in both Win16 and X11 you could just get a handle to the "root window" and draw wherever you wanted?
> The "single buffer with invalidation" model of Win16 (I cannot remember how it works in X)
Same way, they both come from Macintosh (which, if i remember the apocrypha correctly, was Bill Atkinson's idea based on what he thought Xerox Smalltalk was doing even if it turned out it wasn't working like that).
You remember correctly:
https://www.folklore.org/On_Xerox,_Apple_and_Progress.html
https://www.folklore.org/I_Still_Remember_Regions.html
eh, there is nothing a gpu can do here within the concept of composition that a cpu could not also do. the gpu simply has buffers that it compsits, the cpu can do that as well. with the benefit of less complexity leading to not needing to worry about driver crashes. on sane architectures its all the same ram anyway
> eh, there is nothing a gpu can do here within the concept of composition that a cpu could not also do.
True, but which is more efficient?
> on sane architectures its all the same ram anyway
Opinions differ. The main benefit of splitting RAM is not having to share the bus. As I said, this lets you use the CPU for CPU things without having to spend precious DRAM bandwidth shovelling pixels.
Things change. The tab in Brave that I'm using to view this comment section is coming in at 95MBs!
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.
I am still waiting for e17. I stuck to e16 for a long time until ubuntu got a thing which was much more convenient than gentoo.
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.
They're up to e27 now, it even supports Wayland.
The dbus requirement is a hard pass from me.
Greetings from e27!
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.
> 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.
No kidding. Last time I used Enlightenment back in the late 90s, both KDE 1.x and GNOME 1.x were orders of magnitude more usable on my lowly Pentium MMX 166 with 16 MB of RAM.
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.
I used that same theme back in 2003. Makes me want to reinstall E16
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.
https://www.enlightenment.org/ Seems down at the moment.
Coincidence, or collateral hug?
that was literally me... i stopped it because... well.. short version - chasing bug in efl that blurted out an invalid object stdout errors when http requests for the forecasts module failed - the module relies on a caching proxy service on e.org to get weather forecasts. i simulated it a bit brute-force by temporarily taking down apache :) it's back and bug is fixed in git. it's silent now not complaining about invalid objects.
Thank you for all your work on e, still my daily driver after all these years
It was a load-bearing bug you reckon?
I always appreciated how you can simply attach to the enlightenment process at any point, and also upon a crash.
The documentation is there: https://www.enlightenment.org/contrib/enlightenment-debug
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.
"Re-attaching repeatedly showed the program was not deadlocked."
Why re-attaching and not just resume then ctrl+c ? Is this some kind of clever hack I dont know about.
when it's your window manager you are using right now... you tend to debug differently :) yes yes - xephyr and what not. i know...
I really wish there was more EFL software :(
Good thread.
I've been going backwards to Afterstep and Window Maker theming. Maybe I'll get back to E in a few years.
I still use enlightenment today in the form of Bodhi Linux
Still the best window manager ever made. Nothing has beaten it to date.
very nostalgic :D thanks for a trip back down memory lane!
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.
Wow I haven't used enlightenment since the 90s! So cool!
e16 was truly unique... honestly the best Linux desktop ever made !
[dead]
[dead]
[dead]