antisol

  > I don't expect anything from anybody

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:

Argle bargle snerf blu carn delg bling blong blu barg sneh bork mert.

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

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 feel you. Same reason I don't use amiwm.

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

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

more "just the best, first example that springs to mind" - Great minds something something.

  > or whatever the tycat thingy understands

You're missing the point, which is that the EFL library just has media playback built into it - for a lot of different formats. Like Carsten mentioned, tycat doesn't do anything special, it just emits the right escape sequences to tell the terminal "display file X". And then terminology just says "hey media library, give me a player for file X". tycat doesn't need to know or care about file formats, nor does terminology.

  > And then you only need access to the mouse position in pixel granularity, and you basically have the foundation for a graphical environment. We can implement Qt and GTK for that new thingy. 

You (rightly) say this sarcastically. But people have done things like this. I was playing around a while back with embedding GUI elements like buttons inside terminology. I've got a library (which I should finish) to display gorgeous GUI-style progressbars in terminology. This also works for things like buttons - it's possible to display an actual GUI button inside the terminal, and to have it emit events that you can respond to. Limited real-world practical value, perhaps, but interesting IMO.

  > But: What is it for? Why not use your graphical environment in a direct way? 

Rasterman and I have both given examples of how this improves the terminal experience. Being able to preview media files in your terminal is a direct, measurable enhancement to usability: it removes the context switch and time of having to fire up a media player to preview a file, and the need to move your hand from keyboard to mouse and back.

  > What is it for? Why not use your graphical environment in a direct way? The existence of terminal emulators is the proof for it being at least as strong (or stronger) as your terminal can ever get. Right? 

I'm not sure what you mean by "at least as strong as your terminal can ever get"?

We do also use our graphical environment. It's just that our terminal also happens to not be stuck in the 1970s and pretending it's running on a teletype. Decades ago someone could have made a very similar argument to the one you're making that we shouldn't have added colours to terminals because real dumb terminals are all green or amber screen.

It's at least partially about pushing the envelope, not accepting the status quo, and trying to improve things. Terminal emulators tend to have a fixed feature set and there's a bunch of things they can't do that would be nice to have.

I mentioned the kitty terminal emulator before. It's doing similar things. And it's quite popular with the kids. These enhancements to terminals are a good thing! I'm glad these people are experimenting with things even if they turn out to not be very useful (and many terminology improvements are great!)

Another great example of this type of thing is the tysend command, which lets you download files without starting a new ssh session: you're ssh'd into some remote machine and you want a file. You can switch to another terminal and scp, or (as long as the host you're logged into has tysend), you can just do 'tysend /path/to/file'. Terminology pops up a (very pretty) save dialog asking where you want to save the file, and then displays a (very pretty) progress bar while the transfer happens.

I think maybe you need to try terminology to understand the many, many ways it's superior to a more conventional terminal emulator. For me, terminology is definitely enlightenment's "killer app". You can try it just by installing it, btw - you don't need to be running enlightenment :)

hey Carsten! o/

Haha, you beat me to it. Basically the same example.

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

[1] https://imgur.com/a/tL9h8Xs

May I present: amiwm

https://www.lysator.liu.se/~marcus/amiwm.html

https://en.wikipedia.org/wiki/Amiwm

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.

Hey! Someone sneaked into my brain and wrote down my exact comment!

Welcome!

Physical media is the only way to fly. Looks great on a bookshelf, works when the series of tubes is broken, and as a bonus the studios don't sneak into your house and steal them from you.

The price of discs these days, particularly second-hand DVDs, is so great. The low demand is a real windfall for us physical media collectors. Not long ago I managed to score the first 15 seasons of south park on DVD for $100. I quickly did some math in my head, and at ~4 discs per season, that works out to about...uh...carry the one...yep, it's fuck-all per disc.

That is indeed extremely likely to happen

  > Markdown without formatting isn't usually the nicest to read imo

Or to write! I use a bunch of features of markdown rarely enough that I can't remember the format for them half the time, and so I'm always looking at markdown references/cheatsheets. Add to that all the variations and incompatibilities between markdown versions and I'd much rather just use a wysiwyg word processor with nice keyboard shortcuts and a toolbar, and save in markdown format if I need to.

You had me at "non-HTML-based" ;)

I've been looking for a simple word processor that will let me easily/quickly do basic things and which will let me export to markdown and HTML that isn't terrible like the type word processors create.

