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

The Wanderer wanderer at fastmail.fm
Wed Apr 12 15:22:15 UTC 2017


On 2017-04-12 at 10:29, Ben Bucksch wrote:

> The Wanderer wrote on 12.04.2017 16:04:

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

That seems entirely reasonable.

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

Depending on how this is implemented in practice, it's still something I
could be mildly concerned about, but that does sound as if it could be
reasonably good overall.

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

Essentially, Thunderbird 2, with the exception of the fact that thread
sorting was by (approximately) "order in which the thread-root message
was moved into this folder" rather than "date of the thread-root message".

"Why" is more complicated, and would probably require examples and
side-by-side comparisons. I could easily enough list off the changes I
dislike and what I do to (try to) revert them (I have a notes file for
whenever I need to spin up a new TB install or profile for myself), and
start explaining the whys in each case, but that seems like it would be
a tangent to the thread.

> I always liked userChrome.css, and we can preserve that feature,
> given that the style will still be based on CSS.

That says a lot about how much ability to hack the UI locally there will
be, just as a baseline.

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

Assuming I understand what you're talking about (which I think I do),
that sounds reasonable.

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

At the moment, it is the following snippet:

#threadTree > treechildren::-moz-tree-row(even) {
  background-color: -moz-oddtreerow;
}

The "odd" vs. "even" mismatch is because the alternative needs several
additional CSS overrides (with !important), overriding one another in
succession, to produce the desired result in all cases; I'm not clear
whether Thunderbird 2 shaded odd rows or even ones, but the result is
functionally the same regardless, since I'm rarely at the "zero" end of
the list in any case.

This was only an example, however. (The compose-UI facet can also be
reverted by userChrome.css hacks, but it takes _much_ more extensive
code, and I just use something I found in a forum which someone else
wrote.)

-- 
   The Wanderer

The reasonable man adapts himself to the world; the unreasonable one
persists in trying to adapt the world to himself. Therefore all
progress depends on the unreasonable man.         -- George Bernard Shaw

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://mail.mozilla.org/pipermail/tb-planning/attachments/20170412/81009959/attachment.sig>


More information about the tb-planning mailing list