Talk:Thunderbird:Thunderbird3: Difference between revisions

From MozillaWiki
Jump to navigation Jump to search
(silent deletion of Emails into "Comments on Usability (IMAP support)")
m (getting involved was nitpicked, so comment is now obsolete)
Line 105: Line 105:
So a basic need for development is to be able to select a contiguous segment of an email, including graphics, and send to a printer. Even nicer to be able to select a rectangle, like a screen capture, but which can span the whole email if needed. As a minimum, to able to File/Save As Image (saving the entire message as .bmp or .gif to crop and print in an image editor; would be better to save as .rtf or .doc, but not sure how consistently that would work).
So a basic need for development is to be able to select a contiguous segment of an email, including graphics, and send to a printer. Even nicer to be able to select a rectangle, like a screen capture, but which can span the whole email if needed. As a minimum, to able to File/Save As Image (saving the entire message as .bmp or .gif to crop and print in an image editor; would be better to save as .rtf or .doc, but not sure how consistently that would work).
I am not a programmer so I have no idea if this would be hard to do.
I am not a programmer so I have no idea if this would be hard to do.
== Comment on 'Getting involved' ==
It says: "Four good sources...".
The list consists of five items however.
I'd change it myself, if it weren't for the *bold* disclaimer at the top.

Revision as of 08:14, 11 August 2008

Comments on 'Better Extensibility'

Personally, I think it'd be better to simply point tb extension developers at #maildev on IRC. There's so much that can be learned just by reading scrollback, and splitting up the mail-expertise and mail-scrollback would seem like a loss to me. Also, splitting channels makes it less likely that someone will be around to answer a question in either channel, which just leads to frustration. --jminta

Sounds good. I've adjusted the copy. --davida

As an extension developer, one thing that frustrates me is that some key functionality is not exposed to extensions. For example, deleting messages seems to be handled without JS exposure, and some areas of composing messages, specifically reply-all functionality, is likewise not exposed or broken. It would be great to expose more to the extensions. --Watusimoto

reply: These are exactly the kinds of problems Steel is aiming to solve. If all goes according to plan, extensions will have this functionality exposed in TB3. --jminta


Comments on Lightning integration

If you choose to integrate lightning and move TB3 towards a heavier email application like Evolution/Outlook etc. it should be considered to provide a Thunderbird lite version without lightning etc. similar to outlook express.

Comments on Usability (IMAP support)

A main focus on usabilliy should be better IMAP support. In particular its important to have an option to save a copy of all emails locally and an improved download mails and work offline mode. It should generally be possible, when using IMAP and being offline, to write an email and send it. That mail should be copied to the local sent mail folder and be marked as unsent. Then when going back online the mail should be sent out and synchronized with the remote IMAP folder. Particularly attachments should be downloaded and saved locally for further reference. IMAP localization should be improved / currently use of German IMAP folders (e.g. with GMX) requires a lot of nasty hacks in prefs.js / users.js and about:config

Most important is a working export function to save mails / contact
list AND account settings / global settings

Right now even silent deletion of Emails happens in specific situations when using IMAP: https://bugzilla.mozilla.org/show_bug.cgi?id=439216

Comments on 'Architectural cleanup'

I know some people don't share my love of JavaScript, but I'd like to see the architectural cleanup include an audit of mail components for possible candidates to move from C++ to JS. Firefox has gone this route for components not on perf-critical paths, for example the search service or the download manager. Advantages include virtually crash-proof code and no reference counting. Also, it seems as though Mozilla2 will be moving even more things to JavaScript (with ES4), so getting a head-start on this would be good. --jminta

I'm not sure if it has been mentioned elsewhere, but the move away from mork for the .msf files seems to be a good opportunity to dump mbox as well (and replace it by maildir). It occurs to me that common agreement was already reached on this issue, which is tracked in bug 58308. As a placeholder I've added it here--GustB 12:46, 4 February 2008 (PST)

Its not clear to me that "common agreement" was reached on replacing mbox with maildir. I periodically see a few posts in the mozillaZine forums from people asking for this, but most users have no idea what it even is because they are using Windows. Many of the comments in the bug report advocate supporting both formats. Tanstaafl 09:33, 2 March 2008 (PST)
I refer to comment 75 of bug 58308. Or comment 18 of bug 290057. Just search bugzilla for maildir --GustB 04:58, 7 March 2008 (PST)