I recently found wordgrinder (https://github.com/davidgiven/wordgrinder), which is a terminal-based word processor that's very close to what I've been looking for. A wx-based thing like this might be a bit nicer. So I'll start with one suggestion: support for wordgrinder's .wg format would be real nice :)

  > just the fact that they've ensured that k9mail is still maintained seems like an objective win, even if it's now called Thunderbird.

Not if you liked k9 and wanted it to not get turned into trash. It's just a matter of time. Personally I'd rather see k9 not maintained - it works perfectly well and has for ages - than see it ruined by mozilla like everything else.

Those people can think whatever they want to think, doesn't change what the facts are. I can't be bothered to look for them - I'm not sure which email address I used for which bugzilla (or was it something other than bugzilla?), or whether that bugzilla still exists (probably not? I haven't seen a bugzilla in a while). I'm not even 100% sure which decade it was (but probably 2010s, it was early in the thunderbird enshittification process). All I know is that I filed a couple - more than one, perhaps 3 or 4 - bugs for thunderbird, had zero response on any of them, and decided that it's not worth my time to try to engage with them any further.

You actually got me thinking about it, because I've been living with a lot of this trash for so long now that I think I've probably forgotten a bunch of my gripes with thunderbird.

So here are the ones that spring to mind when I gave it a little bit of thought. I'm sure there are others that I've forgotten about because I've adopted new workflows that don't involve thunderbird (e.g my calendar is a bit like that, but I remember it because I feel like an email client with a calendar should probably be able to sync with my caldav server, and because of the stupidity of the bug). I'm also sure that as soon as I hit 'post' I'll think of more (edit: this totally happened).

* Searching IMAP folders. Worked just fine in 2010, does nothing now, no matter how long you wait. These days I just grep my maildir, like it's 1975.

* Forgetting the sort order and display preferences for folders. It LOVES to do this after an "upgrade". Because the 300,000 times I've previously told it not to show my 'cron' folder in threaded view isn't enough, apparently. I must want threaded view, but I'm just too stupid to realise it, and if they switch back to threaded view one more time maybe I'll just accept it and learn the new and better way because Mozilla knows best. Ditto for showing folder contents with the newest messages as the top - you know, the default and most useful sorting order for email. Nooooooooooo - thunderbird knows better! It loves to semi-randomly switch folders to "oldest messages at the top".

* Flat-out refusing to talk to certain older email servers because they're serving up SSL certificates using an algo that's old and which mozilla has decided they don't like anymore. What's that? The machine is one that you don't have control over and that's difficult to upgrade due to it being an ancient SunOS machine running software from like 2001, and that you're connecting to over a very secure VPN and which isn't publicly accessible, so it's no security risk at all? Tough shit, use an email client that isn't thunderbird, we're not going to provide a "proceed anyway" button for people who understand what they're doing, because Mozilla knows better than you.

* Hey there! I see you've repeatedly removed the garbage hamburger menu. This must have been an accident and not that you do not want and did not ask for it and will never want it under any circumstances ever due to your strongly-held opinion that a traditional hierarchical menu bar across the top of an application is a superior UI in every way and that hamburger menus are less efficient and have no place on a high-resolution desktop interface. So as part of the latest thunderbird "upgrade", I'm just going to helpfully slip that shitty hamburger menu that you've removed 10,000 times back into the toolbar where I think it should be, so it can waste some screen real-estate for something you'll never use. That should correct that oversight where you accidentally removed it 10,000 times. Glad I could help!

* Hey there! I see you've accidentally removed the shitty hamburger menu for the 50,000th time. I'm going to do you a solid and solve this problem once and for all - by simply making it not optional and not configurable anymore. The top right hand corner of your toolbar WILL be a hamburger menu now and forevermore. That should sort that problem out.

* Hey there! I notice that you like a traditional hierarchical menu bar, like computers have had since the 1980s. Unfortunately this isn't fashionable anymore and isn't great on phones, so what we're going to do on your high-res desktop machine is put a toolbar above the menu bar, creating a completely bizarre interface where the "get messages" button is above the File menu, in condradiction of 35+ years of UI conventions. We're also going to make this something that isn't configurable anymore. Sure, the UI used to be super-configurable for 20+ years, but that wasn't done with javascript, so we had to remove it. You really should just use the hamburger menu instead. We like it, you see, and we're not interested in your opinion if it's not the same as ours. Mozilla knows best, you see.

