Exactly. Well said, @antonis. Every time I hear the phrase “make it more modern,” I just assume it to mean “remove a lot of useful settings, or bury them under endless sub-menus, reduce font contrast to pale gray on even paler gray, and inject a lot of blank space around everything… you know… make it look nice for phone screens.”
Although I do understand the developers’ reasoning for rebuilding the code. What would have been nice is if they could have made the new layout a setting that users could enable themselves, to “check out the new look,” or disable to keep the UI as it was. But maybe it wasn’t possible to keep everything as it was, given the new code.
They did say they were going to try to approximate the former look and functionality, so I don’t know how some of those jarring design changes made it into the mix.
By the way, another annoyance: I have dark theme enabled, but when I launch Thunderbird, it first displays as bright white before quickly switching to black.
OK, as an exercise, I updated one of my other machines and followed the list of changes I made (see above) to make sure it was complete. I adjusted or added some edits to that list, so check them out if you’re interested.
That wouldn’t surprise me at all - particularly as at V1.0 of a rewrite. Achieving compatibility with a former look may be something that is only arrived at over time i.e. incrementally over the next 3 years.
I still look forward to
an adaptable and extremely customizable user interface
Within limits that should keep everybody happy - but it is an objective over 3 years.
In principle, this is a good thing i.e. Thunderbird will still work on the desktop/laptop but it will work better than it currently does on a touchscreen tablet and better than it currently does on a smartphone. (They also observe that they want to make Thunderbird fully compatible with current accessibility technology, which was probably not such a requirement, or even a possibility, back in the stone age when Thunderbird started.)
I’m pretty confident that Rome won’t be built in a day.
I’m not disagreeing with that claim but where specifically did they say that?
It is perhaps implied by “extremely customizable”.
I probably gleaned that from a separate blog post of theirs; in the comments, Jason Evangelho replied to a commenter’s concerns (“…I hope it can be made to look as much like the current version as possible…”) with this:
Jason Evangelho wrote on July 13, 2023 at 18:08
You’ll be relieved to know that 115 still mostly defaults to the layout and presentation you’re used to from version 102. It takes a few toggles and changes to get the “Supernova” look. And we did this because we understand some of our users have been used to that general paradigm for the last 20 years.
We also have no plans to retire the “legacy” views, although the defaults may change in the future.
EDIT: Fixed the link, which was not for the blog post I mentioned.
A very good thing, I would say.
Rust, like Go is a memory safe language (unlike C, java) An enormous progress - so many bugs due to memory unsafe programming languages like C (which the entire Linux ecosystem is built on)
It remains to be seen what they mean by “implementing”? Which part of TB would be rusted? Obviously not the entire code - this would be herculean work. And the problem here, is that if you have some part of the Rust code that depends on any C library - well, nothing is memory safe anymore…
At the risk of starting a my-programming-language-is-better-than-yours war … to the best of my knowledge, Java is memory safe. (There is no “free” at all in Java - so there are no use-after-free errors, no double-free errors - and all memory is type safe - and all array accesses are checked … . So large classes of programming errors are simply not possible, as compared with languages like C.)
If you look more at the report it seems like what they mean is: They have changed Thunderbird so that Rust code can be integrated within Thunderbird and they did that in order to have safe support for Microsoft Exchange-related protocols. But I don’t really know the details (and Exchange support is not needed by me).
Also, I should note that Kotlin (a Java alternative that is used by many/most Android devs) is also memory-safe. Here is the cloc decomposition for K9-Mail / Thunderbird-android from GitHub - thunderbird/thunderbird-android: K-9 Mail – Open Source Email App for Android . You’ll note that in terms of actual code (Kotlin and Java), the project is written in memory safe languages.
My understanding is that if you want to write an app to run under Android then it must be memory safe because it must fall under an even broader kind of safety i.e. that it respects the restraints of its environment and cannot escape from the environment - which would be much harder to enforce if the programming language is not memory safe. (It is the same under iOS but the approved or encouraged programming languages are, I think, different ones.)
Maybe. Certainly Java and/or Kotlin are preferred. That said, applications are allowed to have native C/C++ libraries … which weakens/defeats the memory-safe advantages (Add C and C++ code to your project | Android Studio | Android Developers). I think the main aspect of application safety in regard to memory is enforced by the OS ( https://source.android.com/docs/security/features ) — each app is run under a unique UID and is effectively isolated with resource availability managed via SELinux MACs …
My bad here, I guess!
Some intox from Tamago unikernels on USB Armory devices, which I love and use for different security purposes. I picked up from these guys that Go was memory safe and java, C# and Python were not. But I didn’t check those assertions…
I made the list into a wiki post, so others may choose to maintain it if they want to. Past this point, I am likely to self-host my own email server in spite of its various challenges, but I will strive to reduce its maintenance as much as possible while prioritizing security and privacy.