Is the de-morkification the first of a two step process, where its changes eventually get replaced by Unified Storage? Tanstaafl 09:33, 2 March 2008 (PST)

A common problem that I see in the mozillaZine forums is users panicking due to Thunderbird appearing to lose all of their data the next time they start it. There are arguments whether this is mainly due to prefs.js getting corrupted or a old bug where Thunderbird sometimes forgets about the existence of a profile in profiles.ini but I'm surprised some minor architectural changes to work around this issue weren't considered. Tanstaafl 14:33, 1 March 2008 (PST)

Another group of problems is the MIME handling, summarized in Fix some longstanding bugs. Certain highly visible bugs related to MIME-type parsing (e.g., with quoted-printable HTML messages) and attachment handling (management of Content-Type associations and actions) should be addressed, a comment in one of the bugs suggests a major overhaul of the MIME module code. --Rsx11m 14:34, 2 March 2008 (PST)

Comments on 'Increased Adoption'

The item 'GMail IMAP support' can probably be a subpoint under 'Simple Account Setup', as it is an example of an ISP-specific setup. My concern here is that it would involve a lot of work to cover all possible ISP setups across the world, not to mention non-public corporate or institutional setups. Thus, equal effort should be given to the extension of the Account Wizard to allow alternate encryption and port settings to be entered already during the initial setup. A partial patch is pending review for more than two years now in bug 221030. --Rsx11m 21:13, 24 February 2008 (PST)

I've expanded on this in Talk:Thunderbird:Easy Account Setup. --Rsx11m 12:20, 9 March 2008 (PDT)

I wish I knew of a better place to leave this feedback. Here are things our company would love to see in Thunderbird that all users would love. 1) Fix that "Mail Server Password Required" bug/issue. Whenever our imap accounts lose connectivity with have to repeatedly enter our passwords and click remember our password over and over again. It's an exercise in futility. Thunderbird should simply reattempt connection and just let the user know connectivity is lost and they should retry later. 2) Ability to drag emails to local folders/desktop etc. 3) Ability to select and save a group of emails to a folder. 4) A better method of sending feedback on Thunderbird. Thank you.

I'll leave this feedback here, as I hope it will be more visible than it has been in the past in other locations. In order to appeal to current users of Mail.app on OS X, it is vital to include a built in way to import Mail.app settings and mailboxes, and to provide integration with the system wide address book application. I firmly believe that these 2 features alone will have the largest influence on getting mac users to adopt Thunderbird.

Rage Against The Account Machine

Rage Against The Account Machine explains the problems with the current (Thunderbird 2.0.0.x) approach to accounts. Among these problems is that Thunderbird 2.0.0.x demands that the user create and configure an account before doing anything else. If the user declines to do so (because, say, the user needs to express a thought in writing before the thought slips from the user’s mind), Thunderbird 2.0.0.x quits. This behavior is hostile and discouraging to the user. Implementing the proposals in Easy Account Setup and Autoconfiguration would be a huge improvement but still not enough to achieve best‐in‐the‐field usability. Rage Against The Account Machine is a proposal to eliminate Thunderbird accounts as we know them, eliminating the need to set up accounts in the process. —Etan Wexler 16:28, 25 June 2008 (PDT)

Comments on 'Getting Involved'

You mention that there are currently 1300+ RFE's for Thunderbird pending, this does not include some 800+ RFE's for the MailNews Core modules. About 120+ (total) of those RFE's have at least partial patches up for review, thus would be easier to add than others. It may be worth to go through those to determine which ones fit into the concepts for TB3, and to give them some increased priority. --Rsx11m 21:21, 24 February 2008 (PST)

A link to the Thunderbird:Fix some longstanding bugs article should be provided in addition to Thunderbird:Thunderbird 3 Possible Bugs as all of those are probably likely candidates for priority fixes. --Rsx11m 14:58, 2 March 2008 (PST)

I'd like to try out TB3 to see how it's UI looks like, yet I can't afford loosing any mails (not even already read ones). It would be nice if there's a "read-only" mode during installation or running.

Goals of the Thunderbird 3