* I noticed that you don't have thunderbird's adaptive junk mail filter(tm) turned on. This must be an accident and not because you have sophisticated and extremely reliable enterprise-grade spam filtering solution set up on your server, with rules to do things like move email to a specific folder and mark it as read if it's determined to be spam. So what I'm going to do with this latest thunderbird "upgrade" is just silently enable the adaptive junk mail filter(tm), and then let that decide that about 40% of the thousands and thousands of messages in your inbox are junk, and then move them into a completely different and previously-unknown junk folder that you've never seen before. Now you might wonder "hey why has that colleague I was emailling back and forth with gone silent?" and you might check your junk folder to see if maybe your spam filter has gone haywire. But his messages (and a bunch of messages from your boss) won't be there! They'll be in the new and previously-unknown junk folder that I think spam should go into! And you can spend literally hours trying to find the email that's gone missing. As a bonus, we've also made it really difficult to find that missing email by breaking the search feature, and this new junk folder isn't in your maildir structure (or even on your server!), so you can't just grep for it. Have fun!

* OMG ALL YOUR RSS FEEDS ARE BROKEN! I tried to update them twice, and got an error! This must mean that all your RSS feeds coincidentally died at the same time, and is absolutely definitely not because your internet was down for maintenance for a couple of hours. So I'm going to do the only sensible thing - mark all your RSS feeds as broken and just stop ever trying to update them again until you manually tell me to update each and every one individually. No, I will not allow you to multi-select feeds so that you can update them all at once.

* I see that you like extensions. You have several installed and you use them and rely on them daily, and have for 20+ years. So what We're going to do is turn our extensions API into a shifting quagmire of incompatibility, such that extension authors have to jump through hoops every 25 minutes to make sure their extensions are compatible with the latest thunderbird, until most of them just give up. That way we can phase out the whole extensions thing like we did with firefox, giving you an objectively worse experience.

- Did you like your email headers taking up less than 50% of the message area and having the ability to double-click on the header area to toggle between full headers and compact headers? Didn't think so.

- Aah, you want to manually sort the folders in your inbox. Nah, that would be much to useful.

- Ha! A GUI to manage your sieve filters in a user-friendly and intuitive manner? That sounds far too XUL for our tastes! Begone!

(these are just the big-deal extensions that I still miss all the time and can remember off the top of my head, there used to be a BUNCH of others, too, that I used less frequently and would struggle to remember)

* What's that? You think that interfaces should get faster as computers increase in power? Oh, my sweet summer child, have you not heard the tale of Javascript and the melting CPU? No, see, we needed to disable all those xul extensions because it was bogging us down and making things inefficient! And what we're going to do is replace that with javascript trash, so that it's a whole new level of slow and unresponsive. Did you notice how I mentioned that parsing the calendar brings the whole of thunderbird to a grinding halt, making it totally unresponsive and unusable? Yeah, see that's because all this new code is very well-engineered and async / multithreaded, you see - it can fully utilise the power of a modern processor to do much much less in much much more time.

* I can't start thunderbird maximised. Haven't been able to for a few "upgrades" now. If thunderbird is in the maximised state when I close it, when I re-open it, it starts in the maximised state, and just gives me an empty window frame which it never draws anything in. To work around this, I have to: unmaximise, then close the window, then re-launch thunderbird, then once it launches normally I can maximise it and it will work. But I just don't bother maximising it these days, because that means I have to do the unmaximise/close/relaunch thing every time I start it. Instead these days I just leave thunderbird in an unmaximised state that's almost as big as it would be if it were maximised. Hilarious incompetence.

I told you it'd be vitriol ;)

omg best thing I've read all day. Thanks for the good long out-loud laugh <3

Maybe.

I did try (politely, btw!) reporting a couple of issues on their bugtracker a long time ago, but the usual thing happened: nothing at all. IIRC there was no response of any kind. Which makes me reticent to put more time into writing more bug reports for them to ignore.

I just found out about betterbird today. It looks interesting. I might give it a try. And if I see the same issues there, maybe I'll report it on their bugtracker.

I and a bunch of others have been screaming loudly at mozilla for like 15 years now. They're not interested in hearing what we have to say. Which is why the firefox marketshare is as dismal as it is these days.

As for embarrassing Mozilla publicly, apparently their troll factory watches HN - I got downvoted a lot for describing facts.

