News for hackers. Stuff that matters.
Re:Our plans for Thunderbird on Android by javajosh on Monday June 13, 2022 @10:12AM (#31725854)
As an aside, Thunderbird occupies that uncomfortable space of software that is libre, but seems so bloated and complex I don't want to install it, let alone work on it. I'm not sure if that perception is "accurate" (which of course depends on how you define things). But think of OpenOffice/LibreOffice. It's a huge, classically written C++ blob that is hard to check out hard to build and hard to contribute to. Yet, its very existence undermines the motivation to start something new.

Surely there is a space for minimalist office suites and email clients, written starting with a browser as a jumping off point, rather than a compiler? I guess I'm arguing for an Electron-based docs/sheets/email/calendar using modern software best practices, and great components. An email client should be a webview + sql-lite, no? And (for office docs) maybe with a more thoughtful file format, like a simple html subset. Does this exist? And if so where do I get it? (And maybe there are better "jumping off points", like VSCode, which is itself a specialization of Electron).

Re:Our plans for Thunderbird on Android by ssl232 on Monday June 13, 2022 @10:24AM (#31726054)
I don't personally find Thunderbird to be bloated, especially compared to e.g. KMail (which even a few years ago was still buggy and unstable for me). "Complex" might be reasonable but I expect a lot of that comes from email protocols themselves being convoluted and weird. In fact, I think email's own complexities are what destroy most peoples' motivation to make a shinier, more modern tool.

I will say I do have a massive, single gripe about Thunderbird, and while it's a trivial thing it's also - and in part because it would be so easy to fix - massively infuriating: the default keybindings for archiving, deleting, marking read emails etc. are, astonishingly, single characters. I've lost count how many times I didn't correctly highlight the filter textbox and started to type a search query, which instead had the effect of randomly archiving, deleting and marking read the top N emails in my inbox before I notice. This is literally why we have control characters, so I find it incredible that this is not only the default behaviour but unchangeable without a plugin [1]. I still find the tool very useful in every other way but I can't believe something so obviously wrong has not yet been fixed after what must be at least 20 years of this software tool being available.

[1] https://addons.thunderbird.net/en-GB/thunderbird/addon/tbkey...

Re:Our plans for Thunderbird on Android by zasdffaa on Monday June 13, 2022 @11:34AM (#31727020)
Same (edit: no permanent damage done yet but now I keep tbird minimised to prevent this kind of bad stuff from keybindings).

And I went back to webmail for 6 weeks because when tbird upgraded itself, the new OAuth (I think) stuff needed cookies, which I didn't allow so just couldn't connect and just kept failing without any explanation. That took half a day of chasing down.

And if I get a calendar invite it just tells me "all calendars are currently disabled. Enable an existing calendar or add a new one..." without 1) saying why or 2) saying how (and why would it not just use the one it's literally showing me while saying they're disabled).

And it doesn't recognise domains correctly, and it strips out inline attachments (yes, really), and fucks up formatting (turns html mails into messed up plain text), and it's caused me so much grief since its install, can anyone suggest a competent, reliable email client that has a focus on quality and not a focus on stupid UI crap that makes it feel like someone's personal side-project. I'd gladly pay .

Re:Our plans for Thunderbird on Android by xg15 on Monday June 13, 2022 @10:25AM (#31726067)
> Surely there is a space for minimalist office suites and email clients, written starting with a browser as a jumping off point, rather than a compiler?

As a user, I'd prefer a minimalist office suite that still doesn't have the browser as a starting point.

I think a browser is actually not a good UI for an office programs, because it really awkwardly competes with your own document model: HTML at its core still wants to be a document, except probably not the document you want to have. So you have to reimplement document APIs on top of already existing document APIs.

E.g., tracking and working with selected text is extremely important in office programs, but a browser already has built-in management of text selections: Except, the built-in management doesn't know which part is your chrome and which is your document, making you to either implement your own selection mechanism in addition to the browser's or handle all kinds of really weird special cases.

And so on...

Re:Our plans for Thunderbird on Android by javajosh on Monday June 13, 2022 @11:13AM (#31726724)
It is interesting how people serious about text editing always seem to end up throwing away most of the DOM and use Canvas or SVG (e.g. CodeMirror). But even then the browser brings a lot to the table in terms of a common runtime.
Re:Our plans for Thunderbird on Android by lmm on Monday June 13, 2022 @08:42PM (#31733488)
It brings a runtime that's easy to distribute to, that's pretty much it. I think there are plenty of runtimes out there (e.g. Java Web Start + JavaFX) that are just as good if not better, but they don't have anything like the same installed base (especially in locked-down corporate environments where you can't just distribute your thing bundled as an executable, which is where a preinstalled runtime really matters) as the browser.
Re:Our plans for Thunderbird on Android by jcranmer on Monday June 13, 2022 @11:22AM (#31726864)
> Surely there is a space for minimalist office suites and email clients, written starting with a browser as a jumping off point, rather than a compiler?

As far as email clients go, Thunderbird is literally what you are suggesting. Thunderbird is essentially the Firefox web browser, with all of the browser front-end code stripped off, and an email client dropped in its place.

Re:Our plans for Thunderbird on Android by gspr on Monday June 13, 2022 @10:30AM (#31726147)
> Surely there is a space for minimalist office suites and email clients,

FWIW, my email life improved massively when I left the likes of Thunderbird and KMail behind for the simplicity of mu/mu4e [1]. I hear similarly stellar things about Notmuch [2]. I'm never going back to an email client that even thinks about itself in relation to "office suites".

(For casual reading, and very rare composing, on a phone, k9 works passably well for me [3])

[1] https://www.djcbsoftware.nl/code/mu/

[2] https://notmuchmail.org/

[3] https://k9mail.app/

Re:Our plans for Thunderbird on Android by throwaway892238 on Monday June 13, 2022 @10:54AM (#31726449)
I will not use an Electron app if I can find literally any other kind of app. Bloated, slow, buggy, difficult desktop/Linux integration.
Re:Our plans for Thunderbird on Android by mid-kid on Monday June 13, 2022 @10:25AM (#31726078)
> written starting with a browser as a jumping off point

That's thunderbird for ya.

Really the only web-browsery thing a mail client needs is rendering of the email itself (if it's not just plain text, HTML email is an extension!), for which, sure, it's a better idea to use an existing webview. But for the rest of the interface and logic? No.

Re:Our plans for Thunderbird on Android by sph on Monday June 13, 2022 @11:41AM (#31727096)
To be fair, if you're bundling a web browser to render emails, you might as well write your whole UI out of it. Of all use cases of Electron, an email client is probably the least offensive.
Re:Our plans for Thunderbird on Android by will0 on Monday June 13, 2022 @10:17AM (#31725943)
Arguing for electron on hn? Brave.

(I like electron fwiw, it's enabled me to have a desktop experience with applications that would've otherwise never come to linux)

Re:Our plans for Thunderbird on Android by javajosh on Monday June 13, 2022 @10:25AM (#31726064)
>Arguing for electron on hn? Brave.

Thank you for recognizing this. I admit I had a moment of doubt before pressing "submit". :)

Re:Our plans for Thunderbird on Android by viraptor on Monday June 13, 2022 @10:40AM (#31726291)
Keep in mind electron is just one way to go. There's Tauri for example, offering a very similar solution.
Re:Our plans for Thunderbird on Android by ape4 on Monday June 13, 2022 @10:34AM (#31726194)
Email clients need to display full html/css/js now
Re:Our plans for Thunderbird on Android by subsection1h on Monday June 13, 2022 @10:40AM (#31726298)
Which email clients don't block JavaScript by default? I quickly searched just now and couldn't find any.
Re:Our plans for Thunderbird on Android by ape4 on Monday June 13, 2022 @07:32PM (#31733031)
yes by default, which means it can be enabled
Re:Our plans for Thunderbird on Android by uneekname on Monday June 13, 2022 @10:20AM (#31725988)
I agree with you. It seems like the self-hosting community is getting a decent bit of attention right now, and the ability to deploy browser-based applications is the way to go for many FOSS projects.

I think NextCloud [0] has a few apps that do G Suite-type stuff, but I don't have experience using them. Etherpad [1] also seems really good, I've used it in a few Zoom calls and the experience was smooth. Personally, I'm looking for a Google Photos alternative that's stable enough for my parents to use.

[0] https://apps.nextcloud.com/

[1] https://etherpad.org/

Re:Our plans for Thunderbird on Android by TheFreim on Monday June 13, 2022 @10:18AM (#31725957)
> but seems so bloated and complex I don't want to install it

I don't use thunderbird currently, but have for /very/ short amounts of time in the past. What seems bloated about it? For reading and writing e-mail it worked fine and other features seemed to stay out of the way in menus I didn't need to use.

Re:Our plans for Thunderbird on Android by mempko on Monday June 13, 2022 @10:28AM (#31726114)
Thunderbird is built on top of a browser. Most code for it's functionality isn't C++. Correct me if I'm wrong.
Re:Our plans for Thunderbird on Android by mook on Monday June 13, 2022 @11:16AM (#31726764)
Last I checked (which was a while ago), while the UI is in XUL / JavaScript, the bulk of the mail handling (POP/IMAP/SMTP, MIME parsing, etc.) was still in C++ that was extremely complex and hard to port to JavaScript. There was an attempt to rebuild a mail client in JS for FirefoxOS (the mobile phone thing that is now mostly KaiOS), but that's not used in Thunderbird as far as I know.
Re:Our plans for Thunderbird on Android by jcranmer on Monday June 13, 2022 @11:24AM (#31726889)
The backend stuff is being (slowly) ported to JS from C++. SMTP should be implemented in JS now, I don't know about the other parts.
Re:Our plans for Thunderbird on Android by yjftsjthsd-h on Monday June 13, 2022 @10:20AM (#31725994)
> Yet, its very existence undermines the motivation to start something new.

Does it? There was just an article about claws mail on HN. Or on the office side, gnumeric and abiword seem decent enough.

Re:Our plans for Thunderbird on Android by zbuf on Monday June 13, 2022 @07:29PM (#31733007)
> software that is libre, but seems so bloated and complex I don't want to install it, let alone work on it.

I feel like we've lost some of the point of open source. My rose-tinted glasses are probably in play, but I used to be able to use software, build it and modify it.

Today, the idea of being a "casual" contributor seems to be lost. Things need a huge build process, and some kind of management organisation. The emphasis used to be on contributing patches, not funding.

Re:Our plans for Thunderbird on Android by lmm on Monday June 13, 2022 @09:08PM (#31733646)
> As an aside, Thunderbird occupies that uncomfortable space of software that is libre, but seems so bloated and complex I don't want to install it, let alone work on it. I'm not sure if that perception is "accurate" (which of course depends on how you define things). But think of OpenOffice/LibreOffice. It's a huge, classically written C++ blob that is hard to check out hard to build and hard to contribute to. Yet, its very existence undermines the motivation to start something new.

I think what those have in common is being corporate codebases that were "dumped" as open source. If you look at the equivalents that were built as open-source from day 1 - KMail, Konqueror, and KOffice - you find something that while still C++ is much cleaner and better structured, since they were always meant to be maintained by a distributed collaboration rather than a small team of l33t h4x0rs.

> Surely there is a space for minimalist office suites and email clients, written starting with a browser as a jumping off point, rather than a compiler? I guess I'm arguing for an Electron-based docs/sheets/email/calendar using modern software best practices, and great components. An email client should be a webview + sql-lite, no? And (for office docs) maybe with a more thoughtful file format, like a simple html subset. Does this exist?

I don't think browser-based is the right direction, and I actually think browser-based may detract from having good standard UI component libraries, since the browser itself tends to fall into the trap you mentioned - browser-native components are simultaneously not great, but imposing and complex enough to suck the oxygen away from alternatives. But I agree there's a lot of value in using existing frameworks and libraries to develop your applications, and definitely something that contributes to both OpenOffice/LibreOffice and Mozilla-family applications being as complicated as they are is the fact that they include their own one-off GUI frameworks. (In fairness Mozilla did originally make a legitimate attempt to make their GUI framework an actual first-class GUI framework that could be used for other applications with XULRunner etc., but those days are long gone now). Again this is somewhere where I find KDE family applications shines in comparison - everything is properly layered between the libraries, frameworks, and applications, and the libraries actually see reuse across a wide range of applications.

Re:Our plans for Thunderbird on Android by the__alchemist on Monday June 13, 2022 @10:58AM (#31726516)
How about a minimalist office suite and email suite written in modern C++ or Rust? Performance and responsiveness are important!
Re:Our plans for Thunderbird on Android by javajosh on Monday June 13, 2022 @05:23PM (#31731946)
Sure, it's just there's a lot of distance between compiler and browser. I'd argue the first thing to do is write a browser in Rust (I know Firefox has real components in it).
Re:Our plans for Thunderbird on Android by tomcatfish on Monday June 13, 2022 @07:28PM (#31733004)
I had the strangest issue with Thunderbird during the last big upgrade, where it took my PGP key out of gpg (deleting the key from the store in the process), and stored it in Thunderbird with no protection. I must have read an encrypted email for it to have used the password, but I have no idea how this happened, and do not click "Yes" on boxes without reading them thoroughly. It took me a month of my PGP key apparently sitting unprotected before I noticed.

The fact that Thunderbird does stuff like this to me really weirds me out, despite mostly loving the program.

Re:Our plans for Thunderbird on Android by account42 on Tuesday June 14, 2022 @05:48AM (#31736654)
At least it managed to migrate your key. I just stopped encrypting/signing mail when it stopped working after the forced migration from the Enigmail add-on. Can't be bothered to look into fixing it when noone cares about PGP signurates for mail anyway.
Re:Our plans for Thunderbird on Android by subsection1h on Monday June 13, 2022 @10:35AM (#31726207)
> An email client should be a webview + sql-lite, no?

I strongly prefer Maildir. https://en.wikipedia.org/wiki/Maildir

Re:Our plans for Thunderbird on Android by mxuribe on Monday June 13, 2022 @02:01PM (#31729085)
I'm not a Thunderbird expert...but I seem to recall hearing some where that some desktop mail clients - especially Thunderbird - who use Maildir tend to also leverage sqlite (as an over-layer) to aid with content indexing and search...? If my recollection is right, that's kinda the best of both worlds: separate files (maildir) but speedy content search. :-)
Re:Our plans for Thunderbird on Android by sam_lowry_ on Monday June 13, 2022 @11:16AM (#31726763)
Maildir vs mbox is like emacs vs vim.
Re:Our plans for Thunderbird on Android by indymike on Monday June 13, 2022 @10:17PM (#31734075)
Not really. Maildir does away with a host of problems ranging from file locking (the entire mbox file must be locked during writes, where maildir only requires the message being operated on the be locked), to network compatibility (no transporting a 4gb file back and forth), to corruption issues (mostly due to file size).
Re:Our plans for Thunderbird on Android by e12e on Monday June 13, 2022 @12:29PM (#31727779)
> Surely there is a space for minimalist office suites and email clients

It might be interesting to try and port/rewrite siag/scheme in a grid to racket (or Julia...)?

It's the only "light-weight" office suite that comes to mind...

Re:Our plans for Thunderbird on Android by lkxijlewlf on Monday June 13, 2022 @11:35AM (#31727035)
> I guess I'm arguing for an Electron-based docs/sheets/email/calendar using modern software best practices, and great components.

Nope. Totally not interested in anything Electron...