Closed Bug 213945 Opened 21 years ago Closed 2 years ago

Mail/message listing/thread pane needs more organization in 3 vertical pane view (column wrapping, etc)

Categories

(Thunderbird :: Folder and Message Lists, enhancement, P3)

Product:
Thunderbird
Component:
Folder and Message Lists
Type:
enhancement

Tracking

(Not tracked)

Status:
RESOLVED FIXED
Milestone:
112 Branch

People

(Reporter: kevin.breit, Assigned: aleca)

References

(Blocks 4 open bugs,
URL
)

Details

(Keywords: ux-efficiency, Whiteboard: [Supernova3p][see comment 222])

Attachments

(2 files, 14 obsolete files)

Bug 213945 - Implement an initial and simple card tree row for vertical layout. r=darktrojan
(deleted), text/x-phabricator-request
Details
Screenshot 2023-03-01 104058.png
(deleted), image/png
Details
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 stacking. 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: Joe Bob 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. Reproducible: Always Steps to Reproduce: 1. 2. 3.
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.
OS: Linux → All
Hardware: PC → All
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.
Target Milestone: --- → After Thunderbird 1.
QA Contact: asa
Attached image What the message pane looks like in Outlook 2003. (obsolete) (deleted) —
There's a <a href='http://forums.mozillazine.org/viewtopic.php?t=50256&postdays=0&postorder=asc&start=0'>thread</a> about this at the mozillaZine forums. It seems as if some people would like this enhancement.
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 headed columns. 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 effect? Anyone have a clear enough picture of xul in their head to say if this would work? Jim
*** 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. ***
Attached image Rough Mockup of Organized Column View (obsolete) (deleted) —
Here's a quick mockup of how the column view could potentially be organized.
QA Contact: front-end
Attached image Lotus Notes using stacked sender and subject (obsolete) (deleted) —
It might be possible to make an extension in TB2 for this. From http://www.mozilla.com/en-US/thunderbird/2.0.0.0/releasenotes/ "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 database." Don't get me wrong, I would so much like to have this feature in Thunderbird myself =)
Summary: Mail listing needs more organization in 3 vertical pane view → Mail listing needs more organization in 3 vertical pane view (like Outlook, Lotus Notes et al.)
(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.
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: View Go +-----------------+ |Toolbars >|_______________ |Layout >|* Classic View | |Folders >| Wide View | +-----------------| Vertical View| |Sort by >|---------------+ |Threads >|* Stacked View | +-----------------| Column View | |Headers >|---------------+ |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) My $0.02
Attached patch treeView enhancement: draft (obsolete) (deleted) — — Splinter Review
Attached image treeView enhancement: more style work (bigger cells) (obsolete) (deleted) —
Attached image treeView enhancement: cropped (obsolete) (deleted) —
patch: attachment 307012 [details] [diff] [review] screenshots: 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 ?
Hey Paul, 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.
Flags: blocking-thunderbird3?
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.
Hi Paul. 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.
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?
Assignee: mscott → paul.rouget
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. so, (pref.multiline.rows, 2); (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.
Blocks: 307070
Depends on: 441414
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")!
Version: unspecified → Trunk
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.
Flags: wanted-thunderbird3+
Flags: blocking-thunderbird3?
Flags: blocking-thunderbird3-
Priority: -- → P2
Target Milestone: Future → Thunderbird 3.0b2
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 ?
Target Milestone: Thunderbird 3.0b2 → Future
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.
Hi there Sorry for that stupid question but how to get and install that "treeView enhancement: draft" patch? I'm using Thunderbird Version 2.0.0.23 (20090812) and looking forward to an Outlook View.
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.
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
Hi, 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!
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)
Assignee: paul → nobody
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. Kind regards Kristo
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.
Kristo, 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.. <--
URL: http://gsfn.us/t/1cd8l
Whiteboard: [gs]
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.
Keywords: helpwanted
Whiteboard: [gs] → [gs][see comment #75]
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: http://getsatisfaction.com/mozilla_messaging 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.
howdy y'all, apple's mail.app now has a multi-line message list display. it was added in the 10.7 o/s release. take care, lee
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: http://www.fossfactory.org/project/p294
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.
Target Milestone: Thunderbird 11.0 → ---
Component: Mail Window Front End → Folder and Message Lists
QA Contact: front-end → folders-message-lists
Summary: Mail listing needs more organization in 3 vertical pane view (like Outlook, Lotus Notes et al.) → Mail/message listing/thread pane needs more organization in 3 vertical pane view (like Outlook, Lotus Notes et al.)
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. Suny
Blocks: 737347
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. http://en.wikipedia.org/wiki/History_of_Mozilla_Thunderbird#Future_development
"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. > > http://en.wikipedia.org/wiki/ > History_of_Mozilla_Thunderbird#Future_development 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.
Priority: P2 → --
Whiteboard: [gs][see comment #75] → [gs][see comment #75][waiting on bug 441414]
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.
Thanks.
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? Instead of: + Mail One test@example.com 12/12/13 + Mail Two test@example.com 12/12/13 + Mail Three test@example.com 12/12/13 Something like: + Mail One 12/12/13 + test@example.com + Mail Two 12/12/13 + test@example.com + Mail Three 12/12/13 + test@example.com 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: http://4.bp.blogspot.com/-wxGkyc4kiPU/USvvA90nRyI/AAAAAAAAAng/pnUpeU1OKaI/s1600/Inbox.jpg 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: > http://infinite-josiah.blogspot.com/2013/02/thunderbird-ui-concept.html > This looks great, I can't wait to see this beeing realised.
(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.
Assignee: nobody → josiah
Status: NEW → ASSIGNED
You really should check the work that postbox has done on this, particularly in treeview, that you can download from: http://download.getpostbox.com.s3.amazonaws.com/source/3.0.7/postbox-3.0.7-mpl.tar.bz2 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: > > http://download.getpostbox.com.s3.amazonaws.com/source/3.0.7/postbox-3.0.7- > mpl.tar.bz2 > > 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.
Assignee: josiah → nobody
Status: ASSIGNED → NEW
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 > 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.
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. Thanks. - Josiah Bruner
(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. Hey Rahil! 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? https://addons.mozilla.org/en-US/thunderbird/addon/morelayouts/
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) > https://addons.mozilla.org/en-US/thunderbird/addon/morelayouts/ 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.
Hi ! +1 for this new feature Thanks.
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.
Attachment #8701651 - Flags: feedback?(squibblyflabbetydoo)
Attachment #8701651 - Flags: feedback?(mozilla)
Attachment #8701651 - Flags: feedback?(mconley)
Hi Thomas, 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[1], 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. [1] https://github.com/fxos-components/fastlist
Attachment #8701651 - Flags: feedback?(squibblyflabbetydoo) → feedback+
(In reply to Jim Porter (:squib) from comment #131) > Cool, good to see this is going well. I'd recommend trying to use > fastlist[1], 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. > > [1] 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.
Attachment #8701651 - Flags: feedback?(mconley) → feedback?(mkmelin+mozilla)
Attachment #307012 - Attachment is obsolete: true
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.
Attachment #8701651 - Flags: feedback?(mozilla)
Attachment #8701651 - Flags: feedback?(mkmelin+mozilla)
Attachment #8701651 - Flags: feedback+
(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? CompactHeader PopMailListRecipients Reply to All as CC
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? > CompactHeader > PopMailListRecipients > 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).
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.
Hope Mozilla Foundation will put some efforts to it and will make it as blocker for next major release.
When the subject is too long: Instead of having: Jane Doo | A very long ... | 6/6/2015 Joe Ko | Short | 6/6/2015 It would be great to have line wrapping Jane Doo | A very long | 6/6/2015 | subject wrapped |
This is absolutely necessary when using the "vertical layout", especially if you're subscribed to mailing lists, which typically add the name of the mailing list between square brackets to the subject. Meanwhile, an extension to mangle subjects would be useful to reduce the usability problem. E.g. it would be nice to fix all subjects that include "[very lenghty mailing list name] rest of the subject" to look like (note: only display should be affected, not real subject) "[VLMLN] rest of the subject".
p.s. I've tried the test extension attached to this bug: I'd say the direction is very good!! Please develop it further, presently is too limited.
Blocks: 1364640
FYI: https://blog.mozilla.org/thunderbird/2018/02/what-thunderbird-learned-at-fosdem/ It's probably safe to say most Thunderbird users are on Linux now. IMHO this is a feature the Linux desktop sorely needs. Not just an email client, but a modern messaging framework that integrates well with address books, Exchange servers, chat, etc. Thunderbird's reliance on plugins has always been a problem, because plugins don't stay up to date, and can impact performance in a big way. As was noted earlier, Thunderbird will need more than a couple patches to be able to do this.
I marked most of the recent (2018) discussion as either off-topic or me-too. The Thunderbird team is well aware users want this feature (see the "votes" count above), unfortunately we have very few resources. Mozilla graciously is supporting Thunderbird infrastructure, but all development is done by a small community. However, Bugzilla is for tracking technical discussions. Therefore, please refrain from "me-too" or "I'm unhappy with..." comments, as they just clutter the ticket.
Most of the people here probably aren't involved with either the Mozilla Foundation or the Thunderbird team, and as stated before, the team/community is small. There is a possibility to donate towards Thunderbird: https://donate.mozilla.org/de/thunderbird/ But in all seriousness: couldn't someone from the foundation set up a $kickstarter to fund the neccessary code overhaul specifically? I know, this isn't technical but I'm writing this here because I have no idea where to turn otherwise.
(In reply to D-Jo from comment #160) > FYI: > https://blog.mozilla.org/thunderbird/2018/02/what-thunderbird-learned-at- > fosdem/ > > It's probably safe to say most Thunderbird users are on Linux now. IMHO this > is a feature the Linux desktop sorely needs. Not just an email client, but a > modern messaging framework that integrates well with address books, Exchange > servers, chat, etc. Thunderbird's reliance on plugins has always been a > problem, because plugins don't stay up to date, and can impact performance > in a big way. > > As was noted earlier, Thunderbird will need more than a couple patches to be > able to do this. I am on Windows 7. When I look at the source files of newsgroup messages on the news.mozilla.orgserver, I find most of the users there are using Thunderbird with Windows. As I commented before (comment #125), I request that this change be done with the current three-pane, wide view display retained as an option.
(In reply to ubuntu from comment #171) > A Kickstarter for funding the code overhaul of Thunderbird would be very > great. I will definitely support it financially!! > > I know this is a "me too" post but perhaps the developers see the urge for > an overhaul of Thunderbird if enough users post this?! The way to "me too" this post is to click the Vote button under Details (in the original bug report), not to add a comment!

Alessandro Castellani (:aleca) can you please implement this? Thank you

Flags: needinfo?(alessandro)

Ditto regs' comment. We have an office-full of users who, much to my chagrin and irritation, are planning on abandoning Thunderbird and going back to Outlook for no other reason than Outlook's message-list pane permits multi-lines per email (e.g. subject on 2nd line), letting them shrink the size of that pane. This all despite the fact that accessing CalDAV calendars from Outlook is a real NIGHTMARE, and, ironically, Outlook will only Active/Directory authenticate if using Exchange ... and I could go on and on. I think this one modification would preserve a lot of Thunderbird users.

Attached image Postbox.png (obsolete) (deleted) —

Postbox is based on Thunderbird which has implemented this feature. Please view the attached Postbox.png image from Postbox's website.
https://www.postbox-inc.com/

There are many clients that are based on Thunderbird. This might provide additional ideas on how to implement this feature.
http://kb.mozillazine.org/Email_clients_based_on_Thunderbird

What do you think?

Thank you

Assignee: nobody → alessandro
Flags: needinfo?(alessandro)

Hi, thanks for pulling me into this.
I'll see if I have some capacity next week and submit a patch.

Óvári : postbox looks very interesting. I'll download and check it out. I do need Windows and Mac, but too bad they don't do Linux.

Alessandro - I'll eagerly look forward to your "patch".

I started working on this today and indeed it's fairly complicated as the current threechildren structure doesn't allow this kind of flexibility.
I'll write some test patch and gather some feedback from other devs to see how we can move this forward.

(In reply to Alessandro Castellani (:aleca) from comment #181)
Thank you

Be sure to take a look at comment 127 to see some work that was already done on how to do this with purely HTML

https://bugzilla.mozilla.org/show_bug.cgi?id=213945#c127

There are a lot of useful comments immediately following, well worth your time to review if you are going to take this on, which I really, really hope you do!

Thanks!!

Priority: -- → P3

Hi there,

I made a post on Mozilla support about this issue. They recommend me to add my comment to your discussion. So here I am. Maybe it could help or it could encourage progress on this.

First, I’m very happy that Thunderbird exists. Thanks for your work. It is great to have an efficient open source email software!

However, I'm used to managing my emails in vertical view and when I switched to TB, I found that the configuration of the message list pane was not adapted for this layout. I think that information (date/subject/sender/etc) listed horizontally is not adapted for vertical display because:

  1. It needs too much space in the message list pane to make important information readable and complete. The result is a message pane squeezed. (Screenshot 1)
  2. Inversely, making enough room for the message pane squeezes the message list pane and its information. (Screenshot 2)

Superposing information of the message list pane would solve this problem. (Screenshot 3)
It is how vertical view is displayed in Apple Mail (screenshot 3), Outlook and Kolab Now for example. It makes reading accurate and more pleasant.

So I’m wondering if Thunderbird team could consider working on it for a future release.
(Besides, I don't know if there’s a better space for my comment/suggestion. Please, feel free to redirect me if there’s one.)

Thanks!

Attached image Screenshot 1 (obsolete) (deleted) —

Hi, thanks for using Thunderbird and for your extremely polite request :D
I'm planning to work on this and landing it before the next ESR release, which is supposed to be 78.
I will probably be able to work on this in a couple of weeks.

Attached image Screenshot 2 (obsolete) (deleted) —
Attached image Screenshot 3 (obsolete) (deleted) —
Status: NEW → ASSIGNED
Keywords: helpwanted → ux-efficiency
Priority: P3 → P2

This is literally the only thing preventing me from using Thunderbird again.
I remember there being a bigger discussion bug about this and how it was really hard to do, and the discussion also going into the XUL treeview component etc. I don't know if it would be possible to just have a workaround, like for example:

  • Use a different widget without deep tree features for thin list panes
  • Have "fake" virtual columns that just have multiline content (and increase the row height of the whole control)

I'm glad to hear someone is taking this on! :aleca, is there anything we can help with? I can't do C/C++ but I can do UX design and maybe some HTML/JS...

This is great news!. The only thing I have been missing in TB.

Great! I'm a big fan of Thunderbird but the lack of column wrapping has always been the biggest niggle for me.
If you could make the columns individually re-sizeable as well that would be even better. Thanks :)

I am so curious how far Allesandro Castellani has come with the solution of this (now) 17 years old bug. Can we already test something? I would be excited to do so!
Will Allesandro gain eternal fame by solving this 17 year old bug?

I haven't progressed a lot unfortunately as I've been super busy with a million other bugs, as usual T_T
While exploring a possible solution, I noticed that using a simple HTML view doesn't scale well and it gets very heavy and slow when handling 1k+ messages.
The tree XUL element is way more performant and stable, so I'm exploring the possibility to create a custom view with a single column in order to leverage the same element without reinventing the wheel, and therefore inherit all the flexibility and performance of the tree.

If I manage to fix this bug, at least I deserve a paper star on my scrapbook :P

I'm not a developer, so take what I say in that context, but the impression I've gotten is that all XUL elements will ultimately be going away.
Perhaps though tree will get replaced with a 1-to-1 swap-in replacement?

Probably in the future will be dropped, as you can see in bug 1446341, but for now it stays so we still have a bit of time to properly explore alternatives and replacements.
In that bug I shared, you can see FF implemented a react-based tree in the devtools, which we might extend, it's just a thought tho, nothing has been decided.
I guess we might try to use this bug as an experiment and see how a new implementation handles things, without replacing everything at once.

It may help you looking at the experimental implementation I attached to this bug five years ago. It is a pure HTML implementation, and works fine with an unlimited number of lines. The footprint of this implementation is constant.

The trick is just to use a view port with fixed height Elements. This allows sliding the elements inside the view ports and combine this with a simple caching strategy. The addon just at maximum cached 50% of the visible elements in either direction. Which means if 25 Elements where displayed the HTML ended up with at most 50 Elements. The fixed height means you can easily calculate the visible elements.

It as was poor mans implementation without any optimization so there is plenty of room left (e.g. by using a canvas or webGL as context).

Thank you Alessandro for looking at this bug/feature request. Could I also ask would it be possible in this view for the first line of the message be displayed in the middle panel under the subject line. This is the default view in Outlook, Apple Mail and Microsoft Outlook and is a real usability improvement as long as saving time with message triage. This is explained further in Bug :

https://bugzilla.mozilla.org/show_bug.cgi?id=307070

A functional and efficent interface really helps end users and seperated Thunderbird from it's competitors. It is good to see the project supporting users with these usability improvements.

I should say Geary for Gnome desktop on Linux instead of Outlook twice.

(In reply to Thomas Schmid from comment #201)

It may help you looking at the experimental implementation I attached to this bug five years ago. It is a pure HTML implementation, and works fine with an unlimited number of lines. The footprint of this implementation is constant.

The trick is just to use a view port with fixed height Elements. This allows sliding the elements inside the view ports and combine this with a simple caching strategy. The addon just at maximum cached 50% of the visible elements in either direction. Which means if 25 Elements where displayed the HTML ended up with at most 50 Elements. The fixed height means you can easily calculate the visible elements.

It as was poor mans implementation without any optimization so there is plenty of room left (e.g. by using a canvas or webGL as context).

Yep, this is how it's done. Web components for virtual scrollers are emerging

https://github.com/PolymerLabs/uni-virtualizer/tree/master/packages/lit-virtualizer
https://github.com/WICG/virtual-scroller

Summary: Mail/message listing/thread pane needs more organization in 3 vertical pane view (like Outlook, Lotus Notes et al.) → Mail/message listing/thread pane needs more organization in 3 vertical pane view (column wrapping, etc)

In "Vertical view" with TB 80, the message body overflows (text width larger than pane width), without horizontal scroll. This is due to the fact that the text width is at least the menu bar width (bar with action buttons -- msgHeaderView).

To get readable emails again, a workaround is to remove the buttons in userChrome.css.

.msgHeaderView-button {
  display: none !important;
}

Another workaround would be to allow line breaks between buttons but I don't know how to do this.

TB78 looks already more modern than previous versions, maybe we have a chance to see this feature coming soon? I guess P2 is a pretty high priority, right?

According to [1] the next Firefox ESR is scheduled for July 2021, and that will also mark the release of Thunderbird 91 as the next stable release. Missing Thunderbird 91 will mean punting the fix to this bug in Thunderbird stable to 2023 at best :(

[1] https://wiki.mozilla.org/Release_Management/Calendar

Priority: P2 → P3

So now if I understand this classification that this feature request is even less likely to be implemented?

This really is a case of not seeing the wood for the trees here when this is a clearly popular suggestion. It's truly sad seeing Thunderbird becoming less and less relevant and outdated over time.

We'll implement it at some point, but it's not something we can do right at this time for the next release. (Just not technically feasible.)

Status: ASSIGNED → NEW

(In reply to Jamie M from comment #208)

So now if I understand this classification that this feature request is even less likely to be implemented?

This really is a case of not seeing the wood for the trees here when this is a clearly popular suggestion. It's truly sad seeing Thunderbird becoming less and less relevant and outdated over time.

I was just wondering, if a P2 is still hanging around after almost 20 years what is P3 like?! ;-)

Yes it's dissapointing and likewise I see this as a big flaw with T'Bird. On the other hand, it's still the best email client for my purposes and presumably priority is being given to other issues that would cause us problems if not dealt with, while manpower is limited. So I'll take the opportunity to say thanks to the devs for all their hard work on all that's good in T'Bird.

I agree... it is truly sad.
Thunderbird is by far the most effective email client, if we stick at the mail management.

However, the interface is really outdated and does not work well on modern devices.

And, it is not a matter of taste!!! I saw some comments by some developers, pointing to the fact that it is perfectly usable, looks "more modern than before" and so on, all with a common mood: "if you don't like it, is it up to you to change your way of doing things".

I really do not understand why design/UX things are considered, so insistently, as they were a lowest priority issue. They are not! There are several pieces of wonderful software just forgotten, simply because they are practically unusable. And no, it is not the whole world being wrong with respect to a limited set of developers...perhaps, it is the time developers try to understand changed needs.

This thread is an example. Practically any modern email client has the email list column that display 2 or three rows (Sender, subject, first line), there is a reason if this practice expanded to all email clients (thunderbird excluded). Or are you seriously thinking you (developers) of thunderbird are all right and the other (the rest of the world) are all wrong?

Another example is the scrolling. Nearly all laptops now have a touchpad and all of us are used to scroll with our two fingers. Scrolling in the message list of thunderbird is insane. The reason is that it is not able to scroll pixel by pixel, but the scrolling is implemented line by line, so the scrolling action with the touchpad makes the list scroll simply too fast. The scroll function with mouse work well, but its behavior is different at its roots, so they are not comparable. This highlights that no one took care of adding such a basic (in 2021) function.

To conclude, "just not technically feasible" looks a bit strange. And to prove this, I point to just two open-source solutions that may count on a much more restricted support that Mozilla based solutions can count on: Mailspring and Geary.
That Mozilla, and thunderbird in turn, developers tell me that having something the competitors have (from years now) "not technically feasible" seem really something to take indefinite time.

(In reply to Magnus Melin [:mkmelin] from comment #209)

We'll implement it at some point, but it's not something we can do right at this time for the next release. (Just not technically feasible.)

Thank you for clarifying, I understand the constraints you are all under. But please do not just forget about this request and put it on the back burner indefinitely. People have been asking for 18 years.

The lack of this feature makes Thunderbird genuinely less usable compared to other mail clients. As this won't make the next release are you able to put some priority for this feature to implemented in the release after?

Kind of like marking the 20th anniversary of this request by solving it?

It can't be fixed before we have a good enough (performant enough!) widget to replace it with. In the new address book we're working on, we will prototype such a widget, and once successful it could be used for this as well.

Like I said, we do want to fix it. It's just not technically feasible to fix it right away. Probably before it's 20th anniversary though.

Restrict Comments: true
Flags: wanted-thunderbird3+
Flags: blocking-thunderbird3-
Whiteboard: [gs][see comment #75][waiting on bug 441414] → [see comment #213][waiting on bug 441414]
Attached image multiline-view.png (obsolete) (deleted) —

We have implemented this now:
https://github.com/Betterbird/thunderbird-patches/blob/main/91/features/04-feature-multiline-tree.patch
https://github.com/Betterbird/thunderbird-patches/blob/main/91/features/04-feature-multiline-tree-m-c.patch

From comment #107:

You really should check the work that postbox has done on this, particularly in treeview, ...

Like in our patch based on Paul Rouget's work, Postbox have modified layout/xul/tree/nsTreeBodyFrame.cpp to paint whatever they need into the rows of the tree.

Severity: normal → S3

Finally started working on this with a more sane approach and not hacking the XUL tree.
It should land in the next beta 112 as a very first and simple implementation.
Also, it doesn't depend on the XUL core anymore since we implemented a new widget.

Blocks: sn-msglist
Status: NEW → ASSIGNED
No longer depends on: 441414

Adding [Supernova] to Whiteboard 20230223_1125

Whiteboard: [see comment #213][waiting on bug 441414] → [Supernova]

Oops. Restore whiteboard. Sorry!

Whiteboard: [Supernova] → [see comment #213][waiting on bug 441414][Supernova]
Attachment #9319338 - Attachment description: WIP: Bug 213945 - Implement an initial and simple card tree row for vertical layout. → Bug 213945 - Implement an initial and simple card tree row for vertical layout. r=darktrojan
Attached image Screenshot 2023-03-01 104058.png (deleted) —

This initial patch is landing on daily soon, so here's a quick overview of the progress and plans for further improvements.

This is just an initial implementation, is not completed and many things are missing

  • The new card item will kick in automatically if users switch to a Vertical Layout.
    • Some users might still prefer to keep the table item even with a Vertical Layout, so in the future we will explore the option to control that independently.
  • For now, on the sender, subject, date, and favourite fields are visible.
    • All other fields will be added in a follow up.
    • Toggable options to show/hide preferred fields will be added.
  • New messages get a primary blue color variation, as well as a drop shadow and white background.
    • A more prominent visual indicator will be added later, probably a top left circle like we use for the folder pane.
  • Threaded messages are only indented by 1 level.
    • We can't show the actual threaded indentation because that defeats the purpose of the vertical layout, making further indented messages harder to read without a wide screen.
    • This UI will improve later once we implement a proper conversation view.
  • These cards are not yet density aware, we will implement this later.

You will notice rough edges and missing features, especially the quick filter bar is kinda useless in Vertical layout.
I will create a follow up meta bug to track the effort and hopefully we will have something good and usable before 115.

Thank you all for the suggestions and patience.

Attachment #142624 - Attachment is obsolete: true
Attachment #258111 - Attachment is obsolete: true
Attachment #266237 - Attachment is obsolete: true
Attachment #307013 - Attachment is obsolete: true
Attachment #307014 - Attachment is obsolete: true
Attachment #307016 - Attachment is obsolete: true
Attachment #307017 - Attachment is obsolete: true
Attachment #8701651 - Attachment is obsolete: true
Attachment #9080755 - Attachment is obsolete: true
Attachment #9126602 - Attachment is obsolete: true
Attachment #9126603 - Attachment is obsolete: true
Attachment #9126605 - Attachment is obsolete: true
Attachment #9240172 - Attachment is obsolete: true
Attachment #9319338 - Attachment is obsolete: true
Keywords: checkin-needed-tb
Target Milestone: --- → 112 Branch

Temporarily removing check-in due to test failures.

Keywords: checkin-needed-tb
Keywords: checkin-needed-tb

Pushed by alessandro@thunderbird.net:
https://hg.mozilla.org/comm-central/rev/ee075ab2651a
Implement an initial and simple card tree row for vertical layout. r=darktrojan

Status: ASSIGNED → RESOLVED
Closed: 2 years ago
Keywords: checkin-needed-tb
Resolution: --- → FIXED
Attachment #9319338 - Attachment is obsolete: false

Great things are finally happening, thanks much to Geoff and Alex!
Per Alex comment 222, we'll continue working on this for refinement (tracked in meta bug 1819710).

Whiteboard: [see comment #213][waiting on bug 441414][Supernova] → [Supernova][see comment 222]
Regressions: 1819840
Whiteboard: [Supernova][see comment 222] → [Supernova3p][see comment 222]
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: