User-Agent: Mozilla/5.0 (X11; U; Linux i686) Gecko/20030530 Galeon/1.3.5
Build Identifier: Mozilla/5.0 (X11; U; Linux i686) Gecko/20030530 Galeon/1.3.5
The latter builds of Thunderbird feature the new, Outlook 2003 3 paned view.
This view has the 3 common mail panes going from left to right with no vertical
This works well, except the mail listing. Because this layout causes the middle
pane to have less horizontal real estate, it causes scrunching of mail
information. As a result, under this view, a new setup should be done:
Subject Line 6:15PM
Moving to a more vertical mail summary will allow each mail's to/date/subject
information to be viewed without crowding.
Steps to Reproduce:
This would be nice, but I don't think it is currently doable.
Can't be done for technical or time constraints?
Updating platform information. Yes, the problem is that what our 3-pane does is
simply move the panes around. Outlook 2003 actually uses a *different* pane for
the maillist in the 3-vertical-column view, so it shows less information. So,
yes, it will be a lot of work.
this would be great but our framework doesn't support something like this. It
will be a lot of toolkit work. Future'ing for now.
Created attachment 142624 [details]
What the message pane looks like in Outlook 2003.
There's a <a
about this at the mozillaZine forums. It seems as if some people would like this
Have been browsing an xul reference, and the following thought came to me:
Currently, TB's mail listing uses an xul "tree" element which provides for the
Would it be possible to change this to the xul "grid" element? If so, would the
"flex" attribute of the grid or row elements be useful in achieving the desired
Anyone have a clear enough picture of xul in their head to say if this would work?
*** Bug 242428 has been marked as a duplicate of this bug. ***
*** Bug 244444 has been marked as a duplicate of this bug. ***
*** Bug 304194 has been marked as a duplicate of this bug. ***
Created attachment 258111 [details]
Rough Mockup of Organized Column View
Here's a quick mockup of how the column view could potentially be organized.
Created attachment 266237 [details]
Lotus Notes using stacked sender and subject
It might be possible to make an extension in TB2 for this.
"Improved Support For Extensions: Extensions can now add custom columns to the
message list pane in addition to storing custom message data in the mail
Don't get me wrong, I would so much like to have this feature in Thunderbird
*** Bug 307070 has been marked as a duplicate of this bug. ***
(In reply to comment #4)
> this would be great but our framework doesn't support something like this. It
> will be a lot of toolkit work. Future'ing for now.
Scott is this implementable now? If so I can bug some ext devs I know
PS: sorry for the bug spam
I would also very much would like to see this view implemented on Thunderbird. Windows Live Mail Desktop is another program that comes with this view.
*** Bug 335310 has been marked as a duplicate of this bug. ***
I totally agree that this needs to be implemented. It's much more efficient use of space, and I consider not having this feature a deal breaker at the moment. I'm guessing that a lot of other people who use Microsoft's mail software (Windows Mail, Outlook, Windows Live Mail) are going to be thinking similarly.
I've actually seen this in a Thunderbird 1.x theme, but the theme itself wasn't too nice. As such I see absolutely no reason why this cannot be implemented.
I generally run away from front-end bugs, but I'll still put some of my research into this topic in here.
First of all, I like the current implementation of the threaded pane, so there should be an option in the View->Layout menu and probably a pref as well to change between a thread pane and the column layout like so:
|Layout >|* Classic View |
|Folders >| Wide View |
+-----------------| Vertical View|
|Sort by >|---------------+
|Threads >|* Stacked View |
+-----------------| Column View |
|Message Body As >| Message Pane |
My personal preferences for UI aside, the files for implementation are going to mostly reside in mail/base/content/ and mailnews/base/resouces/content/; the files that I think are the most important are:
mail/base/content/messenger.xul (where the current threadTree for TB resides)
mailnews/base/resources/content/threadPane.xul (ditto for SM)
mailnews/base/resources/content/threadPane.js (code that works on threadTree)
mail/base/content/mailWindowOverlay.xul and respective js (menu entries)
mailnews/base/resources/content/mailWindowOverlay.xul and js (ditto for SM)
*** Bug 413288 has been marked as a duplicate of this bug. ***
Created attachment 307012 [details] [diff] [review]
treeView enhancement: draft
Created attachment 307013 [details]
treeView enhancement: rows with vertical content (subject + preview)
Created attachment 307014 [details]
treeView enhancement: higher height description (multiline)
Created attachment 307016 [details]
treeView enhancement: more style work (bigger cells)
Created attachment 307017 [details]
treeView enhancement: cropped
attachment 307012 [details] [diff] [review]
attachment 307013 [details]
attachment 307014 [details]
attachment 307016 [details]
attachment 307017 [details]
I've made some hack in the current xul:tree implementation in order to add new content below cells. The new content, named "description", is subdivided into "item"s. Each item could be customized. There's two new pseudo classes (-moz-tree-description, -moz-tree-item) and a new property (multiline). Each item could be associated to properties (like a cell). Each row could host a different number of items.
The idea is to allow a tree to display a "multiline" row. So Thunderbird could display in the first line the classic cells (you have to define explicitly the height of a cell, and each cell could has different height), and in a second line, the subject, followed by the preview. If the subject and the preview are two large for the row, they are cropped. The description use all the height available (multiline). All rows of a tree have to have the same height (for perf issues), but I'd like to try to implement a variable height if this kind of hack is in the right way.
Subject and preview are displayed. Subject is the first item, a colon is the second one, and the preview is the third one (only subject is displayed if there's no preview). Only new messages have a preview content (used in the new mail notification window), and I don't want to force the preview fetching because it means TB would have to download each message displayed in the threadPane.
Bad points: I don't know how to deal with hierarchy yet. There's some bug about coordinates retrieving (tooltip and click are affected, the "listening" zone is too large). It's required to add a margin to the description (in order to avoid overlapping with cells). And much more :) ... a lot of work is still needed.
Well, the result looks good, but it implies a layout hack, and I'm not sure it's allowed (but it doesn't break the API).
So, does this way sound good for you ?
It looks excellent!
I LOVE Thunderbird and Mozilla (and of course Firefox and Sunbird).
This is so cool, so I dare not to believe it =)
I would love to use any version of Thunderbird, that have this patch applied! I'd change immediately =)
What would you say the TODO list is before it can be commited? E.g.?:
* De-layout hack it to satisfy MozillaMessaging
* Add hierarchy
* Add a margin to the description
Before all, I need to know if such way is the good way (but I can't figure any other way than a layout hack).
Then, since the description box (which holds items) floats over the cells, it needs a margin. Currently, margins are defined in the CSS file.
For instance, description element shown in the attachment 307017 [details] has a top margin and a left margin (in order to not overlap cells). But if you move unread or star cells, description will overlap cells :/ So, either I could compute automatically the size of the margins (considering the cells positions and size, but it's tricky) or TB UI could make some cells immobile or cells could all have the same height (but then, there's no way to have the same look as shown in attachment 307017 [details]).
Then, I need to think how to deal with hierarchy and how to allow rows with different heights (without perf issues).
Wow, I'm the one who started the mozillazine topic on this way back in 2004, that's my original screenshot, attached... It's so awesome that there's finally some work being done on this, it looks good! Hopefully this works out and it makes it into TB3, or as an extension.
Paul, while I am a relative Mozilla newbie, I think I can say that this will not get the attention it deserves without some reorganization. I would suggest that the mozilla/content and mozilla/layout work be moved to a new bug that this bug depends on. Then you could set the correct product and component fields, and ask for review from the people with the power to make changes there.
From a mailnews perspective, I think this is awesome work that deserves to move forward.
Are there any news?
Are there a change for it to be a feature in TB3?
As Kent suggested, I will work on a two separated patches (layout & TB). So first, I must fill a bug about a treeView extension and make this bug depending on the layout bug.
*** Bug 430089 has been marked as a duplicate of this bug. ***
This looks like good stuff. Reassigning to Paul, since he's working on it. I'm not sure whether this wants to block Tb3, but I suspect that it falls into the "low-hanging UI fixes" bucket pretty nicely. clarkbw, any thoughts on that?
really nice indeed! if it's not a vast amount of difficult work or a perf problem, may i suggest:
1)number of additional rows is a user variable, instead of just the current one. toggle is still one row or all.
2)cells are user variable, based on columns available. only applies to additional rows, not the primary.
(pref.multiline.row1, "lines, size");
(pref.multiline.row2, "tag, attachments");
the flexibility of this would be a killer feature.
(In reply to comment #33)
> As Kent suggested, I will work on a two separated patches (layout & TB). So
> first, I must fill a bug about a treeView extension and make this bug depending
> on the layout bug.
Is bug 307070 going to be dupe of this, the other (split..) or become a dependent one. It touches only a part of it, the content of the multiline to get txt preview
I would have made it dupe, but comment 33 stoped me.
Great job Paul! Very handy feature this is. Can we expect this for v3.0?
The "Target Milestone" for this bug (at top of this page) has been set on "Future"! I really really like this for Thunderbird v3.0 ...
Did I say that the vertical view layout is actually useless without a compressed layout on message list column?? ;-) Or one needs to have a 17" monitor at least to deal with it... Not suitable at all for laptop users (mainly on 13"-15")!
*** Bug 455938 has been marked as a duplicate of this bug. ***
This is one of those polish bugs that help people view TB as a professional productivity suite or not.
I hope this will be included in 3.
marking p2 (which may be high...), blocking minus, wanted +, b2. A lot depends on whether the rich tree stuff happens.
Will this feature be merged in main branch of Thunderbird 3 ? Looking forward to this feature indeed
Paul do you still have the patch in two phase lying somewhere ?
bug 441414 must be fixed before, but honestly, I don't have time to work on it. And the current patches (both for this bug and for 441414) are the most recent code I have.
*** Bug 483205 has been marked as a duplicate of this bug. ***
*** Bug 269992 has been marked as a duplicate of this bug. ***
Sorry for that stupid question but how to get and install that "treeView enhancement: draft" patch? I'm using Thunderbird Version 188.8.131.52 (20090812) and looking forward to an Outlook View.
*** Bug 481606 has been marked as a duplicate of this bug. ***
Please see http://forums.mozillazine.org/memberlist.php?mode=viewprofile&u=539005&sid=4d0e7610400d3465c860a5d3511bb72f and reconsider to implement this feature in TB3... really, I don´t understand this feature request is sistematically ignored.
It´s an thing that TB3 can take advantage to obtain more users around the world.
The correct link is http://forums.mozillazine.org/viewtopic.php?p=7778805&sid=4d0e7610400d3465c860a5d3511bb72f#p7778805
Thunderbird 3 is almost ready for final release. We are way beyond the point where new features can be added. The patches that have been submitted for this bug are now over 18 months old and will probably need work to be integrated into the main tree.
You can hope that this will make it for 3.1 (or whatever the next release will be) but I think this will require some significant work. A release candidate is not the time to be adding features like this.
I must agree with Fernando. I've been waiting for this feature to be implemented for over 2 years now. I will not move to TB without this view. With Outlook 2010 just around the corner, which looks like it's going to be a worthy upgrade from 2007, I'm afraid those of us who are waiting for this feature end up never moving to TB.
Many people want this, but a count is not needed. Please refrain from comment unless you are contributing to fixing this - https://bugzilla.mozilla.org/page.cgi?id=etiquette.html
I think the TB3 Team needs to review the history:
-May 12, 2008 TB3 Alpha 1 - Comments #20 to #34 was ignored
-August 12, 2008 TB3 Alpha 2 - Comments #35 to #39 was ignored
-October 14, 2008 TB3 Alpha 3 - Comments #40 to #41 was ignored
-December 9, 2008 TB3 Beta 1 - Comment #42 was ignored
-February 26, 2009 TB3 Beta 2 - At this point the last 22 Comments was ignored
-July 21, 2009 TB3 Beta 3 - Comments #43 to #47 was ignored
-September 22, 2009 TB3 Beta 4 - At this point the last 27 Comments was ignored
-November 24, 2009 TB3 RC1 - Comments #48 to #49 was ignored
-December 1, 2009 TB3 RC2 - At this point the last 29 Comments was ignored
The TB3 Team can do their own patches for this simple feature: 2 lines message list in 3 column view
I can see people requesting this since TB2 and nothing was considered?! The community was sistematically ignored in this request. In TB2 was a feature for TB3 and now is a feature for TB3.1 ???!!
See forums, use Google to search about this and then know what the (simple) users needs!
"Thunderbird 3 is almost ready for final release" ... well make it unready and do this feature! It´s the time!!!
"We are way beyond the point where new features can be added" ...No comments... Anyone know that the TB3 Team can do RC3, RC4... I can´t belive this is too complicated feature to be implemented NOW!
When TB Team start hear the community requests the TB Project will get the same visibility as the FireFox 3.5 has today!
Remmember: Is a community request and not simply a "Outlook like style".
Thanks a lot!
*** Bug 535390 has been marked as a duplicate of this bug. ***
In one week this bug will be SEVEN YEARS old!
By now, it's the only serious issue that is preventing me an several friends and colleges from finally making the switch over to Thunderbird. A simple Google search reveals hundreds of other people either baffled that this is not possible in Thunderbird or requesting the implementation of this simple feature. And rightfully so, having three vertical panes in Firefox is borderline useless due to this idiotic limitation. And have you even tried using Thunderbird on a netbook? It's an incredibly uncomfortable experience when you're used to the superior UI of other e-mail-clients.
By now just about every notable e-mail client and even several webmail UIs offer this view.
I guess in another seven years standard desktop monitors will be wide enough to compensate for this issue, but by then desktop-e-mail-clients may be a long forgotten thing of the past anyways.
I really don't understand why several promising patches for this ridiculous issue went completely and utterly ignored and that in SEVEN YEARS not a single person of Thunderbird's core developers even considered that this may be a usability problem worth fixing.
(In reply to comment #57)
> I really don't understand why several promising patches for this ridiculous
> issue went completely and utterly ignored and that in SEVEN YEARS not a single
> person of Thunderbird's core developers even considered that this may be a
> usability problem worth fixing.
1. There is only one patch on this bug. That bug was not requested for review.
2. The developers have expressed interest in the volunteer fixing the patch.
3. Said patch requires a change to core layout. Which has yet to be fixed (see that open bug in the Depends On: field).
This was in fact wanted, and someone did volunteer to work on it, but was unable to drive in the core change on which this depends.
I completely agree with Frank!
It is almost unbelievable that Not a Single developer seems to be able to fix that.
If you're trying to base a companies mailingliste system on thunderbird then no one accepts an excuse like: it's too difficult (when anyone else does it) or "no developer wants to do it" (this would Be the most unprofessional excuse you could make)
So I think Mozilla should make a decision here and stop complaining about the ones complaining. Because whoever says we Need that preview list is absolutely right.
This issue should Be discussed and solved once and all.
Sorry for all those typing errors. That damn iPad just Wirtes whatever it wants!
To expand on comment 58, this bug is not unique - there are too many bugs and too few patchers. Paul - a volunteer - gave this bug a good start, but a new volunteer is needed.
And so until someone steps up to provide an updated patch (or someone in this bug recruits a friend to do the work), "complaints" and comments lamenting the state of affairs do not help this bug make progress. you may disagree, but stating that here wont change the fact that this simply isn't a priority for the product ATM, and comments that don't involve making progress on the code are just going to piss people off. https://bugzilla.mozilla.org/page.cgi?id=etiquette.html
(unassigning paul per comment 45 and his permission)
People are already **** of as it is because of the missing feature.
You can refer to etiquette or missing resources or whatever, but frankly what counts is that there should be some effort to solve the problem. Why not just make an open request to all current developers and ask them to work on e issue at hand rather than discussing why it has not been solved so far.
This would lead to results and not to discussions.
Kristo, I understand that it's frustrating to see issues that you believe should be fixed still around, and that's completely valid. If you wish to express that frustration in a Thunderbird-related forum, <http://getsatisfaction.com/mozilla_messaging/topics/> is a great place to do that.
Bugzilla, however, is a technical forum for development, and over the years, we have a lost too many developers because they feel that Bugzilla is not a pleasant place to work. The result of this means that important bugs that aren't getting fixed specifically because we have fewer developers than we otherwise might.
Comment 62 was a second case of you violating the etiquette _immediately_ after Wayne (and Joshua before him) asked you to stop.
While we very much want feedback from whomever is willing to give it, if I'm forced to choose between enforcing the etiquette rules in order to make Bugzilla a more pleasant place to work and keeping your Bugzilla account enabled, I'll choose the "pleasant place to work" every time. So please don't violate the etiquette yet again, or I'll be forced to disable your account.
For what it's worth, I think alot of people feel like you do on most arguments, but it's indeed not pleasant for developers to read certain ways of describing your frustration. I mean, they are giving their time for free after all..
This problem may as well be the typical issue for open source and maybe thé one issue that keeps a lot of open source "winning" today , namely that certain features (that a lot of people want) are just not wanted by the developers and never get in (somtimes in combination with difficulties of architecture).
But who can blame them, right? It's only that more reason to try and please them.
Anyway, from an open source developer, which I am, to any other developer reading this : Keep your head up, we dó appreciate your efforts and try to read our sometimes too quickly posted frustration with a positive note. We all mean well after all (we are just too human sometimes :-) ).
And with this I also would like to express my love to see this feature happening. *grin*
P.S. People, don't forget to vote (on top) either!
Correction (Apologies! Unfortunatly no edit option):
..maybe thé one issue that keeps a lot of open source FROM "winning" today..
Even if Thunderbird is usable without it, that's a very old (see http://forums.mozillazine.org/viewtopic.php?f=30&t=17450 for example in 2003) and indispensable feature, essential for small screens (< 15").
So I subscribe to this "bug" (in fact, a base feature of all mail clients and webmails except Thunderbird for an unknown reason).
Nevertheless, I use Thunderbird : it's not the worse!
i can't believe that this is a soo big problem to change the code? why is it possible in other e-mail clients and even micro$oft manage to get this "feature" in their outlook...why Mozilla don't?
i think it IS a very important function for usability and clarity!
it's really sad that nothing happens about this issue since 7 years - !! SEVEN YEARS !!
When will there a fix available?
Please update, this is really urgent. The Message overview list is very cruel and with userchrome.css you can't get very far.
Well... I'm switching back to Outlook this weekend. Yeah yeah this is not a place for such posts but sorry guys - there is no movement to be seen here and my time is really too valuable to be wasting it with getting frustrated every single day over this. Thunderbird is seriously unusable the way it currently is. Email clients are an essential part of our everyday lives and Thunderbird is not the only app out there.
Good luck for the future.
so what is the problem to change the message view? is the "outlook view" patented? i still can't believe that this is a really big problem to change in the code! it's really sad that nothing is changing here!
This is the only Thunderbird bug I'm still subscribed to. I seriously didn't expect it to be unresolved after almost 8 years.
It's essentially the only bug keeping me from using Thunderbird.
I'm currently, not all that happily, using Outlook. I have been hoping for this silly problem to be resolved in under a decade - but I guess that is too much to ask for.
Well, technology is changing and switching to a powerful webmailer like gmail is increasingly becoming the more likely choice when considering Outlook alternatives.
It's a shame, Thunderbird appears to slowly going the way of the Dodo ... or should I the way of the Seamonkey?
Moaning about this feature in the comments is unlikely to achieve anything, apart from annoy those of us who are CC'd into this bug. If you want this feature to be implemented, please add a vote for it if you haven't already done so. If it receives a high number of votes then hopefully it'll become popular enough to be implemented in a future release.
The code that was added to this bug was never properly tested, and a number of years and Thunderbird releases have passed now, so it'll need a lot of work before it can be added to the trunk. It's a real shame but unfortunately the priorities of Thunderbird's developers lie elsewhere at present.
For the record, I use Thunderbird every day for my job, and it works much better than any version of Outlook that I've tried.
It's fairly shocking that this remains unaddressed, but to be honest I think this is indicative of Thunderbird generally having become an extremely stale piece of software. I jumped ship to Windows Live Mail a few years ago and have found it to be an excellent piece of software, utilising the view sought by this very bug thread and being more casual-orientated than Outlook. Its development is also very active, with the software having almost completely transformed over the last few years. It makes full use of the ribbon to boot, which I like.
Suggest giving it a try if you're a frustrated Thunderbird fan who isn't keen on Outlook like I was.
i would switch back to outlook if i weren't using Ubuntu/Linux.
and i don't like running software with an emulator.
This bug requires bug 441414 to be fixed, which is a core Gecko bug. Until that bug is fixed, there is no way that this one can be fixed.
Unless you are specifically working to fix this bug, DO NOT COMMENT ON THIS BUG.
To elaborate on Joshua's response, we are also approaching this bug from other angles that are actively being worked. Specifically, using the HTML DOM as a more flexible and efficient means of displaying in the 3-pane.
I recognize that approach may have its detractors as there are many who do not appreciate Thunderbird moving in the interface directions of webmail or of potentially losing any of its native theming. We are sensitive to these concerns but the HTML DOM still remains the best avenue to technically address this problem. There is no risk of us gaining a paging idiom like webmail clients, and it will still be very possible to style the interface to appear native. Most importantly, at no point will be taking away the existing 3-pane from those who prefer it above all other interfaces.
As Joshua says, please don't use this bug as a place to discuss meta-issues or vent. If you want a place to discuss related issues, you can try our getsatisfaction instance at:
If you want to vent, please find an entirely different venue, as we have volunteers working hard on getsatisfaction to help people out with support topics and negative energy doesn't help the people working to improve things (here in bugzilla, or on getsatisfaction) to actually improve things.
*** Bug 644589 has been marked as a duplicate of this bug. ***
apple's mail.app now has a multi-line message list display. it was added in the 10.7 o/s release.
The 441414 bug(In reply to Paul Rouget [:paul] from comment #45)
> bug 441414 must be fixed before, but honestly, I don't have time to work on
> it. And the current patches (both for this bug and for 441414) are the most
> recent code I have.
I have added a project on FossFactory for bug 441414 and donated $100. It has only been up an hour and another kind person has donated ~$50, so there is a little cash in it for anyone willing to do the work.
Find the project at:
This feature, or lack thereof, is the main reason why I just access Gmail in a browser now. Never thought I'd resort to a web client. The T-bird UI is just so cluttered and outdated. Mozilla in general seems to have gotten a bit stagnant on innovation. Both Firefox and Thunderbird have gotten slow and buggy. With lightning installed T-bird uses ~400MB. Unfortunately, on Ubuntu it's the only option. I'd like to see a UI overhaul with less clutter and better thread viewing. Make it a mail client again, and strip out the bloat. Integrate with the system address book and a standalone calendar. I'm thinking of getting involved on the dev side, but I don't know if it's worth it.
Hello my fellow Mozillans,
I was brought to this bug by a commenter on another technical web-site. Yes, I have read all threads here b4 commenting. Let me say this to all newbies and community members (users): PLEASE, PLEASE, leave your comments @Mozilla Forum, Thank You.
To Developers: Thanks for the many years of great work here @Mozilla. Please, allow me to indulge on this particular bug. I say that the reason ThunderBird IS ThunderBird is because it is NOT Outlook. The idea of this mail client program/app. is to provide an essentially easy, intuitive, and beautiful user experience with regard to E-mail. In this regard, ThunderBird excels thanks to all the developers/volunteers on the project. That is what makes Mozilla UNIQUE.
Having said that let's review all past comments and ideas:
1. Comment #19 provides the best of both worlds: the unique Thundeerbird design with the option to change view/design thru the menu.
2. Comment #26 seems to been implemented on subsequent ThunderBird releases if I am not mistaken.
3. This "outlook" design concept, which provides certain functionality that allows for user ease of use, I believe, that many don't know its use or do not use it. Question: To what benefit does this provide for the user and can ThunderBird fulfill this niche?
4. With the introduction of HTML5, and other tools, is this possible? Does the UI interface inter-operate w/in Html5 to allow the change w/out compromising the ThunderBird Architecture? If it does, then we don't need this feature, since ThunderBird is Uniquely built from Outlook.
5. An Alternative could be to build an add-on: A Specialized add-on (maybe a new category?) that allows one to download and install and will provide this particular "outlook" design on Thunderbird. This thus provide for simply modifying the overall architecture for those that want the Outlook design function. It is a Specialized Add-On, as apposed to existing add-ons (extension, theme, whichever). Just an Idea, my 2-cents here really.
This is one of these projects where developers just keep scratching their heads and says, "what's the heck?" Frustrating? No. Challenging? Yes. It just needs time, and a lot of thought as to what it will accomplish or how it will be accomplished (if undertaken).
Best regards, and happy adventures to all in 2012. Make the best of it.
Wow this bug has been around for a while. Even on a widescreen monitor, the columns are too scrunched & it's hard to read the mail. I wish there was something I could do to help but I'm hoping for a solution. If anyone can do it, the Thunderbird developers can!
For any developer out there that doesn't find any motivation to do this (or depending bug) for free, I'm sure A LOT of people would pay a small amount, resulting in a big enough sum. So, here is my suggestion:
Make a "bounty" for it and earn some money on it!
I guess the current most popular platform for that, would be: www.kickstarter.com
One found from previous comment: www.fossfactory.org
Then make sure to post the bounty on all the existing topics. Here is an overview for some topics: https://getsatisfaction.com/mozilla_messaging/topics/thunderbird_how_to_have_subject_of_messages_on_two_lines#promoted_reply_5716788
For any non-developer out there: Please find a way to let the developers know about this suggestion. (I guess this bug must be on their ignore-list by now. :-) )
Another way is google summer of code. Honestly I dont use tb because of the way it shows msg list.
Just like Ruchir I no longer use Thunderbird due to its antiquated and for modern screen resolutions absolutely inadequate message list view.
I'm pretty sure that what's left of the Thunderbird developers are aware of this bug, but don't consider it a serious issue - and everyone who stuck with Thunderbird for this long is most likely quite happy with the status quo and sees no reason for any design updates.
Next year it will be this bug's tenth(!) anniversary. I'd suggest to simply close it as "won't fix" on said anniversary.
I think it's fair to say that hoping for any future feature updates like this is somewhat futile, considering that Mozilla has officially ceased development of Thunderbird. Best to just move onto other software, guys. Alternatives now exist.
"no longer be focused on innovations" just means there will be no large features created from within the Mozilla Foundation. In fact it also states that the further development would be more "community-driven" in the future.
1. Not a reason to sitch to another client
2. Well, if the community's opionions get more weight...
(In reply to Frank Freibuth from comment #85)
> Next year it will be this bug's tenth(!) anniversary. I'd suggest to simply
> close it as "won't fix" on said anniversary.
(In reply to mozilla.org2 from comment #86)
> I think it's fair to say that hoping for any future feature updates like
> this is somewhat futile, considering that Mozilla has officially ceased
> development of Thunderbird. Best to just move onto other software, guys.
> Alternatives now exist.
Take the time/care to notice that this is blocked on factors other than TB developers. Thanks.
Also, TB development issues are best covered outside of bug comments. ref: https://wiki.mozilla.org/Thunderbird/CommunicationChannels
Therefore, please STOP spamming the bug with such comments unless you are in a position to help move the bug forward.
Up to anyone who has joind to CC of this 2003 bug, but I for one moved all the mail to google and use gmail now. Thunderbird was good when it was as well as kmail and evolution. Not anymore. The paradigm has changed and you can't adapt 10+ years old code to it. And since Mozilla just dropped the thing on the floor ... I'd better off with gmail extensions. YMMV.
Yes, Thunderbird is just a decaying and neglected husk of a browser. I personally use Windows Live Mail as it offers the very UI discussed on this page, but other alternatives are out there. Just makes no sense to stick with Thunderbird, even its developers gave up on it.
Wayne Mery, this is a feature request thread and not a bug — even if it is technically in a bug reporting system. If you're not happy with us discussing the feature and its future development (or not) then kindly unsubscribe. Thanks.
Gmail (or other webmails) are not a substitution for Thunderbird for some use cases.
I hate doing that, but this is just killing me, sorry:
I am a Mozilla developer. I have tried to fix this bug before.
And as a developer, I get hundreds of emails every days about different bugs. 99% of the time, people discuss calmly, in a respectful manner. Not everybody is happy, but that doesn't prevent people to be nice.
But there's this 1%. Bugs getting "hijacked" by aggressive people. I fear that might happen here.
What happens when we get bugmails with comments like @ryanjohnwilliams's comment? We just unsubscribe, and give up on the bug. Because working in these (bad) conditions is no possible.
@ryanjohnwilliams: Bugzilla is the place where developers talk about technical issues. If you want to talk about this Feature Request, please use the mailing lists. You'll have more chance to reach the right people, and you won't bother the wrong people.
@all: Please understand that fixing this bug requires fixing a Gecko bug, that is _very_hard_ to fix (bug #441414), and there's not many people capable of fixing it. I filed this bug, and also tried to fix it myself. And believe me, every time someone is ranting in this bug, this just demotivate us to even try to fix anything.
Please, just be nice.
I propose to implement this type of message list without using the XUL tree element (which bug #441414 is about). It is just not designed for this purpose.
Creating this new list based on a combination of other XUL elements is certainly possible in my opinion the best way to ever see this proposal happening. Someone could even do it within an extension for prototyping purposes.
Would you be up for this task, @Paul Rouget?
I am not expert of Gecko/XUL but what surprises me is that this kind of list is already implemented in addons list of firefox (list items contain icons, subtitles, buttons, etc.). Can't the list under question be implemented using the same technique?
(In reply to Eduard Babayan from comment #94)
> I am not expert of Gecko/XUL but what surprises me is that this kind of list
> is already implemented in addons list of firefox (list items contain icons,
> subtitles, buttons, etc.). Can't the list under question be implemented
> using the same technique?
No, because the "list" in question is not a list but actually a tree; there is no <richtree> equivalent to <richlistbox>. Actually, it's even more complicated, since <richlistbox> works by having nodes in the DOM tree for every row in the tree, while the <tree> that drives the thread pane uses nsITreeView, so the DOM tree doesn't have nodes for every row in view. This, I think, explains why fixing the underlying feature to add this functionality is so difficult.
On the other hand, changing this facet is a non-starter: you'd either have to reimplement ~10KLOC or implement a very hacky glue layer just to drive the layout, and I suspect there would be severe performance impact in forcing the DOM tree to have to handle all the additional nodes as well.
As far as I remember, the XUL tree is very list-like in its nature (the function getCellText, f.ex., just works on (list-)rows).
I already created DOM trees with thousands of elements without a severe performance impact (which surprised me as well - though these trees where heavily nested and just a fraction of elements (CSS-)visible at once), but even if this should become a problem, then there are ways around it. DOM nodes only have to be created for the visible items and the size of the to-be-scrolled box can be calculated based on the number of rows. As I said, I'd rather go with a combination of XUL elements in the DOM, than using (read: fixing) XUL tree for rich content (which I don't see happening).
I don't think this type of view is supposed to provide all the features the tree view provides. No need for all possible columns and whatsoever. I'd propose we start with something simple, that works for most of the users who want this feature.
I'm just curious: how would one retrieve the data needed for the list (the messages and the according data like read-status, etc.) via JS?
Showing + building only the visible element is an option (updating the list while scrolling). I also think it's the only realistic way to do it. The challenge will be to keep this updating mechanism smooth while scrolling.
> I'm just curious: how would one retrieve the data needed for the list (the messages and the according data like read-status, etc.) via JS?
That's actually the easy part: just use the treeView used by the xul:tree. Basically, reimplement what a xul:tree does, and implement the nsITreeBoxObject interface.
I am new here, but also very sad about the situation, but I might have an idea.
If that "list" is a tree - why not only use two nodes for one mail instead of one?
+ Mail One firstname.lastname@example.org 12/12/13
+ Mail Two email@example.com 12/12/13
+ Mail Three firstname.lastname@example.org 12/12/13
+ Mail One 12/12/13
+ Mail Two 12/12/13
+ Mail Three 12/12/13
This might not be the nicest solution, but in my opinion better than no solution and easier to implement as a whole new tree-type. And the number of entries would only dublicate, what shouldn't be a problem for todays hardware.
It also would have the nice "sideefect" that you could hide the "From" field to make your view even more compact.
Might this be an idea?
The postbox guys (http://www.postbox-inc.com/) can do it with their TB-based client. Why is it such a problem for the Mozilla guys?
Maybe the TB developers should swallow their pride, call postbox-inc and ask them for advice, help or simply some piece of code. I'm pretty sure they're gonna talk to them.
Hello. We are trying to do a massive UI redo, along with some concept ideas. Bwinton has looked them over, and agrees with the points. A link to it is at the MozillaWiki, under TB -> UX, but here's the link we are going for: http://infinite-josiah.blogspot.com/2013/02/thunderbird-ui-concept.html
Point 9 consists of 2 ideas, this bug (updating the mail list view to be optimized for vertical) and updating the UI for the actual message content plus having a better conversation view. This bug handles the first point.
The sketch created, which can be seen from the link, shows how the columns could be formatted.
Essentially though, it looks like:
However, the mockup created by Steven Garrity could also work, with a few changes. Mainly we need a place to hold the account (as one point is adding a combined inbox), and we need to have a number for the amount of mail in the conversation.
Anyway, we are pushing that blog post, so hopefully we can get a few more developers over here.
Although very difficult, it is possible (this is software after all). The real challenge is getting good developers over here and doing some re-writing.
(In reply to Josiah [:JosiahOne] from comment #102)
> Hello. We are trying to do a massive UI redo, along with some concept ideas.
> Bwinton has looked them over, and agrees with the points. A link to it is at
> the MozillaWiki, under TB -> UX, but here's the link we are going for:
This looks great, I can't wait to see this beeing realised.
*** Bug 855157 has been marked as a duplicate of this bug. ***
(In reply to Josiah Bruner [:JosiahOne] from comment #102)
> Hello. We are trying to do a massive UI redo, along with some concept ideas.
This looks promising. Thank you for your efforts.
So I'm going to take this for now. I am looking at other approaches to this, besides using Treeview, since, although TreeView would be preferred, it clearly isn't getting fixed anytime soon. So for now, I'm going to see if it can be accomplished using something else.
I might even see if I can just get HTML to accomplish this, but we'll see.
Note: I do have quite a bit of other things to do, so it might be awhile before I update again, don't think I have forgotten about this bug, because looking at the ugly three-paned-vertical view everyday will keep me on task.
You really should check the work that postbox has done on this, particularly in treeview, that you can download from:
Their changes to treeview are done (by necessity) under the MPL, so you are free to incorporate them.
(In reply to Kent James (:rkent) from comment #107)
> You really should check the work that postbox has done on this, particularly
> in treeview, that you can download from:
> Their changes to treeview are done (by necessity) under the MPL, so you are
> free to incorporate them.
Hey cool. That should help a lot. Thanks Kent!
@Josiah Bruner: I totally support the idea of just using HTML. As I see it, with web components starting to land in FF (see bug #783129), XUL is not going to stay forever - HTML is more future proof. While were at it, I'd probably also use the new HTML flexbox model (dunno how much that differs from the XUL flexbox model though).
(In reply to A. Sel. from comment #109)
> @Josiah Bruner: I totally support the idea of just using HTML. As I see it,
> with web components starting to land in FF (see bug #783129), XUL is not
> going to stay forever - HTML is more future proof. While were at it, I'd
> probably also use the new HTML flexbox model (dunno how much that differs
> from the XUL flexbox model though).
We'll have to see about that. Right now I am looking at Postbox-inc to see what they are doing. It seems to be that they successfully re-wrote the TreeView layout, so I might use that.
HTML is actually not the ideal plan simply because of how ugly it is and because it could be (potentially) unreliable and slow.
However, I do have an html mockup that works, so if I could use that, it could be handy.
We'll see. Like I said, I have quite a bit to do so expect updates to not be for a few weeks.
Unfortunately like everyone else now, I am way to busy to take a look at this. It's quite unfortunate, as I would really like to see this bug fixed, but it simply isn't happening anytime soon. We just don't have enough people actively working on TB for us to take time to fix this. At least not right now.
Hopefully one day a new volunteer will be able to devote all their time into this, but for now, this is not so. :(
Unassigning myself because there is no way I would have time to work on this for many months.
XBL, web components, etc. would be much slower than the tree widget. Memory footprint would increase too. I have a lot of stuff on my plate, but I would be actually quite interested in bringing the new tree widget feature to Gecko. I still hope that the tree widget will show in HTML 5 again, then you will be able to get rid of XUL.
@Josiah - I am ready to take this and develop the feature. However, I do not know how to get started as this is my first Mozilla Project. Can you give me pointers to ramp up?
(In reply to Josiah Bruner [:JosiahOne] from comment #111)
> Unfortunately like everyone else now, I am way to busy to take a look at
> this. It's quite unfortunate, as I would really like to see this bug fixed,
> but it simply isn't happening anytime soon. We just don't have enough people
> actively working on TB for us to take time to fix this. At least not right
> Hopefully one day a new volunteer will be able to devote all their time into
> this, but for now, this is not so. :(
> Unassigning myself because there is no way I would have time to work on this
> for many months.
Byebye TB, as this took far too long (3 years now) I switched me and my customers to Postbox.
(In reply to Frank Thommen from comment #114)
> Byebye TB, as this took far too long (3 years now) I switched me and my
> customers to Postbox.
This type of comment is not helpful or constructive to this bug. In fact this negative behavior will only slow development processes by driving away any future volunteers. Please read https://bugzilla.mozilla.org/page.cgi?id=etiquette.html and abide by such rules or your account may be suspended.
(In reply to Rahil Parikh from comment #113)
> @Josiah - I am ready to take this and develop the feature. However, I do not
> know how to get started as this is my first Mozilla Project. Can you give me
> pointers to ramp up?
> (In reply to Josiah Bruner [:JosiahOne] from comment #111)
> > Unfortunately like everyone else now, I am way to busy to take a look at
> > this. It's quite unfortunate, as I would really like to see this bug fixed,
> > but it simply isn't happening anytime soon. We just don't have enough people
> > actively working on TB for us to take time to fix this. At least not right
> > now.
> > Hopefully one day a new volunteer will be able to devote all their time into
> > this, but for now, this is not so. :(
> > Unassigning myself because there is no way I would have time to work on this
> > for many months.
I am _so_ glad you are willing to take this bug, I'm sure everyone would appreciate it. Here are some things to get you started (You may have done some of these already)
A. Thunderbird Source/Build setup
You first will want to set up the TB build enviroment, which is very simple if you follow the instructions here: https://developer.mozilla.org/en-US/docs/Simple_Thunderbird_build
That should get you up and running.
B. This bug, choices
You have a few options for this bug:
The first is to check out Postbox Inc.'s source and try to figure out how they accomplished this richer mail list. However, they are based on a very old version of Thunderbird so this may be quite difficult to reproduce.
Choice two is to fix bug 441414 first (Update the treerow API to allow richer formatting), and then use this bug to implement that updated API. This is most likely the ideal approach.
Choice three is to implement an entirely new API and write tests for it (Probably the most difficult, but perhaps the most useful)
C. Ask questions!
Please, ask as many questions as you need. The best place to ask such questions is either in this bug or better yet on IRC. irc.mozilla.org, room #developers or #maildev is the place to inquire about _any_ info you might need. Even questions that seem basic are completely acceptable, especially since the codebase is so large.
D. Perhaps take a smaller bug first, just to get the hang of things
It may be useful to take a smaller bug, just to get a hang of the codebase, creating a patch, landing a patch, etc. A small bug shouldn't take too long at all, but will vastly help your understanding.
So hopefully that helps you in some way. Again, anything you need, feel free to ask about. I would love to see this bug realized! Whenever you get started working on this, go ahead and assign this bug to yourself. Thanks again!
Josiah Bruner, IRC nick: JosiahOne
Rahil, I wanted to second Josiah's welcome and say that any work on this feature request will be greatly appreciated throughout the community, whether you choose an add-on style fix, a reintegration of the Postbox fork, or want to dig into 441414 and increase the general robustness of the UI. Your efforts are welcome and appreciated, and volunteers are the gold medal members of this community.
Hi Rahil, Do track the fossfactory bounty of $412 (http://www.fossfactory.org/project/p294). Its a tad confusing bounty is a tad confusing because it lists bug 441414 in the subject, but the description is really for this one (213945). I suspect the bulk of sponsors really want this bug fixed. If you choose to fix this in a way that doesn't also fix 441414 please create a different bounty (or ask to have that bounty updated) so I and others can transfer our funds there.
I'll add I personally would happily throw additional $ in for a bounty that is specifically for fixing this bug (vs 441414).
Also, note PostBox is now at 3.0.8. I just tried tweaking the above link to have 3.0.8 instead of 3.0.7 and it seemed to work - http://download.getpostbox.com.s3.amazonaws.com/source/3.0.8/postbox-3.0.8-mpl.tar.bz2.
Its also probably worth reaching out to PostBox also to see if they have any additional source/info the want/have to share under MPL. I'm not sure the best way to reach them (my #1 complaint about PostBox is there lack of direct support), but there is a PostBox person cc'd on this bug. So perhaps you could start with him.
We are now in the mid of 2014. Any positive follow-ups on this?
It would be really great if Thunderbird was to support a Mac OS X vertical view!
There is a also an extension for Thunderbird which aims at something similar.
Maybe it is worth working together with this developer?
In the last weeks there is lots of movement in bug 441414 https://bugzilla.mozilla.org/show_bug.cgi?id=441414 . I just like to bring that under your attention.
I hope now it will happen!
(In reply to pieter kristensen from comment #121)
> In the last weeks there is lots of movement in bug 441414
> https://bugzilla.mozilla.org/show_bug.cgi?id=441414 . I just like to bring
> that under your attention.
> I hope now it will happen!
There may be movement, but the implementation that patch author appears to be going for would be almost completely useless for this bug. I mentioned it offhand to the author in IRC and he (she?) doesn't appear to care.
(In reply to Yet Ding from comment #120)
What happened with this addon? It's gone. :-(
+1. Is this feaure under development?
Maybe there is some stuff that can be looked up in the source code of geary: https://code.launchpad.net/geary
I happen to like the current Wide View display. Please be sure to implement this RFE as an option, not as the only view.
+1 for this new feature
Created attachment 8701651 [details]
messagelist-0.1.xpi - Addon to Demonstrate implementation
Instead of patching the treeview object, I tried the opposite approach reimplementing the message list in pure HTML.
The result is way better than I expected. I would rate the performance as good even with a 10000 item list. just give it a try. I packaged the experiments into an addon, which injects the html message list side by side to the "classic" treeview based list.
But keep in mind it is a poor mans implementation, which is in a very early state and has room for lots of optimization.
In order to activate the list you need to click on "inject", when changing folders click on "populate".
Displaying Unified inboxes and news folders may not work as expected.
But IMAP Folders in unthreaded and threaded view work fine. Grouping has still issues.
The code as well as a list with all open issues can be found at https://github.com/thsmi/messagelist
Give it a try and tell me if you think if it's worth investing more time into this approach.
good job! I only skimmed through the code (and I ain't a mozilla addon expert anyway), so I can not give you much feedback on that. The result looks very promising though and even works well with > 17000 emails.
Keep it up, I think many thunderbird users would appreciate this!
Great job Thomas :) . I confirm the experience with your HTML implementation is surprisingly usable, even in my 'All Mail' GMail folder with 25000 emails.
Interesting, thanks for the effort!
I see a line through the Subject line, but it does seem to already be very performant, so looks promising, especially if it can be optimized.
Cool, good to see this is going well. I'd recommend trying to use fastlist, since it should already address a lot of the issues you're likely to run into. I'm not sure how well fastlist would work with customizing columns, but you can probably hold off on that for a while anyway.
(In reply to Jim Porter (:squib) from comment #131)
> Cool, good to see this is going well. I'd recommend trying to use
> fastlist, since it should already address a lot of the issues you're
> likely to run into. I'm not sure how well fastlist would work with
> customizing columns, but you can probably hold off on that for a while
>  https://github.com/fxos-components/fastlist
You wrote "customizing columns". May be I am interpreting too much, but do you have a "one size fits all" solution in mind? A component which renders a grid (with single rows and customizable columns) as well as a rich list ( multiline, fixed layout without customizable columns)?
If so I strongly discourage from doing that. One thing I learned over the last years, it that all libraries/toolkits I had used are either good for grids or rich lists. Upto now I did not stumble upon any library which was good in doing both.
Instead it makes way more sense to cleanup the architecture and have a separate renderer for grid and one for a richlist. This can be achieved by cleaning up the dbView and folderview and adding a streamlined rendering interface similar (but a bit more generic, to avoid code duplication) to the existing treeview interface. So you'll endup with some kind of a pluggable message list renderer.
Those message list implementation can coexist side by side, as illustrated in the experimental addon. This allows to use different "technologies/toolkits/frameworks" for the rich list view as well as for the grid view.
The grid view should stick to the xul based treeview, and a decision about a new grid view implementation should be postponed to the future. The long term strategy should be either replacing the xul based treeview by a html based grid or following other mail clients and scrap the grid view completely. But such long term decisions are up to the module owners.
Concerning the rich list view, I think the best way to go is, to develop it as an addon. Which can be merged into the trunk as soon as all features are implemented and it is proven to be stable. This makes it way easier to test it by users and allows are more incremental development.
Is this ok for you? Or do you prefer a different approach?
Concerning the "fastlist". I did some tests. But it was not impressive at all. All my experiments had a similar result: with large lists the are serious issues. There are whiteouts and lags while scrolling as well as strange side effects. E.g. it happened more than once that the list did not stop scrolling when it should. Instead it continued to scrolling for one or two seconds. With small lists it's some how acceptable.
Did I miss something? Did I make something wrong? Is there any special reason why you suggested/promoted it? What makes this library special compared to other rich list implementations? With only 3 stars and two forks at github it does not seem to be popular or widely used at all.
As far I have seen it does not neither support multiselect nor drag an drop. But both "features" are essential for a Thunderbird integration. Same applies to a support for threaded/conversation view. Fixing those issues would require large changes and rewrites to the "fastlist".
You wrote "it should already address a lot of the issues you're likely to run into" what kind of issues do you have in mind? Currently I can not see any benefit which "fastlist" could offer.
(In reply to Thomas Schmid from comment #132)
> You wrote "customizing columns". May be I am interpreting too much, but do
> you have a "one size fits all" solution in mind? A component which renders a
> grid (with single rows and customizable columns) as well as a rich list (
> multiline, fixed layout without customizable columns)?
You can have two separate implementations (although I'm not convinced that this is the right decision), but I don't see much point in a multi-line rows unless you can customize at least some of the columns. We can't know exactly what columns people prefer for their use cases. See bug 441414 for an already-working (if incomplete) implementation that extended XUL trees.
> Concerning the "fastlist". I did some tests. But it was not impressive at
> all. All my experiments had a similar result: with large lists the are
> serious issues. There are whiteouts and lags while scrolling as well as
> strange side effects. E.g. it happened more than once that the list did not
> stop scrolling when it should. Instead it continued to scrolling for one or
> two seconds. With small lists it's some how acceptable.
It's possible that there are problems, or that you're just not using it in the recommended way. My experience with fastlist has been pretty good, but that's with lists of a few thousand items on memory-constrained devices (read: phones).
> Did I miss something? Did I make something wrong? Is there any special
> reason why you suggested/promoted it? What makes this library special
> compared to other rich list implementations? With only 3 stars and two forks
> at github it does not seem to be popular or widely used at all.
If you use the fastlist (or fxos-fastlist), you're using a library that has paid Mozilla staff supporting it, as well as keeping us closer to our friends working on the Firefox OS email app. (I believe the tb-planning list has some discussion about a desktop mail UI that uses the FxOS email app's backend.)
> As far I have seen it does not neither support multiselect nor drag an drop.
> But both "features" are essential for a Thunderbird integration. Same
> applies to a support for threaded/conversation view. Fixing those issues
> would require large changes and rewrites to the "fastlist".
Yes, the fastlist is still pretty basic, and I'm sure there are many features missing from it that you'd need for a desktop UX; it's primarily targeting phone UIs at the moment. However, I think it would be a lot more useful to try to get a general HTML-based replacement to XUL trees (single-line and multi-line), since there are multiple places we would like to eliminate them. Firefox Desktop would also find this work useful, I imagine. While fixing this bug only requires replacing one instance of a XUL tree, I'd much rather see us take this opportunity to help reduce our dependence on XUL.
> You wrote "it should already address a lot of the issues you're likely to
> run into" what kind of issues do you have in mind? Currently I can not see
> any benefit which "fastlist" could offer.
First, fastlist is a web component, which should make it a lot easier to use with relatively little modification as we excise XUL from Thunderbird. Second, it already handles destruction of not-in-view rows to keep memory usage down. It's also already got fairly good RTL support, which can be a major pain to deal with, especially when you have mixed-direction content.
"The long term strategy should be ... or following other mail clients and scrap the grid view completely."
While I certainly support a multi-line richtext view as an option, the grid view is extremely efficient at scanning lots of emails at once, which is an important feature of an email client. I don't think we really understand why Thunderbird continues to maintain its popularity versus other email clients, but personally I suspect that maintaining efficient methods of displaying information, against the trend of others, is part of the reason. I hope there is no move to scrap it, though replacing grid view with an HTML implementation will probably need to happen eventually.
Comment on attachment 8701651 [details]
messagelist-0.1.xpi - Addon to Demonstrate implementation
I'm afraid I don't currently have cycles to look at this - forwarding to Magnus.
Comment on attachment 8701651 [details]
messagelist-0.1.xpi - Addon to Demonstrate implementation
I agree this is interesting. It's too far from something really usable to be able to evaluate in any detail though.
(In reply to Kent James (:rkent) from comment #134)
> "The long term strategy should be ... or following other mail clients and
> scrap the grid view completely."
> While I certainly support a multi-line richtext view as an option, the grid
> view is extremely efficient at scanning lots of emails at once, which is an
> important feature of an email client.
This is very true - and driven home by the fact that Outlook, even in Vertical View, automatically switches to grid view if you widen the message list pane enough. It is only when the message list is pretty narrow that it is in this multi-line view. I think this is pretty smart, and what Thunderbird should shoot for.
Hope this finally gets into Thunderbird with next release.
Will implementing this break any of the following extensions?
Reply to All as CC
*** Bug 1267940 has been marked as a duplicate of this bug. ***
Note well: If I wanted an E-mail client that resembled Outlook or Lotus Notes, I would install Outlook or Lotus Notes. I use Thunderbird because I prefer its user interface.
@David: Outlook isn't running at all on most operating systems and Lotus is ugly. A lot of us are using Thunderbird because of its extensions, of its opensourced code, of its respect of web standards, of its functionality ... and maybe even for its user interface. Nobody is requesting to "copy" any other interface, and it should be optional, like many other parts of the interface. But since we're getting wider and wider screens and some longer and longer emails, it's obvious that a 3-column-layout might be better. And a two-line option for the mail list table itself, because of the possibilities you have then (more content per mail, and with a 3-col-layout you even have more space to fill ...) So: This is a feature I'm waiting for since years, that's why I voted and that's why I'm watching this :) Not sure why you're watching this, but let's hope it's unnecessary and Thunderbird people are not "forcing" as Firefox guys are doing ...
(In reply to David E. Ross from comment #139)
> Will implementing this break any of the following extensions?
> Reply to All as CC
Of those the only one I see that might be a real problem is CompactHeader, and because it is such a widely used Addon, I'm confident that if something did break there, it would get fixed rather quickly.
(In reply to David E. Ross from comment #141)
> Note well: If I wanted an E-mail client that resembled Outlook or Lotus
> Notes, I would install Outlook or Lotus Notes. I use Thunderbird because I
> prefer its user interface.
And the Vertical View has been a part of its UI since a very, very long time. I found a reference to it being in version 1.5, so at least that long.
This 13 year old bug is about improving the Vertical View mode, not doing away with Wide View mode (which I do prefer myself, incidentally).
*** Bug 1309889 has been marked as a duplicate of this bug. ***
I've been moving users from outlook to thunderbird.
I personnaly don't feel the need for that (as I never used outlook so much) but they keep asking me for this feature
Would be nice to have this feature as it greatly improves usability and most popular email programs support it, including Outlook, KMail (KDE), Evolution (Gnome), and Geary.
Yes, and even though someone took the first steps by creating an Addon (see comment 127) to implement this, alas, it doesn't seem to have picked up any steam.