Live data from Hacker News

The Future of Thunderbird

blog.thunderbird.net

131–140 of 473 posts

Re: The Future of Thunderbird

#131

I think non-webmail has been more trouble than it's worth for some time now.

Webmail is a nice option to have if you want it. Email should continue to be a separate set of protocols targeted at that one application. I'd much rather see webmail disappear as an option than standard email servers and clients.

Re: The Future of Thunderbird

#132

> Why does Thunderbird look so old UI isn't a fashion show. I'd much rather have a UI that looks older but is comfortable to use than something trendy.

It doesn't look old, it looks overloaded and inconvenient. HN UI looks old, but it's the most convenient UI to use.

I'm still on TB68 because Enigmail was *broken after, and I think the UI is convenient except adding new accounts and managing SMTP servers.

*I send emails in plaintext, don't tell me about S/MIME.

Re: The Future of Thunderbird

#133
post #102

Earlier quoted context omitted.

This is a great example of the kinds of problems they're trying to tackle. This shouldn't be an issue. Just use sqlite or similar.

At least on Linux, I think the mbox vs maildir is an interoperability thing. I can access folders created by thunderbird, or existing user local ones in any local mail client or remotely through IMAP. It may be they don't want to break those external tools.

So have a checkbox for "also persist mailbox in an interoperable format", that then lets you choose mbox or maildir; where it's going to save the data for its own use in SQLite either way; only save in that "interoperable format" asynchronously in the background, and on quit (just like e.g. a Redis RDB file); and, if enabled, also scan the interoperable backing store for changes made on startup, to apply them to the internal, canonical store.

FYI, iTunes.app (or whatever it's called now) for a long time had a legacy XML-file representation of the music library "for interoperability", that you could enable to be persisted to disk alongside its newer, binary DB file; when enabled, it worked exactly like this.

Re: The Future of Thunderbird

#134
post #28

If they are looking for paths going forward, I hope they investigate what PopOS is doing with rust (COSMIC) [0] and Iced [1] (cross platform ui library). [0] https://www.phoronix.com/news/COSMIC-Desktop-Iced-Toolkit [1] https://github.com/iced-rs/iced

I read "A cross-platform GUI library for Rust" but never saw any specifics. Is this targeting MacOS, Windows, Linux?

From [1] https://github.com/iced-rs/iced it says:

"Cross-platform support (Windows, macOS, Linux, and the Web)"

Re: The Future of Thunderbird

#135

Uhg. This is the exact opposite of what direction I want from Thunderbird. I want it to remain stable. I want it to remain looking like an email client I run on my native OS. I do not want giant white-space webshit design and an entire rebuild that makes all my extensions and well trained spam detection .dat unusable. Please stop changing things just to change. Thunderbird works.

Unfortunately the web keeps changing. Firefox is trying hard to remain relevant and needs to be flexible with their code-base. So Thunderbird does not live in a stable world.

Re: The Future of Thunderbird

#136
post #79

I skimmed the article and the video, but I couldn't find exactly where they mention what this new direction will be and what technologies will it use?

Yeah it seems like they're announcing their high-level aspirations, so not really note-worthy yet.

Re: The Future of Thunderbird

#137

Earlier quoted context omitted.

It doesn't look old, it looks overloaded and inconvenient. HN UI looks old, but it's the most convenient UI to use.

I'm still on TB68 because Enigmail was *broken after, and I think the UI is convenient except adding new accounts and managing SMTP servers. *I send emails in plaintext, don't tell me about S/MIME.

Enigmail functionality is now built-in, it's quite nice!

Re: The Future of Thunderbird

#138
post #63
post #40

Earlier quoted context omitted.

> UI isn't a fashion show. Yes, it is. At least, it is for UI designers.

Also for the users. For my part, I appreciate if stuff looks modern. I understand the whitespace madness complaints, but a software which looks like 1999 is not something I want to work with. There is a degree of modern style needed because Thunderbird does not exist in a vacuum. Windows evolved, macOS evolved, iPhone/Android look different than 1997 Windows .. which Thunderbird looked like the last years.

For anyone else who likes 1997-Windows-style software and can tolerate shareware, try Becky! Internet Mail: http://www.rimarts.co.jp/becky.htm

Re: The Future of Thunderbird

#139
The highest priority IMHO is security.

Given how a targeted email can reach someone wherever they are (and spam can conceal mass exploits), frequent security updates are the wrong mindset.

The mindset of one necessary security update should be, OMG, we messed up badly, we need to fix and mitigate, and immediately figure out how never to need another security update, ever again.

Web browsers, OTOH, are hopeless for security right now, due to monstrously big-moat standards. But email MUAs (with addressbook, calendar, and maybe chat) are a much-much simpler problem, also high-value, and maybe the place to set a good example.

If someone objects "but we will always have constant stream of security vulns, because we need these 1,000 libraries, many of which are hopeless"... maybe that's not true. Implementing email is conceptually very easy, and you don't need all that much more than conceptual to get all the benefit that users actually want from email.

(Even incoming HTML multipart content-types, which are often a nightmare of BS generated by some MS program, can be transformed to a vastly simpler and cleaned-up form, enabling a very simple and secure rendering/editing engine, with zero baggage from hopeless browser engines.)

Re: The Future of Thunderbird

#140
post #102

Earlier quoted context omitted.

This is a great example of the kinds of problems they're trying to tackle. This shouldn't be an issue. Just use sqlite or similar.

At least on Linux, I think the mbox vs maildir is an interoperability thing. I can access folders created by thunderbird, or existing user local ones in any local mail client or remotely through IMAP. It may be they don't want to break those external tools.

You can asynchronously generate the mbox/maildir data.
Post reply on HN