Proposal to start a new implementation of Thunderbird based on web technologies

[Ben Bucksch]

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

nod

> 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.