IMO people don't want to get yet another mailer, people want to get a modern communication center which handles all kind of personal information. This essentially means a TB3 has to be able to synchronize these information to any kind of external storage (devices). It has to be realized that synchronization will become the main data exchange protocol anytime in the future and might even supplant POP3/IMAP/SMTP later on. Therefore it's essential to plan to base the internal structure on e.g. SyncML (OpenSync) and move the older protocols into addable/removable plugins. This would allow to open up TB3 for future uses which aren't known so far. Besides TB3 would get a simple internal structure to handle all currently known whishes.

So first action should be to add synchronization to the goals of TB3. The second action should be to analyze OpenSync and determine how feasible it is as the base of TB3. Third action should be to define the necessary APIs of the needed plugins, e.g. check if access to SQLite could be realized as a plugin and used as the information storage engine. A concept of this kind probably is robust enough to handle many more whishes without making it more complex. Many if not most wishes might simply be realized in an appropriate plugin. Anonymous

I suggest you add a lower level goal of providing a help system, to help meet the high level goal of To improve usability". See http://interimhelp4tbird.mozdev.org/ Tanstaafl 19:46, 24 March 2008 (PDT)

None of the goals address process issues. Or perhaps I should say helping to get users more involved.

  • Its quite common to have bugs sit for years as new or unconfirmed with no assignment to a developer, let alone a comment by one, and then sometimes be closed automatically for inactivity. This discourages users from filing bug reports. (wsm: progress is being made in this area, but the user community needs to become more involved in QA activities to make this important issue a reality.) As an aside telling somebody "Also, please do not file bugs on browser/email software older than two weeks - first, download a newer build of Firefox, Thunderbird, SeaMonkey, or Camino and check that the problem is still present." who only uses released versions doesn't exactly make them feel welcome. (wsm: guided bug form is not controlled directly by Thunderbird team - it does need some improvement)
  • Lots of people add comments in the appropriate planning documents talk page lobbying for certain features. When the next major release is released we all scratch our heads trying to figure out why certain features were implemented, and whether there is a chance that what we wanted will get implemented in the next release. It would help if you publish a one page document describing the criteria you use to determine what to add/implement for each major release beforehand, and afterwards provide a short document listing the top 30 features that were considered, showing how they were ranked/scored, and where the dividing line was. This wouldn't take much time, and might help provide more useful input from users next time. Tanstaafl 19:46, 24 March 2008 (PDT)

Allow for completely hiding the folder pane. The folder pane is only needed when switching between folders. But switching between folders could be easily be done through a popup box (as in SeaMonkey). This would allow for a dual pane instead of the usual triple pane layout, occupying much less screen area. (wsm: for all 3 views types this can be achieved by dragging the splitter to the far left margin - but it does not persist across restarts).

When I will migrate to Thunderbird

I wanted to let you know what conditions would need to be satisfied in order for me to migrate from Mac Mail to Thunderbird:

1. If there was seamless email encryption enabled by default, you would pretty much have me sold.

2 If there was a nicer looking skin enabled by default, + the features and ease of use were just as good as mac Mail, I would migrate.


Right now i think thunderbird as being a. not as pretty as my other apps, It really makes a difference to me, and I know it makes more of a difference to most people than they are willing to admit. b. a little harder to use than mac mail. c. nothing special to bring me over.

Just thought I would let you know. I do want you to know that you have the advantage over mac mail, I will select open source software over proprietary.

Thanks for this very reasonable mail software! Is just not my best option at present.

Printing emails

Looking for progress on this need, didn't find anything recent: Sometimes I need to print out an email but find too much paper is consumed by useless parts. I can "edit as new" and select what I want and paste into a word processor, but formatted html emails no longer resemble the original at all. I have to manually reorganize the parts to make it printable. That is way too much work. I can use a screen capture program if what I want will fit on one screen (not usually). And that makes a gif file, which has to be loaded into an image editor to print; still a lot of steps for what should be a basic feature. So a basic need for development is to be able to select a contiguous segment of an email, including graphics, and send to a printer. Even nicer to be able to select a rectangle, like a screen capture, but which can span the whole email if needed. As a minimum, to able to File/Save As Image (saving the entire message as .bmp or .gif to crop and print in an image editor; would be better to save as .rtf or .doc, but not sure how consistently that would work). I am not a programmer so I have no idea if this would be hard to do.