| |
| ▲ | antisol 2 days ago | parent [-] | | > 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. | | |
| ▲ | pino83 2 days ago | parent [-] | | > 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. | | |
| ▲ | antisol a day ago | parent [-] | | (lol, split for length, 1/2) > But how often do I spontaneously need previews of something?
I don't know. Or care. I use it a bunch. Maybe you're conditioned not to do that because every time you do it, it takes you 10+ seconds rather then 1. Who knows? Who cares? > can it show me the TOC of some pdf and allows me to navigate to some chapter?
I've already responded to this spurious scenario. Go read my previous 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
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. > 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. | | |
| ▲ | antisol a day ago | parent [-] | | (2/2) > it's there while I'm releasing the Enter key
This is empirically, demonstrably untrue, because the "launch application" action does not begin until the "key release" event has fired. Which is something you'd know if you understood how your interface works. > And before you start taking into account that a lot of gui software is just poorly written trash seemingly written by morons under the CADT model (Hi, 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.[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 |
|
|
|
|
