Proposal to start a new implementation of Thunderbird based on web technologies
ben.bucksch at beonex.com
Wed Apr 12 14:29:19 UTC 2017
The Wanderer wrote on 12.04.2017 16:04:
> For what it's worth, I approve of the idea of rewriting from scratch
> with the aim of UI equivalence and feature parity (within reasonable
> limits, although reasonable people may disagree where those limits are),
> but I also have serious reservations
> On 2017-03-24 at 13:04, Ben Bucksch wrote:
>> Deeper goes the problem of virtual folders.
> The mention of GMail-like views leaves me cautious. Is this related to
> what GMail does with message deduplication (only store one copy of the
> message, and display it in multiple locations), or is it something
> different and more folder-centric rather than message-centric?
> If the latter, this is probably fine, but the former could be
> problematic. So far as I can tell / am aware, Gmail appears to do its
> message-level deduplication by treating messages with the same
> Message-ID as being identical and discarding any duplicates, even though
> in some cases (e.g. sending an E-mail to a mailing list and then
> receiving a list-modified copy back to yourself) the second message with
> the same Message-ID may in fact include important differences.
Yes, I am not talking about message de-duplication, but operating on the
folder level. I want to have virtual folders that e.g. show me all new
mails in all folders (or a reasonable subset that I subscribed to and
can open). Or see all mails that are flagged "TODO" or similar.
Once we combine several folders, there will certainly some kind of
de-duplication, and most likely based on the message-ID. But that will
be an optional additional feature. You will certainly still have the
ability to see only a single IMAP folder or local mbox, and all messages
in it, like you do today in Thunderbird. Virtual folders would be an
additional feature on top. But I want them to be usable and fast, not
like in today's Thunderbird.
> Assuming that sort of issue (the question of what criteria to use to
> determine message uniqueness) can be addressed, however, I approve of
> this concept.
>> 0.8. Be close to the existing Thunderbird
>> Even though we write almost all code from scratch, we will save a lot
>> of time by having a clear goal: We want to replicate the current
>> Thunderbird, from an end user perspective. That means, the user will
>> find the same 3-pane window layout, the same way how folders and
>> message lists and the thread pane operate. The theme will be similar.
>> Existing Thunderbird users should feel right at home.
>> We retain the overall UI and most features and qualities like
>> performance, even if we do not copy all little details.
> What about those of us who prefer a Thunderbird UI more like that which
> came *before* "current Thunderbird", and apply various hacks (add-ons,
> userChrome.css, et cetera) to restore aspects of that UI? That is, those
> who may have felt "right at home" in a previous Thunderbird version, and
> felt that a later version took that home away from them.
Which version did you like, and why?
I always liked userChrome.css, and we can preserve that feature, given
that the style will still be based on CSS.
> Will this rewrite take those people into account, and either provide
> options for such UI variations
Concretely, I plan eventually 3 different UIs:
* Imitate current Thunderbird
* Make a new, fresh UI for those who have not used email clients
* Mobile UI for smartphones and tablets.
That will be down the road. We should not get distracted. But the
technical possibility should exist.
That possibility currently does not exist in Thunderbird. There's too
much logic mixed in the UI to make it feasible to make a different UI
without outright forking.
> (Examples fall into at least two categories: modifications which are
> possible in current Thunderbird, and ones which are not. Examples of the
> former which I change for my own Thunderbird include the To/CC portion
> of the compose UI, and zebra-striping of the message list / thread pane;
FWIW, zebra-striping of the message list / thread pane should be a trivial change in userChrome.css. And it will probably be part of one of the new UIs anyway.
More information about the tb-planning