Re: Thunderbird’s future: a modern addressbook
neandr at gmx.de
Wed Mar 14 23:04:08 UTC 2018
Different tb-planning/devmail/etc messages and also personnel statements
of the Council Candidates spoke about the necessity to re-new the legacy
TB/Addressbook. But there were not much concepts with functional or
technical background, the look and feel, not even any activity plan /
perspective for it.
So glad to see a TB/Addressbook discussion was started with:
On 12.03.18 17:28, TT Mooney wrote:
> The current address book in Thunderbird is barely usable. There are a
> couple extensions which try to work around the problem, but they’re
> not 100%. Not that I’m complaining about Cardbook, or anyone else
> working on solving the problem — it’s the best we have now, and I’m
> happy to have it.
Cardbook -- evolved over the last few years (2-3 ?) -- shows how much
improvement are possible to get a significant enriched addressbook.
Philippe -- the author -- wrote:
On 14.03.18 14:40, CardBook wrote:
> CardBook starts to be a pretty decent address book but I don't know if
> css, xml bindings and an indexedDB database, so no "new technologies".
> It is relatively handy until 10 000 contacts but above writing an
> email is slow.
And he himself pointed to some important facts for any further work on
the re-new of the TB/Adressbook (TB/AB).
1. A new TB/AB was said to be an ideal part to see how modern technique
can be used
> It's intended to serve as a technical experiment for a rewrite
> using web technologies
Clearly Cardbook doesn't fulfill this point.
2. TB performance should not be degraded by any subsystem -- or better
said: the degradation should be a minium. One of the strong points
of the legacy TB/AB is performance, and the trophy goes to: the
(hated) Mork db. So any replacement has a challenge here.
Cardbook doesn't do well about that. I have seen massive delays at
TB startup already with 3.000 contacts. Not sure if it's building
the db at startup or handling the contacts table. Also it's
interesting to see Cardbook is using XUL for the table and that
should be fast.
What happens with a change to using web technologies (JS/HTML/CSS)?
A concept which could help here is described by Ben Bucksch:
> "fastlist <https://github.com/benbucksch/trex>" TRex - HTML UI
> markup language and library to develop GUI apps
More imporant point for a new-TB/AB:
3. A modern addressbook (using web technologies) should overcome legacy
layout ideas. Clearly our legacy TB/AB UI is bound to a desktop
implementation. If a new-TB/AB project is meant "to serve as a
technical experiment" we should experiment also with alternative
layouts and handling, not only bound to mouse and menu and pulldown
and such. Do will need a full list/table to show the contacts?
Categories instead or additionally to Contact Lists (see also next
4. Last not least TB/AB functionality: Mike Conley helped for a
students project in 2016 and he reworked some of his interesting
aspects it. Worth to take it as a basic also in 2018.
See here: https://github.com/Thunderbird301/react-addon/wiki
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the tb-planning