Thunderbird++ for each of the four major components
R Kent James
Here's my personal understanding/guess of where we are likely
heading with each of the 4 major pieces of Thunderbird. What's new
here is mostly discussing the "other" pieces beyond email, as most
of the Thunderbird++ discussion so far has implicitly focused on
email. Note in all cases, it may be possible to incorporate
portions of the new work in the existing Thunderbird, but that is
not a primary goal. Retaining existing users IS a primary goal.
Mail (and related views): There will be a servo-like rewrite of the major email portions (accounts, servers, folders, messages, views) using web technologies. This will likely be mostly driven by a paid team.
Contacts: will be a complete rewrite in web technologies.
I am working toward figuring out how the Cardbook, vContacts, and
my group (Caspia) can work together on this. It is likely this
will be done mostly by volunteers.
Calendar: will likely be a line-by-line conversion from XUL and the Mozilla Platform to web technologies. I have another Caspia team that might work on this, but the overall task is probably too big for them alone.
Chat: I have heard nothing from this team, but I would guess this is also likely a line-by-line conversion from XUL and the Mozilla Platform to web technologies.
It would be good to hear from the Chat and Calendar teams about
possibilities for those subsystems, so far I am guessing. I am
also introducing here the idea that the "rewrite from scratch"
proposal is I believe mostly focused on email only, which might be
worthy of discussion.
:rkent
Gervase Markham
> Here's my personal understanding/guess of where we are likely heading
> with each of the 4 major pieces of Thunderbird. What's new here is
> mostly discussing the "other" pieces beyond email, as most of the
> Thunderbird++ discussion so far has implicitly focused on email. Note in
> all cases, it may be possible to incorporate portions of the new work in
> the existing Thunderbird, but that is not a primary goal. Retaining
> existing users IS a primary goal.
Thunderbird lasted for many years without either capability. I would
strongly suggest that neither is part of a minimum viable product for
TB++. We can't forbid people from working on them, but if those people
are also capable of contributing to Mail and/or Contacts, then every
hour spent on them makes the MVP an hour of work further away.
Firefox (and, even, Thunderbird!) demonstrated that a subset of users of
a more complex product (the Mozilla Suite) are happy and find it
refreshing to use a simpler product which does one thing well. That
should be the initial path to gaining users for TB++ - an explicit
refutation of the idea that (initially at least) it provides feature
parity, to correctly set expectations.
If we say "We're rewriting Thunderbird; we'll let you know when it's got
feature parity, and you can come and try it out", that's a path to low
usage, low testing and failure IMO.
Gerv
_______________________________________________
tb-planning mailing list
tb-pl...@mozilla.org
https://mail.mozilla.org/listinfo/tb-planning
Matt Harris
On 18/04/17 05:53, R Kent James wrote:Here's my personal understanding/guess of where we are likely heading with each of the 4 major pieces of Thunderbird. What's new here is mostly discussing the "other" pieces beyond email, as most of the Thunderbird++ discussion so far has implicitly focused on email. Note in all cases, it may be possible to incorporate portions of the new work in the existing Thunderbird, but that is not a primary goal. Retaining existing users IS a primary goal.Do we have data on what proportion of existing users use Calendar? Or Chat? Thunderbird lasted for many years without either capability. I would strongly suggest that neither is part of a minimum viable product for TB++.
What is the proposed selling point of Thunderbird++ on Windows anyway? What is the killer feature that will grow our user base?
As for data, really I think we have little or no idea what our users use, or what features they despise or want. (there is a wealth of telemetry data, but accessing it is beyond me.) WE do apparently have data indicating Lighting has some 5.5 million current installs. Even before it was bundled it was the most popular add-on by a very big margin.
- I can tell you is that I see a lot of
screen shots in support, and most have a menu bar. But I have
no idea if that is turned on because they are having issues or
the average user likes having a menu bar. I know I do because
it is faster that the half crippled appmenu.
- I do know that the app menu is far from intuitive (what is this with hover menu's or a menu that differs if you click the > or the text.)
- I do know that for most of the last
decade users have asked for a migration process that migrates
their profile from old to new devices. They expect an export
and import option to do that with. Will Thunderbird ++ ship
with that as a minimum? perhaps as a selling point.
- I do see a small but continuous stream of issues in Support with chat and News (NNTP). Mostly looking for long standing bug fixes, given Mozilla ignored that module as much as they could get away with. Are there 10 or 10 million users of NNTP. I have no idea.
- I do think that a very significant proportion of our users fall in the small business group. The single user with a web site looking for automated responses to web site emails (usable templates anyone) and people organizing community events like club meets etc. (Mailing lists that self audit for bad addresses) and mail merge
Regards
Matt
Gervase Markham
> I strongly suggest that anyone thinking a mail client without a calendar
> will fly should listen the the users a little more. Even the cheapest
> phone has a calendar. The windows 10 mail app has a calendar.
and "you don't have a calendar".
I use Google Calendar Tab, which must be 100 lines of code, and does
most of what one wants from calendar integration. A few more hundred
lines of code and it would do everything.
> What is the proposed selling point of Thunderbird++ on Windows anyway?
> What is the killer feature that will grow our user base?
> * I do see a small but continuous stream of issues in Support with
> given Mozilla ignored that module as much as they could get away
> with. Are there 10 or 10 million users of NNTP. I have no idea.
Nomis101 🐝
>
> Thunderbird lasted for many years without either capability. I would
> strongly suggest that neither is part of a minimum viable product for
> TB++. We can't forbid people from working on them, but if those people
> are also capable of contributing to Mail and/or Contacts, then every
> hour spent on them makes the MVP an hour of work further away.
Mail/Contacts development will bring TB++ sooner to a usable point in
the first place. But I think at the end TB users will expect a Calendar
(and maybe chat) integration. So, what about a three step plan? First
step, bundle all devs to bring Mail/Contacts working and release this as
TB++ v1.0. Second step, bundle all devs to integrate Calendar/Chat into
TB++ and release it as TB++ v2.0. And than split the teams to separatly
maintain and fix bugs in Mail/Contacts/Calendar/Chat and release this as
TB++ v2.5.
Klaus Hartnegg
I strongly suggest that anyone thinking a mail client without a calendar will fly should listen the the users a little more.
Ben Bucksch
> Thunderbird lasted for many years without either capability. I would
> strongly suggest that neither is part of a minimum viable product for
> TB++. We can't forbid people from working on them, but if those people
> are also capable of contributing to Mail and/or Contacts, then every
> hour spent on them makes the MVP an hour of work further away.
auxiliary parts, not on the core. I think that's a good approach.
> Firefox (and, even, Thunderbird!) demonstrated that a subset of users of
> a more complex product (the Mozilla Suite) are happy and find it
> refreshing to use a simpler product which does one thing well. That
> should be the initial path to gaining users for TB++ - an explicit
> refutation of the idea that (initially at least) it provides feature
> parity, to correctly set expectations.
functionality, then create a competitive mailer, then in the end cover
the full feature set of TB.
Ben
Ben Bucksch
> If you are not delivering more features that the windows 10 mail app
> which is almost universally denigrated as next to useless then you
> are not delivering something useful.
The Windows 10 mail app is indeed next to useless, but not because of
calendar or chat, but because it's a UI for children of age 10-14.
> As for data, really I think we have little or no idea what our users
> use, or what features they despise or want.
make a list of features, and gather data what users actually want.
Ben
Patrick Cloke
On 4/18/17 12:53 AM, R Kent James wrote:
Chat: I have heard nothing from this team, but I would guess this is also likely a line-by-line conversion from XUL and the Mozilla Platform to web technologies.
Most of chat is "web technologies" in that the entire backend is
written in JavaScript. It does use XPCOM to provide interfaces,
but all providers/consumers of those interfaces are JavaScript. It
uses some Mozilla-specific interfaces, of course, the most obvious
of which is low-level TCP sockets. I'm sure there are other APIs
too.
The user interface would need to be converted from XUL to HTML,
however. Message themes are already HTML/CSS/JavaScript. I can't
think of any super high performance aspects (i.e. treeview for
mail), currently the view can get really slow when you have many
many messages (e.g. a busy IRC channel left open for weeks).
--Patrick
The Wanderer
> On 18/04/17 11:11, Matt Harris wrote:
(I did have something to say on the subject of calendars, but I've
reluctantly concluded that it's not really relevant to progressing this
discussion. Short version: I miss the standalone-calendar Sunbird, but I
don't have any interest in an integrated calendar, except insofar as it
can be made to behave as if it were a standalone one.)
>> * I do see a small but continuous stream of issues in Support with
>> chat and News (NNTP). Mostly looking for long standing bug fixes,
>> given Mozilla ignored that module as much as they could get away
>> with. Are there 10 or 10 million users of NNTP. I have no idea.
>
> NNTP is certainly not part of an MVP. And I say that as a keen NNTP
> user.
do consider the NNTP functionality of Thunderbird to be a key part of
its feature set, without which it would not be complete. It may not be
part of "minimum viable", but it is still an essential target for a
sufficient replacement for "current Thunderbird", IMO.
Even for "minimum viable", sufficient Usenet-awareness to be able to
open and display imported messages with e.g. a Newsgroups: header but no
To: header would seem important. (I have hundreds if not thousands of
such, in Local Folders -> Sent and in "manual archive" folders of the same.)
Actually, that brings up a potentially important point. Is it intended
that people be able to import their existing Thunderbird profiles into
this "minimum viable product", and use them seamlessly?
If so, that seems to raise the bar for what would constitute minimum
functionality, since at the very least anything the program doesn't yet
understand would have to be retained in such a way that when support is
added later the data can still be picked up. (Subscribed-newsgroup
configuration, for example.)
If not, that makes enticing people across from Thunderbird to
Thunderbird++ a considerably more difficult proposition.
--
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
Gervase Markham
> Although I don't use it as heavily as I used to (by a large margin), I
> do consider the NNTP functionality of Thunderbird to be a key part of
> its feature set, without which it would not be complete. It may not be
> part of "minimum viable", but it is still an essential target for a
> sufficient replacement for "current Thunderbird", IMO.
"minimum viable" and "sufficient replacement" is utterly vital. We can
define "sufficient replacement" once we've built "minimum viable" -
there's no need to define it any earlier than that.
> Even for "minimum viable", sufficient Usenet-awareness to be able to
> open and display imported messages with e.g. a Newsgroups: header but no
> To: header would seem important. (I have hundreds if not thousands of
> such, in Local Folders -> Sent and in "manual archive" folders of the same.)
> Actually, that brings up a potentially important point. Is it intended
> that people be able to import their existing Thunderbird profiles into
> this "minimum viable product", and use them seamlessly?
> If not, that makes enticing people across from Thunderbird to
> Thunderbird++ a considerably more difficult proposition.
I don't see why that should be true.
Gerv
Joshua Cranmer 🐧
> On 18/04/17 16:57, The Wanderer wrote:
>> Although I don't use it as heavily as I used to (by a large margin), I
>> do consider the NNTP functionality of Thunderbird to be a key part of
>> its feature set, without which it would not be complete. It may not be
>> part of "minimum viable", but it is still an essential target for a
>> sufficient replacement for "current Thunderbird", IMO.
> Quite possibly. But keeping clear the (massive) difference between
> "minimum viable" and "sufficient replacement" is utterly vital. We can
> define "sufficient replacement" once we've built "minimum viable" -
> there's no need to define it any earlier than that.
There is a concept I have that certain features should be reflected as
eventually desirable and need their presence taken into account early on
to influence design yet for which implementations are unnecessary in a
MVP. NNTP is very clearly in this category, and I suggest things like
S/MIME, PGP, TNEF, LDAP, GSSAPI also fall into this category. They're
design points to take into account, although most of them have similar
technologies available already in MVP form. (MIME add-ons being the main
counterexample).
--
Joshua Cranmer
Thunderbird and DXR developer
Source code archæologist
op...@optosolar.com
> Matt Harris wrote on 18.04.2017 12:11:
> > If you are not delivering more features that the windows 10 mail app
> > which is almost universally denigrated as next to useless then you
> > are not delivering something useful.
>
I/We are business users: we need calendar. I think most enterprises do. We receive emails and drop them in the calendar to create tasks and events. There is no use having an email client without calendering. If that is not in TB, enterprises will need to go elsewhere. The same holds for IMAP: being able to access the mailbox from multiple PCs, without Exchange or similiar.
Google calendar, even in a tab, is not an option: at least in Germany, people use open source in order not to give personal data to companies like Microsoft, Google, etc. But also: if Google's calendaring server is outside of the European Community, I am not even legally allowed to use it for my company. If I don't want to continually check the newest developments on 'safe harbour for data', I want to keep that locally.
So as email is about information and answering at a certain time, it needs a calendar. At least with simple conversions between email and tasks/events.
Klaus
The Wanderer
> On 18/04/17 16:57, The Wanderer wrote:
>
>> Although I don't use it as heavily as I used to (by a large
>> margin), I do consider the NNTP functionality of Thunderbird to be
>> a key part of its feature set, without which it would not be
>> complete. It may not be part of "minimum viable", but it is still
>> an essential target for a sufficient replacement for "current
>> Thunderbird", IMO.
>
> Quite possibly. But keeping clear the (massive) difference between
> "minimum viable" and "sufficient replacement" is utterly vital.
> We can define "sufficient replacement" once we've built "minimum
> viable" - there's no need to define it any earlier than that.
target into account when designing the foundation on which that target
will be built, and knowing what that target will need to incorporate is
essential to being able to take it into account.
Otherwise, you end up either having to re-engineer the backend later to
support the new features (which is likely to be more work than designing
the backend to allow for them in the first place), or giving up on
implementing those new features at all.
(Or else retrofitting them onto an ill-fitting backend, I suppose, but
that way lie kludges and hard-to-maintain code.)
>> Even for "minimum viable", sufficient Usenet-awareness to be able
>> to open and display imported messages with e.g. a Newsgroups:
>> header but no To: header would seem important. (I have hundreds if
>> not thousands of such, in Local Folders -> Sent and in "manual
>> archive" folders of the same.)
>
> Are you typical in that regard?
considerable outlier, having *some* such messages may not be unusual at
all.
>> Actually, that brings up a potentially important point. Is it
>> intended that people be able to import their existing Thunderbird
>> profiles into this "minimum viable product", and use them
>> seamlessly?
>
> No.
For myself, if it's not possible to upgrade from Thunderbird to
Thunderbird++ and continue using my existing profile without data loss
(even if not all features are present yet), I would not consider
Thunderbird++ to be "viable".
>> If not, that makes enticing people across from Thunderbird to
>> Thunderbird++ a considerably more difficult proposition.
>
> It wasn't hard for people to move from the Mozilla Suite to Firefox,
> so I don't see why that should be true.
profiles, whereas they had relatively little invested in their Mozilla
Suite profiles.
For the Mozilla Suite -> Firefox move, there was a certain amount of
configuration-preferences data (which may or may not have had an import
/ migration tool, I don't recall at this remove), and there was the
bookmarks file. As far as I recall, that's it.
For Thunderbird, on the one hand there's account configuration
(including server names, usernames, passwords, etc., which the users may
almost never need to remember), which is complex enough to be a pain to
set back up - and on the other hand there's the store of local mail
messages, which is essentially impossible to re-create without importing
it, and which can range in size from "minimal and totally unimportant"
(a few megabytes or less, for someone who never uses Local Folders at
all) to multiple gigabytes of valuable and irreplaceable data (as in my
case).
The more data there is to be potentially lost without migration, and the
harder it is to avoid losing it without migration, the harder it is to
convince people to move without migration.
Gervase Markham
> For myself, if it's not possible to upgrade from Thunderbird to
> Thunderbird++ and continue using my existing profile without data loss
> (even if not all features are present yet), I would not consider
> Thunderbird++ to be "viable".
say even a migrator is doubtful as part of an MVP - people can just set
up their email accounts again; it's easy with the DB).
One day, using an existing profile without data loss might be possible.
But to say you couldn't try Thunderbird++ until that was possible is
surely not true.
> The more data there is to be potentially lost without migration, and the
> harder it is to avoid losing it without migration, the harder it is to
> convince people to move without migration.
I want to focus on the word "Minimum" in MVP. Minimum does not mean
"works for me", it means "works for some large enough set of people that
we actually have a userbase".
Gerv
The Wanderer
> On 19/04/17 14:38, The Wanderer wrote:
>
>> For myself, if it's not possible to upgrade from Thunderbird to
>> Thunderbird++ and continue using my existing profile without data
>> loss (even if not all features are present yet), I would not
>> consider Thunderbird++ to be "viable".
>
> There would be precisely that - a unidirectional migration (although
> I'd say even a migrator is doubtful as part of an MVP - people can
> just set up their email accounts again; it's easy with the DB).
have under Local Folders. Without a migrator, switching is a nonstarter.
A Thunderbird++ without a functioning migrator might well be viable as
an E-mail client for new users. It would not be viable as an upgrade
from, or replacement for, Thunderbird - in part because without a
migrator, you can't *upgrade*, you have to start from scratch.
> One day, using an existing profile without data loss might be
> possible. But to say you couldn't try Thunderbird++ until that was
> possible is surely not true.
as long as I do nothing that will affect the mail state in a way that
can't propagate back to my live Thunderbird profile), maybe. Try it for
production use, no.
>> The more data there is to be potentially lost without migration,
>> and the harder it is to avoid losing it without migration, the
>> harder it is to convince people to move without migration.
>
> Sure. But not everyone will need to migrate.
which lead one to already use Thunderbird are correlated with the
behavior patterns which will result in needing to migrate.
> I want to focus on the word "Minimum" in MVP. Minimum does not mean
> "works for me", it means "works for some large enough set of people
> that we actually have a userbase".
I think my question is about what it means to say that it "works" -
which puts the focus back on the definition of "viable".
There's also a distinction between "viable as an E-mail client" and
"viable as an upgrade from / replacement for Thunderbird", even assuming
that there's no need for all features to be present right away in a
Thunderbird replacement.
You seem to be targeting the former, whereas I am looking at the latter.
I think the latter is important when considering an audience who use
existing Thunderbird and will be looking at upgrading ("existing
users"), and the former is important when considering an audience who
use another mail client or Webmail or even haven't previously used
E-mail at all ("new users").
The minimum that "works" for one of these audiences is very different
from the minimum that "works" for the other.
That would mean that the question is: which of these two audiences is
more important to target for the initial product build?
The "new users" are certainly the larger potential audience, but it is
also the harder audience to engage, and there is no guarantee that
Another Potential Mail Client will get their attention at all.
The "existing users" are the audience which is more likely to notice the
existence of Thunderbird++ in the first place, and more likely to
consider switching to it in the absence of further updates to existing
Thunderbird.
Particularly given that the stated goals of the from-scratch rewrite
include "to be close to the existing Thunderbird, in UI and features, as
a drop-in replacement for end users, without baffling them", and that
"They should immediately recognize the replacement as the Thunderbird
they love". it seems clear to me that we should be focusing on the
"existing users" as the first priority; the "new users" are important,
but if we lose the existing ones, Thunderbird is pretty much dead
anyway.
Ben Bucksch
> For Thunderbird, on the one hand there's account configuration
> (including server names, usernames, passwords, etc., which the users may
> almost never need to remember), which is complex enough to be a pain to
> set back up - and on the other hand there's the store of local mail
> messages, which is essentially impossible to re-create without importing
> it, and which can range in size from "minimal and totally unimportant"
> (a few megabytes or less, for someone who never uses Local Folders at
> all) to multiple gigabytes of valuable and irreplaceable data (as in my
> case).
Importing account config should be relatively easy. Reading local
folders (mbox) should also be possible, and there's a clear need for
that, if you're not using IMAP.
But there's a lot of other stuff in the profile, your filters, your spam
filter data, and what not, and that's a lot harder to migrate. In fact,
an MVP product won't even have filters. (And I say that as somebody who
totally depends on filters.)
Ben Bucksch
> I want to focus on the word "Minimum" in MVP. Minimum does not mean
> "works for me", it means "works for some large enough set of people that
> we actually have a userbase".
FWIW, a gradual rewrite of component by component throws that MVP right
out of the door. Any replaced component would need to cover 100% of the
TB features of that component. And the project is only done when this is
finished for all components. That's one reason (of several) why that
approach is a rat hole.
Ben
Matt Harris
On 19/04/17 14:38, The Wanderer wrote:For myself, if it's not possible to upgrade from Thunderbird to Thunderbird++ and continue using my existing profile without data loss (even if not all features are present yet), I would not consider Thunderbird++ to be "viable".There would be precisely that - a unidirectional migration (although I'd say even a migrator is doubtful as part of an MVP - people can just set up their email accounts again; it's easy with the DB). One day, using an existing profile without data loss might be possible. But to say you couldn't try Thunderbird++ until that was possible is surely not true.
As for Thunderbird users, not developers, they download the product and expect it to "just get their mail and contacts" from where ever they were in the past. In many cases they do not conceive that web mail and a mail client are not the same thing. When the shiny tool they downloaded does not "just work", they move to the next download on file hippo. A few seek support, but most folks these days simply are not that invested in their software. First sign of trouble, dump it and try something else.
One of the greatest failures of Thunderbird is the absence of a profile migration tool! Now you are proposing another elephant without a trunk to drink from. Those using the product have difficulty copying a file from their desktop to a USB drive. We expect them to copy profiles.
The more data there is to be potentially lost without migration, and the harder it is to avoid losing it without migration, the harder it is to convince people to move without migration.Sure. But not everyone will need to migrate.
I want to focus on the word "Minimum" in MVP. Minimum does not mean "works for me", it means "works for some large enough set of people that we actually have a userbase".
Anyone still using their Firefox OS phone? Think about user acceptance there of what was an MVP
Matt
Gerv
_______________________________________________ tb-planning mailing list tb-pl...@mozilla.org https://mail.mozilla.org/listinfo/tb-planning
Matt Harris
Thunderbird Support Lead
Nomis101 🐝
than I'm a bit disappointed about the slender macOS support. In the
meantime it seems to me, the Thunderbird team does not care so much
about macOS users. For example:
• Thunderbird is shipping on macOS with a broken Spotlight plugin since
3 years now and nobody seems to care
• Thunderbird is completely lacking the support of gestures, which are
available since 9 years on macOS now
• Thunderbird is completely lacking the QuickLook feature, which is
available on macOS since 9 years as well
• Thunderbird on macOS has support of the macOS address book since 14
years, but until than it is still an unfinished "draft" support (you
could rise a child by that time). It only can read out the macOS
address book, nothing more.
• On all other apps on macOS you have advanced spellchecking support,
with suggestions, multi-language support and so on. But not on Thunderbird.
This only names the mayor things Thunderbird is behind most other mail
apps on macOS. In short, Thunderbird supports this macOS features which
are included in Core, but it is not really using own ones and the ones
which are included in Mail or Mailnews are either unfinished or broken.
So, it is really difficult to convince people on macOS to switch to
Thunderbird. I'm wondering why the Thunderbird team cares so less about
macOS users. Is it because Thunderbird has more Windows users than macOS
users? Is it because of the lack of macOS developers? Or what is it?
Being part of a macOS user forum, I know that more than a few users are
looking for alternatives to Apple Mail. So we are missing opportunity
here if we are not supporting even the minimum a modern macOS user would
expect from an email application.
Jörg Knobloch
> Is it because of the lack of macOS developers?
Yes. We have zero developers on Mac, oh, well, maybe one, Philipp, but
he works on calendar or build issues when he finds the time since he is
also the Council chairman with heaps of duties. Or maybe I should count
our new calendar contributor Javi, who has also fixed a Mac sound bug.
We're multi-platform and with the few resources we've got we need to
focus on what is basically supported on all platforms. All new feature
implementation is purely volunteer-based, so if no volunteer implements
anything, nothing will get done. So Mac volunteers, please step forward
and fix your most hated bug or implement your most desired feature. And
bring your friends, so someone can test and review your work.
BTW, does the base Mozilla platform support special Mac features
Firefox, like gestures or advanced spellchecking support? If not, it's
not likely to happen in Thunderbird. But it would be good to fix some
long-standing Mac bugs, for example import from Apple Mail to start with.
Jörg.
Nomis101 🐝
> BTW, does the base Mozilla platform support special Mac features
> Firefox, like gestures or advanced spellchecking support? If not, it's
> not likely to happen in Thunderbird. But it would be good to fix some
> long-standing Mac bugs, for example import from Apple Mail to start with.
Yes, Firefox has very good advanced gestures support. For spellcheck I
don't know. But I think a spellchecker is more usefull in an email app
than in a browser.
Wayne Mery
include them below.
On 6/4/17 7:47 AM, Nomis101 🐝 wrote:
> Yes, I'm using Thunderbird on macOS now since over 15 years, but since
> than I'm a bit disappointed about the slender macOS support. In the
> meantime it seems to me, the Thunderbird team does not care so much
> about macOS users. For example:
>
> • Thunderbird is shipping on macOS with a broken Spotlight plugin since
> 3 years now and nobody seems to care
> • Thunderbird is completely lacking the support of gestures, which are
> available since 9 years on macOS now
https://bugzilla.mozilla.org/show_bug.cgi?id=465257
> • Thunderbird is completely lacking the QuickLook feature, which is
> available on macOS since 9 years as well
https://bugzilla.mozilla.org/show_bug.cgi?id=457546
> • Thunderbird on macOS has support of the macOS address book since 14
> years, but until than it is still an unfinished "draft" support (you
> could rise a child by that time). It only can read out the macOS
> address book, nothing more.
https://bugzilla.mozilla.org/show_bug.cgi?id=391057
> • On all other apps on macOS you have advanced spellchecking support,
> with suggestions, multi-language support and so on. But not on Thunderbird.
> This only names the mayor things Thunderbird is behind most other mail
> apps on macOS. In short, Thunderbird supports this macOS features which
> are included in Core, but it is not really using own ones and the ones
> which are included in Mail or Mailnews are either unfinished or broken.
> So, it is really difficult to convince people on macOS to switch to
> Thunderbird. I'm wondering why the Thunderbird team cares so less about
> macOS users. Is it because Thunderbird has more Windows users than macOS
> users? Is it because of the lack of macOS developers? Or what is it?
> Being part of a macOS user forum, I know that more than a few users are
> looking for alternatives to Apple Mail. So we are missing opportunity
> here if we are not supporting even the minimum a modern macOS user would
> expect from an email application.
I agree with what Jorg said. I think it's pretty telling that
https://bugzilla.mozilla.org/show_bug.cgi?id=728438 - [meta]
Include/Support Thunderbird better into OS X - that in 5 years that
there are only 12 people CC on the bug and that most of the activity
there is only you and I (a non-Mac user).
Plus I didn't know most of those bugs existed before I just searched for
them. That says a lot, namely that users aren't being vocal about these
things, because I know a good percentage of the Thunderbird bugs.
We need new/more Mac people to step up.
Joshua Cranmer 🐧
> Yes, I'm using Thunderbird on macOS now since over 15 years, but since
> than I'm a bit disappointed about the slender macOS support. In the
> meantime it seems to me, the Thunderbird team does not care so much
> about macOS users. For example:
We actually lack good OS integration support on all of our platforms,
including MAPI integration on Windows and pulling S/MIME certificates
from OS stores.
But, as others have said, we don't have OS X developers. And OS X really
sucks because it's very difficult to "casually" build anything on OS
X--you need to buy an entire separate computer, since you can't use it
on a VM (on non-mac hardware). Our last developer on OS X did leave a
few years ago, and without paid developers, we're entirely reliant on
volunteers stepping up to do the job. So if there are no volunteers,
nothing can get done.
--
Joshua Cranmer
Thunderbird and DXR developer
Source code archæologist
_______________________________________________
Nomis101 🐝
> But, as others have said, we don't have OS X developers. And OS X really
> sucks because it's very difficult to "casually" build anything on OS
> X--you need to buy an entire separate computer, since you can't use it
> on a VM (on non-mac hardware).
I don't know how this really works, but the Firefox team is
cross-compiling Firefox for Mac on Linux. So it should also be possible
(locally) for Thunderbird.
https://bugzilla.mozilla.org/show_bug.cgi?id=921040
Joshua Cranmer 🐧
> Am 04.06.17 um 19:52 schrieb Joshua Cranmer 🐧:
>> But, as others have said, we don't have OS X developers. And OS X really
>> sucks because it's very difficult to "casually" build anything on OS
>> X--you need to buy an entire separate computer, since you can't use it
>> on a VM (on non-mac hardware).
> I don't know how this really works, but the Firefox team is
> cross-compiling Firefox for Mac on Linux. So it should also be possible
> (locally) for Thunderbird.
Being able to build the software doesn't help if you can't run it to
test anything :-)
--
Joshua Cranmer
Thunderbird and DXR developer
Source code archæologist
_______________________________________________
Mark Banner
> Thunderbird is shipping on macOS with a broken Spotlight plugin since
> 3 years now and nobody seems to care
people don't realise a possible integration is there.
> I'm wondering why the Thunderbird team cares so less about
> macOS users. Is it because Thunderbird has more Windows users than macOS
> users?
Last I knew the ratios were in the order of 90% Windows users, 10%
other. It is quite possible that has changed though. So the priorities
for FF & TB have always generally been Windows (though Firefox does have
a few people working on Mac & Linux specific parts I believe).
> Is it because of the lack of macOS developers? Or what is it?
Back when I was developing Thunderbird, I did occasionally look at Mac
specific integrations/features. Unfortunately I always found it hard -
attempting to understand how Objective-C and some of their interfaces
worked and then integrating that into Thunderbird was difficult. Had I
had time to become an Objective-C programmer, then it might have been
different.
One other item sometimes was the lack of core support in Gecko - I can't
remember what they were, but I'm pretty sure at least a couple of
integration points needed core support which wasn't there.
It would certainly have helped to have had someone contributing who was
familiar with Objective-C, maybe that's still possible.
Mark.
Axel Grude
Subject:Re: Why does the Thunderbird team care so less about macOS users?
From:Nomis101 🐝 <Nomi...@web.de>
To:Tb-planning
Sent: Sunday, 04/06/2017 13:23:28 13:23 GMT ST +0100 [Week 23]
Am 04.06.17 um 14:10 schrieb Jörg Knobloch: > BTW, does the base Mozilla platform support special Mac features > Firefox, like gestures or advanced spellchecking support? If not, it's > not likely to happen in Thunderbird. But it would be good to fix some > long-standing Mac bugs, for example import from Apple Mail to start with. Yes, Firefox has very good advanced gestures support. For spellcheck I don't know. But I think a spellchecker is more usefull in an email app than in a browser.
I thought Thunderdbird is using the standard Mozilla-based spell checker? Version-specific Language packs for Thunderbird / Mac version 52.1.1 can be downloaded here:
https://ftp.mozilla.org/pub/thunderbird/releases/52.1.1/mac/xpi/
regards,
Axel
Axel Grude
Subject:Re: Why does the Thunderbird team care so less about macOS users?
From:Joshua Cranmer 🐧 <pidg...@gmail.com>
To:Tb-planning
Sent: Sunday, 04/06/2017 18:52:07 18:52 GMT ST +0100 [Week 23]
On 6/4/17 6:47 AM, Nomis101 🐝 wrote:
Yes, I'm using Thunderbird on macOS now since over 15 years, but since
than I'm a bit disappointed about the slender macOS support. In the
meantime it seems to me, the Thunderbird team does not care so much
about macOS users. For example:
We actually lack good OS integration support on all of our platforms, including MAPI integration on Windows and pulling S/MIME certificates from OS stores.
But, as others have said, we don't have OS X developers. And OS X really sucks because it's very difficult to "casually" build anything on OS X--you need to buy an entire separate computer, since you can't use it on a VM (on non-mac hardware). Our last developer on OS X did leave a few years ago, and without paid developers, we're entirely reliant on volunteers stepping up to do the job. So if there are no volunteers, nothing can get done.
Exactly the problem with Addon support - if you want to support Mac users specifically you actually have to buy the hardware. Linux support on the other hand is very easy for windows users as there are free virtualbox environments available.
Axel
Ben Bucksch
>
>> *Subject:*Re: Why does the Thunderbird team care so less about macOS
>> users?
>> *From:*Nomis101 🐝 <Nomi...@web.de>
>> *To:*Tb-planning
>> *Sent: *Sunday, 04/06/2017 13:23:28 13:23 GMT ST +0100 [Week 23]
>> Am 04.06.17 um 14:10 schrieb Jörg Knobloch:
>> > BTW, does the base Mozilla platform support special Mac features
>> > Firefox, like gestures or advanced spellchecking support? If not, it's
>> > not likely to happen in Thunderbird. But it would be good to fix some
>> > long-standing Mac bugs, for example import from Apple Mail to start with.
>>
>> Yes, Firefox has very good advanced gestures support. For spellcheck I
>> don't know. But I think a spellchecker is more usefull in an email app
>> than in a browser.
>
> I thought Thunderdbird is using the standard Mozilla-based spell
> checker? Version-specific Language packs for Thunderbird / Mac version
> 52.1.1 can be downloaded here:
>
> https://ftp.mozilla.org/pub/thunderbird/releases/52.1.1/mac/xpi/
>
See the original message, he's talking about features we don't have, for
example multi-language support. That's sorely missing for me on Linux, too.
Ben
Eckard Berberich
Le 05/06/2017 à 12:46, Axel Grude a écrit :
>
>> *Subject:*Re: Why does the Thunderbird team care so less about macOS
>> users?
>> *From:*Nomis101 🐝 <Nomi...@web.de>
>> *To:*Tb-planning
>> *Sent: *Sunday, 04/06/2017 13:23:28 13:23 GMT ST +0100 [Week 23]
>> Am 04.06.17 um 14:10 schrieb Jörg Knobloch:
>> > BTW, does the base Mozilla platform support special Mac features
>> > Firefox, like gestures or advanced spellchecking support? If not, it's
>> > not likely to happen in Thunderbird. But it would be good to fix some
>> > long-standing Mac bugs, for example import from Apple Mail to start with.
>>
>> Yes, Firefox has very good advanced gestures support. For spellcheck I
>> don't know. But I think a spellchecker is more usefull in an email app
>> than in a browser.
>
> I thought Thunderdbird is using the standard Mozilla-based spell
> checker? Version-specific Language packs for Thunderbird / Mac version
> 52.1.1 can be downloaded here:
>
> https://ftp.mozilla.org/pub/thunderbird/releases/52.1.1/mac/xpi/
>
> regards,
> Axel
Language packs ("Languages" category in the add-ons manager) are needed
if you want to change the user interface language without installing
another Thunderbird localization .
If you want to use the Mozilla spell checker you'll have to install
dictionaries ("Dictionaries" category in the add-ons manager):
<https://addons.mozilla.org/en-us/thunderbird/language-tools/>
Actually running three French versions of Thunderbird (52.1.1, 54.0b3
and 55.0a1) I don't encounter any particular problems with the spell
checker when I compose messages in French, in English or in German. I'm
using the built-in French dictionaries and additionally installed the
"United States English Spellchecker 8.1"
<https://addons.mozilla.org/en-us/thunderbird/addon/united-states-english-spellche/>
and the "Deutsches Wörterbuch 2.0.6"
<https://addons.mozilla.org/en-us/thunderbird/addon/german-dictionary/>
ace
sorry, but I do not see where this "caring less" comes from. Hooking
into optional platform features that are only available on one platform
is not caring less. If Mac hadn't even the features implemented on other
platforms, that would be something to be unhappy about. E.g. like
Firefox can't get HW (GPU) acceleration on Linux going for years, while
it is long working on Windows (if not OS X too).
Of the list you mentioned, maybe the Spotlight support should be fixed
up, considering there is also a Search integration on Windows (albeit
with dubious quality too and we have actually hidden it now). But I see
no bug filed about Spotlight not working at all.
----- Pôvodná správa -----
Predmet: Why does the Thunderbird team care so less about macOS users?
Od: Nomis101 🐝 <Nomi...@web.de>
Pre: tb-pl...@mozilla.org
Dátum: Sun, 4 Jun 2017 13:47:33 +0200
Ben Bucksch
Mac is a different platform with different customs. The Mac philosophy
is that the entire system is tightly integrated, so users expect the
support of the latest features like Retina or Touchbar, and developers
usually are quick to supply it.
If your operating system had a cross-application search function that is
actually useful and that you use regularly, you'd consider that a base
feature and you'd be unhappy about it not working in Thunderbird.
Insofar, I can understand Nomis101.
That said, if there are no Mac developers, then there won't be special
Mac support, that's for sure :-). It's actually amazing that Thunderbird
on Mac still works, considering we have nobody to fix it when it breaks.
Ben
Jörg Knobloch
It's actually amazing that Thunderbird on Mac still works, considering we have nobody to fix it when it breaks.
We are very committed to keeping the Mac platform going. We are fixing regressions. That entails a painful mix of compiling things on the try server and then letting Mac owners try them. Richard bought an old Mac out of his own pocket for his theme work and he can try things for us. This will hopefully improve soon since the Council decided on a hardware grant so developers can buy the hardware they need. We will also have it in the back of our minds when hiring developers (which is on the cards) to cover the Mac platform better.
Recent bugs fixed for Mac:
- Aceman fixed integration with Mac contacts, especially contact groups: bug 1356881
- Discontinued universal builds and got Daily Mac builds going again: bug 1322402 (real pain to fix via try and error on the servers)
- Crash related to the address book: Bug 1332246 - there we
got onto our knees and begged for help from Mozilla core
people and got it. Markus Stange fixed that bug for us.
- Crashes in Sierra due to memory management fixed by
Mozilla staff and backported to a TB release branch (again, a
lot of pain in that since we had to back-port five bugs)
- The sound bug fixed by our new contributor Javi.
So we're really stretching the existing resources to the limit.
Jörg.
Ben Bucksch
> On 06/06/2017 00:59, Ben Bucksch wrote:
>> It's actually amazing that Thunderbird on Mac still works,
>> considering we have nobody to fix it when it breaks.
>
> We are very committed to keeping the Mac platform going. We are fixing
> regressions. That entails a painful mix of compiling things on the try
> server and then letting Mac owners try them. Richard bought an old Mac
> out of his own pocket for his theme work and he can try things for us.
> This will hopefully improve soon since the Council decided on a
> hardware grant so developers can buy the hardware they need.
>
Yes, indeed. We should make sure the core contributors have access to
the hardware they need.
Ben
Nomis101 🐝
> other. It is quite possible that has changed though.
available?
Am 05.06.17 um 12:48 schrieb Axel Grude:
> Exactly the problem with Addon support - if you want to support Mac
> users specifically you actually have to buy the hardware. Linux
> support on the other hand is very easy for windows users as there are
> free virtualbox environments available.
>
> Axel
>
virtualbox. But yes, it is a bit hacky. But it seems possible.
Am 05.06.17 um 19:28 schrieb ace:
> no bug filed about Spotlight not working at all.
are also asking in the Apple support forum:
https://discussions.apple.com/thread/6626450?start=0&tstart=0
https://discussions.apple.com/thread/2013148?start=0&tstart=0
Richard Marti
> I found some tutorials on how to run macOS on Windows using a
> virtualbox. But yes, it is a bit hacky. But it seems possible.
It's possible but illegal. macOS is only allowed to run on Apple hardware.
Richard