I think the best option for me really is to just find a new mail client and be done with Mozilla forever.

I said it before, but I'll just say it again: It's a real pity, Thunderbird used to be a truly excellent piece of software once upon a time. I remember switching to it from outlook and being all "Whoa! This is great!". It was a similar experience to going from IE6 -> Firefox. How the mighty have fallen.

Exactly. It used to be good and they're making it worse every day.

Don't forget telemetry! The makers of the "privacy-focused browser" were super strong-willed about that, too.

  > they are moving more to using a javascript rendering method instead of xul

Yeah, that's what I said: garbage.

  > I am not really sure what the problems are with working with xul though

I'm sure they'll yell "for teh securitah!" in a bunch of vague fearmongering, just like they did with firefox. But the #1 and #2 problems are that it's not shiny and new and the CADT brigade[1] only knows javascript.

  > I think firefox moved off it a long time ago too

I wouldn't call it "a long time ago", but I guess that depends on your perspective.

And that's the moment when firefox became garbage - just another chrome-alike, except slower and more resource-hungry. It had been getting worse for a decade prior to that, but dropping xul and breaking a ton of my extensions and customisability was the (large) straw that broke the camel's back. Sound familiar yet?

  > I feel like thunderbird's user base is more the type to want to use thunderbird because it runs like a local first desktop style app as an alternative to using a web interface to their email. At least that's what I like about it.

Exactly. Which is why moving their UI to a worse, javascript-powered, uncustomisable, web-alike trash UI is a bad thing. And a big part of why everything they've done in the last ~10 years has been garbage. And why I'll almost certainly be switching to something that isn't thunderbird next time I'm forced to upgrade it.

(forgive my tone, nothing against you, I just get emotional when morons take an excellent piece of software I've been using for decades and turn it into broken, unusable trash)

[1] https://www.jwz.org/doc/cadt.html

Then how come everything they've done in the last 10 years has been garbage?

I agree that it should be "affect". Affect doesn't look wrong to me:

  and technology choices made in Firefox can and do affect Thunderbird, just like they effect e.g. Zen Browser or Tor Browser.

I'm no expert on the rules of english, but I think maybe it would be slightly more gramatically correct to say that "choices made in Firefox can and do have an effect on Thunderbird". I would probably have phrased it like that. Maybe that's why it looks wrong to you?

English is a bit of a bastard language IIUC, and so we accept the way you've phrased it too, but in that case it should be "affect".

I hope this helps rather than making things more confusing! ;)

Thunderbird has always been mozilla. They split it out into the other company a few years back.

DO NOT donate to Thunderbird. Let it "die". As with all of Mozilla's software, that would be the best outcome - if it does, someone who isn't totally incompetent might fork it and actually improve it.

Literally every change that's been made to thunderbird in the last 10+ years has made it worse. Mozilla are doggedly using the same philosophy as they are with firefox: "in what new and exciting ways can we make it more shit?".

There are a bunch of things that I used to do in thunderbird with no problem on much less powerful machines that I can't do today.

For example, since they decided to rewrite their perfectly-functional calendar parsing in a trash language, it now eats 100% of my CPU for ~30mins at a time trying to parse my decades-long, many-many-thousands-of-entries calendar. Then when it finishes it notices that it's been 30 mins since it synchronised my calendar, so it syncs and starts parsing all over again! This effectively locks up the whole of thunderbird, making it totally unusable. This issue has persisted for years. The solution I came up with is "stop using thunderbird for my calendar".

There's a similar fun bug which means it won't sync my contacts anymore either. A feature that I had by about 2010 which my nokia phone could manage, modern thunderbird cannot do.

If you'd like another 20 examples of how it's worse today than it was 10 years ago, just ask, and I'll write up a hundred thousand words or so of vitriol.

It's extremely likely that next time I upgrade my distro I'll be shopping for a new email client. Currently I have thunderbird marked as held so that it doesn't upgrade. When I upgrade my distro there will be a new version of thunderbird, and I'd estimate about a 90% chance that that's when I'll make my exit, after ~20 years or so.

It's sad. Thunderbird used to be a great piece of software.

Don't give mozilla your money.

There are also a couple of bug bounty websites out there for exactly this kind of thing: you and others throw some money into the pot for fixing a given bug or implementing some feature, and coders can claim that bounty once they've written the code.

I've seen a few of these sites over the years but I can't remember the name of any RN. Search engines are your friend.