I think non-webmail has been more trouble than it's worth for some time now.
The Future of Thunderbird
131–140 of 473 posts
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 send emails in plaintext, don't tell me about S/MIME.
Re: The Future of Thunderbird
#133Earlier 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.
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
#134If 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?
"Cross-platform support (Windows, macOS, Linux, and the Web)"
Re: The Future of Thunderbird
#135Uhg. 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.
Re: The Future of Thunderbird
#136I 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?
Re: The Future of Thunderbird
#137Earlier 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.
Re: The Future of Thunderbird
#138Earlier 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.
Re: The Future of Thunderbird
#139Given 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
#140Earlier 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.