359270 - Mailbox Display: Needs a unified 'Who' column like current Eudora

Status: RESOLVED DUPLICATE of bug 36489

(Thunderbird :: Mail Window Front End, enhancement)

Description

[Matt Dudziak]

Penelope needs a unified 'Who' column like the current version of Eudora, which displays the sender for incoming messages and the recipient for outgoing messages. This should work for both local and IMAP mailboxes.

Comment 1

[Tony Lowe]

If you mean threading, the absolutely!!

Comment 2

[David Morrison]

Absolutely critical. Eudora makes very efficient use of screen space by doing this. I don't want two columns, one of which always contains my own name.

Comment 3

[Tim Streater]

This is a very important feature for me as I keep sent and received mail for a given topic in the same mailbox. David Morrson's comments mirror my feelings exactly.

Comment 4

[Love Eudora]

This is one of the main reasons I gave up on using first Netscape mail, and later chose not to use Thunderbird.  (I DO use Firefox, though, after having used Mozilla and Netscape web browsers!)  I've used Eudora for close to a decade, and nothing else matches up for me.

Comment 5

[Adam Schneider]

Agreed.  Having my own messages in italics is a brilliant way to convey information without needing any more space on the screen.

Comment 6

[David]

The is an existing Thunderbird extension which, as of its most recent version, does this for Thunderbird 2:  

http://www.ggbs.de/extensions/ShowInOut.html

It adds a "correspondent" column to the messages display, which as of the very latest version of the extension, is sortable (though not in previous versions, and not with Thunderbird 1) -- and is exactly like Eudora's unified "who" column.

You have to add some stuff to userChrome.css to get Eudora-style italics for outgoing mail, but once you do this, the extension makes the messages window very Eudora-like.

Comment 7

[humanengr]

I use Eudora to archive my postings to web forums and others' responses to my postings, amongst other things. I'd like to be able to change the italicization so that the clips of others' responses are not italicized -- as they would appear if they had actually been emailed to me. 

If the columns are unified (which I favor), the From field would, for all of the above, indicate that I was the real author and I could put the purported sender in the Who field (as I do now).

Comment 8

[durnette]

I make extensive use of “blind copy” for multiple mailings to a group. Eudora provides an easy format for this process, by attaching the group name from the Address Book. Other e-mail systems seem to require two or three steps to accomplish the same thing.

Comment 9

[singpolyma]

Going all the way to threading eventually would be nice too :)

Comment 10

[David Peters]

I agree. Unified 'Who' column (and proper threading) should be one of the major qualities of TB v.3.

Keeping outgoing and incoming mail in different folders, and what's more, unthreaded, is an unbelievable anachronism - not only since Gmail. Thunderbird v3.0 really should be the application which changes all that for good.

Here is a screenshot (http://tinyurl.com/2uoghh) of what probably is about as good as it gets at the moment in TB v2 with the following features:

• Unified 'Who' column
• Threading (despite the "thread bubble" extension still not perfect due to bug 262316)
• Proper message symbols and thread lines (note that the 'replied' symbol has been reversed to better match the threading indention direction which is of course left to right and not opposite as is the current 'replied' symbol -- however most of the time after replying the 'replied' symbol doesn't seem to work anyway)
• Highly visible In/Out symbols ("Show InOut" extension by Guenter Gersdorf, with custom In/Out icons)
• Highly visible distinction between different threads by coloring container treechild separately (medium dark blue here)
• Incoming mail with different text color label (green here, as compared to black for sent mail)

Thunderbird really should adopt as many of these features *as a standard*, not in the form of high end tweaking like here. This way, literally millions of users could learn just how efficient, and *how* much fun e-mail *can* be after all …

Thanks already for consideration,
keep up the great work, 
and pls take action,

Cheers,
David.P

Comment 11

[constant_irritation]

Throw my vote in for this: a 'Who' column is a definite necessity.

Comment 12

[David Peters]

Here comes one more feature that I'm sure will turn up sooner or later in "some" e-mail client -- since it is the logical continuation of the threading paradigm:

If you look at a thunderbird message pane ake *thread* pane (sic!) set up properly for threading (e.g. like so: http://tinyurl.com/2uoghh) you can see that the thread pane layout almost resembles a FOLDER TREE where each thread has his own "area" or "subfolder" structure.

Therefore,
• and since quite often messages are being threaded together that actually do not belong to the same conversation (and vice versa: messages that DO belong to the same conversation but for some reason don't get threaded into the proper thread),
• it would be a killer feature if you
• [could not only EDIT the subject line as suggested by others earlier, no:]
--> if you could DRAG-AND-DROP messages that have not been assigned to the correct thread in between threads up or down such that
• you'd be able to pick (with the mouse in the respective row of the thread pane) a message that Thunderbird had allocated to the wrong thread, and simply drop the message over the correct thread where it belongs!

I'm sure that this would be an even more useful enhancement for the threading mode of Thunderbird (or Penelope).

Rgds.
David.P

[If someone knows where to continue the discussion about *threading* more effectively than here in the "Who-column" thread, pls. let me know.]

Comment 13

[David Peters]

Readers of this thread might also want to have a look here:

http://tinyurl.com/27gabs (link to MozillaWiki Article)

Be careful: this is mind-boggling stuff.

David.P

Comment 14

[David Peters]

Sorry, here's the correct link to the MozillaWiki article

"Major Usability Redesign of Folders & Threads (in 4 Steps)"

http://tinyurl.com/yrpsvq

David.P

Comment 15

[Tim Thome]

Tbird's threading is a good step moving forward, and I support David Peter's recommendation.

-- Tim

Comment 16

[Matt Dudziak]

Actually, this feature is already mostly-implemented, though off by default at this point. 

You can enable it by setting 'mail.useWhoColumn to 'true' in the editor settings (Preferences->Advanced->Config Editor...).

Matt

Comment 17

[Jeff Beckley]

Changing to be under Thunderbird as the upcoming fix is implemented there.

Comment 18

[Jeff Beckley]

Attachment: Implementation of unified Who column

Here's the implementation of the unified Who column.  It also implements the italicized summary info of outgoing messages in mailboxes other than Sent and Drafts.

This is tied to the new pref "mail.useWhoColumn".  By default that pref is off in Thunderbird, but on in Penelope.

Dale Wiggins <[e-mail]> is the original author of this code (I'm just submitting it for him).

Comment 19

[David :Bienvenu]

this part doesn't seem right for Mozilla CVS: :-)

Index: mail/installer/windows/app.tag
===================================================================
RCS file: /cvsroot/mozilla/mail/installer/windows/app.tag,v
retrieving revision 1.2
diff -u -8 -p -r1.2 app.tag
--- mail/installer/windows/app.tag	26 May 2004 22:05:33 -0000	1.2
+++ mail/installer/windows/app.tag	16 Oct 2007 00:36:33 -0000
@@ -1,4 +1,4 @@
 ;!@Install@!UTF-8!
-Title="Mozilla Thunderbird"
+Title="Qualcomm Eudora"
 RunProgram="setup.exe"
 ;!@InstallEnd@!
\ No newline at end of file

nor this:

@@ -77,16 +77,17 @@ NO_PKG_FILES = \
 	res/rdf \
 	res/viewer.properties \
 	res/viewsource.css \
 	chrome/chromelist.txt \
 	chrome/embed-sample.jar \
 	PalmSyncInstall.exe \
 	components/libgkplugin.so \
 	components/gkplugin.dll \
+	res/macEudoraPrefTable.txt \


actually, there are a lot more of these that seem wrong...

the importer changes aren't really part of this bug, right?

I'm not crazy about making all msg hdrs 4 bytes bigger for this feature

+  NS_ENSURE_ARG_POINTER(isSent);
+  *isSent = m_IsSent;
+  return NS_OK;
+

It's also not being persisted, so why put it in the msg hdr at all? Perhaps just figure it out in the view code...

Comment 20

[Jeff Beckley]

I'll let Dale comment on the msg hdr changes.  I think for performance reasons there has to be some form of caching whether the message was a sent one or not.  Is there some existing place in the header where we could store a bit for this?

Sorry about the extra changes in that patch.  That was a copy/paste error by me.  I'll fix that when we resolve the other problem.

Comment 21

[WADA:World Anti-bad-Duping Agency]

FYI.
If Bug 280606 will be implemented, implementation of "unified who column" will become simpler(sent mail will be easily identified).
> Bug 280606 need some way to indicate sent messages (status = Sent)
Current implementation of "unified who column" of Eudora 8.0.0b1 has following problem.
> Bug 400090 Two "Who" column exist(one for each former sender/recipient)

Comment 22

[Dale Wiggins]

David, regarding: "It's also not being persisted, so why put it in the msg hdr at all? Perhaps just figure it out in the view code..." I can live with not keeping an extra field in the header but I'll need to do something about how/where I do the calculation for "was the message sent by me?". Currently I do it in nsMsgDBView::GetCellText() to determine which address to use in the Who column and in nsMsgDBView::GetCellProperties() to determine the style to use for the row. Doing this calculation over again for each cell would end up taking up 41% of the time needed to draw a row.

Off the top of my head I can think of two alternatives:

1) In nsTreeBodyFrame::PaintRow() we add a call into an nsMsgDBView function to determine if we are dealing with a "sent by me" message and pass that info down the tree until we reach nsMsgDBView::GetCellText() and nsMsgDBView::GetCellProperties(). This way we only do the calculation once for each row.

2) In nsMsgDBView::GetCellText() and nsMsgDBView::GetCellProperties() we use statics to keep track of whether or not we have done the calculation for that row.

Solution #2 isn't very elegant but it has less of an impact on the code since it all happens inside the two functions. Solution #1 is a neater solution but requires adding a new parameter to a number of functions.

Thoughts?

Comment 23

[Dale Wiggins]

Attachment: Implementation of unified Who column feature

A new implementation that addresses the concerns expressed about the previous implementation, most notably the issue with adding extra data to the message header.

Comment 24

[David :Bienvenu]

Thx, Dale. This is a lot better, I think. One issue - I don't think it will work for cross folder saved searches, in particular, this code:

+PRBool nsMsgDBView::SenderIsMe(PRInt32 aRow)
+{
+  if (!m_folder)
+    return PR_FALSE;
+

Maybe you don't want it to work for cross-folder saved searches, but if you do, I think you need to call GetFolderForViewIndex(nsMsgViewIndex index, nsIMsgFolder **aFolder) for the row to determine the folder the header is in.

Comment 25

[Dale Wiggins]

Attachment: New patch that fixes issues with local mailboxes (which have no associated account), the search dialog and cross folder saved searches.

Here is a new patch that should address all issues with the previous patch.

Comment 26

[David :Bienvenu]

Thx Dale, I will give this patch a shot as soon as I have some spare time.

Comment 27

[Gary Kwong [:gkw] [:nth10sd] (NOT official MoCo now)]

Nominating wanted-thunderbird3 to keep it on the radar.

Comment 28

[Wayne Mery (:wsmwk)]

WRT wanted-thunderbird3, note the 57 votes requesting this capability

Comment 29

[David Ascher (:davida)]

adding bryan, as there's lots of good UI meat here =)

Comment 31

[Mitra Ardron]

Is this ever likely to get done - lots of people want it, and it was in the "Eudora" release so I don't think its rocket science?

Comment 32

[Magnus Melin [:mkmelin]]

FWIW, the patch still applies. I just had a quick run with it.

First, should I be seeing the "who column" elsewhere except for in the search results? I don't.

I seem to get a duplicate "Subscribe..." entry in the folder context menu.

Why is this column any special? With the pref I mean, can't it just be one of the column types you choose like all the other types? 

Also, the advanced.xul change seems unnecessary? And the folderContextDiscoverSubFolders.label doesn't seem to belong in this patch at all?

Comment 33

[Dale Wiggins]

(In reply to comment #32)
> First, should I be seeing the "who column" elsewhere except for in the search
> results? I don't.

Yes, you should definitely be seeing it outside the search results. I do in my builds.

> I seem to get a duplicate "Subscribe..." entry in the folder context menu.

I am seeing that now as well. It wasn't there in earlier builds. I will look into that.

> Why is this column any special? With the pref I mean, can't it just be one of
> the column types you choose like all the other types? 

It made design sense (to me at least) to reuse and relabel the existing column rather than creating an entirely new column.

> Also, the advanced.xul change seems unnecessary? 

The only change I see in advanced.xul is:
+      <preference id="mail.useWhoColumn" name="mail.useWhoColumn" type="bool"/>
where I specify the preference.

> And the
> folderContextDiscoverSubFolders.label doesn't seem to belong in this patch at
> all?

Yes, I made separate changes for a different feature and didn't notice that they crept into this patch. I will fix that.

Comment 34

[Magnus Melin [:mkmelin]]

(In reply to comment #33)
> It made design sense (to me at least) to reuse and relabel the existing column
> rather than creating an entirely new column.

I'm not sure I agree - on one hand user's aren't likely to want both types at the same time, but the way to enable it (even it there were a ui pref) isn't intuitive as you can't enable it the same way the other columns are enabled.

> > Also, the advanced.xul change seems unnecessary? 
> 
> The only change I see in advanced.xul is:
> +      <preference id="mail.useWhoColumn" name="mail.useWhoColumn"
> type="bool"/>
> where I specify the preference.

Yes, that's what i meant. Just declaring it doesn't do anything, right?

Comment 35

[Mitra Ardron]

I think the intuitive way to enable it is the same way other columns are handled - even if it makes no sense to show both. 

This is how the showInOut extension works - though that doesn't work on the current nightly build on OSX (the author says it works in whatever setup he has got, which I think is b1 on Windoze)

Comment 36

[Mitra Ardron]

Is there an ETA of this appearing in the nightly builds so that those of us without compilation ability can test it?

Comment 37

[Jeff Beckley]

It hasn't finished going through the review process yet.  The patch has to be accepted before it can be put in to the code base and get in to a nightly build.

Comment 38

[Mitra Ardron]

Any idea when the review will be complete, and we might see it in the nightly builds?

Comment 39

[Mark Banner (:standard8)]

Comment on attachment 302633 [details] [diff] [review]
New patch that fixes issues with local mailboxes (which have no associated account), the search dialog and cross folder saved searches.

Its not clear from Magnus & Dale's discussion if the patch requires update or not. However Scott isn't doing reviews at the moment, so switching sr and also adding clarkbw to ui-review because this affects Thunderbird UI.

Comment 40

[[e-mail]]

(In reply to comment #32)
> Why is this column any special? With the pref I mean, can't it just be one of
> the column types you choose like all the other types? 
This idea sounds reasonable to me too.

Comment 41

[Bryan Clark (DevTools PM) [:clarkbw]]

Right now I'm mostly unsure about the pref vs. new column type.  I think magnus makes a good point that users aren't likely to want both column types at the same time; however I think it would be easier to fit this into the current Thunderbird model as a new column type instead of trying to create a pref for it.

Otherwise in general I think the idea is good.

Comment 42

[Mitra Ardron]

Agreed - column type makes more sense than pref - not only because of ease of integration intothe model, but also ease of use. 

I think lots of people will want this functionality (anyone who files Sent and Incoming email together) and most of those wouldn't have a clue about how to change a preference, which is - and should be - the province of advanced users.

Comment 43

[Mark Banner (:standard8)]

Comment on attachment 302633 [details] [diff] [review]
New patch that fixes issues with local mailboxes (which have no associated account), the search dialog and cross folder saved searches.

Cancelling my redirected review requests as the recipients have responded and it seems to be up to Dale to update this patch now if he's still working on it.

Comment 44

[Mitra Ardron]

Has this bug gone dead, any chance of it re-appearing, or someone else picking it up if Dale has dropped it?

Comment 45

[David]

(In reply to comment #44)

I hope not!

I have been using Show In/Out but the last beta seems to have broken it.

Comment 46

[Mitra Ardron]

Show In/Out has been broken on Mac's for a fair while, possibly since 3.0

Comment 47

[WADA:World Anti-bad-Duping Agency]

(In reply to comment #46)
> Show In/Out has been broken on Mac's for a fair while, possibly since 3.0

Mitra Ardron, what version are you using? (both Tb and the add-on) 
> "Show In/Out" versions for Tb 3.0x listed at owner's site:
> http://www.ggbs.de/extensions/ShowInOut.html
> Date        Version Tb version (3.0x related only)
> 16.05.2008  0.5.1   3.0a1
> 17.08.2008  0.5.2   3.0a2
> 21.10.2008  0.5.5   3.0a3
> 13.12.2008  0.5.6   3.0b1
> 08.03.2009  0.5.11  3.0b2  (* Fixed Problem with TB3b2) <= Newest one 

Anyway, report to add-on owner first if issue with newer Tb than 3.0b2, please.

Comment 48

[Mitra Ardron]

I use the nightly builds i.e. 3.0b3 and tested with the current (0.5.11) version of ShowInOut, you have to edit the RDF to get around the 3.0b2 maximum version limit. 

I could be wrong but I don't think I've seen it work on any 3.0 on Macs. 

It has been reported to the add-on owner, who doesn't have a Mac to test on. 

It makes much more sense for a key thing like this to be integrated into TB anyway, for anyone who mixes incoming and outgoing in the same folder its a must, and provided by other mail clients.

- Mitra

Comment 49

[klonos]

I agree that this should be built in for the exact same reason.

Comment 50

[Dale Wiggins]

I will be getting back to this shortly and will submit a new patch, hopefully next week.

Comment 51

[Mitra Ardron]

Any luck ?

Comment 52

[David :Bienvenu]

Comment on attachment 302633 [details] [diff] [review]
New patch that fixes issues with local mailboxes (which have no associated account), the search dialog and cross folder saved searches.

I kinda don't care to use two of our limited flag bits for this... this could be a separate hdr property just as easily, right?

Clearing request since Dale has said a new patch is coming. I think this is a highly requested feature, so we should try to drive it in for b4 (iirc, clarkbw agrees)

Comment 53

[Bryan Clark (DevTools PM) [:clarkbw]]

(In reply to comment #52)
> I think this is a
> highly requested feature, so we should try to drive it in for b4 (iirc, clarkbw
> agrees)

let me know whatever I can do to help.

Comment 55

[Mitra Ardron]

I notice the AddOn ShowInOut (see Comment #6) has now been updated and works on the nightly's, hopefully someone will grab the code and incorporate it in TB so we don't have to rely on the AddOn being kept up to date (it hasn't worked on versions since around November).

https://addons.mozilla.org/en-US/thunderbird/addon/3492

Comment 56

[Dale Wiggins]

Attachment: Complete rework of Who column code

I essentially rewrote the Who column code. Who is now a separate column that defaults to hidden. There is also a mail.italicize_sent_by_me pref (defaulting to false) that determines if messages determined to be sent by the account owner should have their row italicized.

Comment 57

[David Ascher (:davida)]

Comment on attachment 403814 [details] [diff] [review]
Complete rework of Who column code

FYI: This patch has new strings, and we're past string freeze.  As such, it won't make it into TB3 (or the code base until after we fork), except if we think it's important enough to warrant a late-string change.

Comment 58

[Dale Wiggins]

Attachment: Removed some extraneous text from the previous patch.

Left some extra text in that previous patch.

Comment 59

[Mitra Ardron]

If you look at "ShowInOut" the equivalent extension it has a seperate column for the direction, which I find in practice I look at all the time - e.g. to see the last email I sent to xxx

Re comment #56, I'd recommend that that preference defaults to TRUE, since 
a) most users haven't a clue about preferences
b) its really useful to know whether its sent or received.

Comment 60

[David :Bienvenu]

If possible, I'd like to avoid storing a calculated column like who in the .msf file - it bloats the .msf file, which makes it slower to load, and consume more memory when loaded. I realize that calculating it on paint is probably too slow, but I suspect we could compute it lazily and cache it in the msg hdr without storing it in the .msf file.

Comment 61

[David :Bienvenu]

Attachment: don't persist computed column

I tweaked Dale's patch slightly to compute the who column lazily, and just persist whether sender is me, using essentially a tri-state property, "sentByMe", which will be empty if not computed, "1" if the sender is me, and "0" otherwise. I also fixed grouping by who.

This patch needs a little more cleanup, but I wanted to see what Bryan thought. E.g., do we want to make the "Who" column the default and stop flipping sender/recipient around when switching between sent and non-sent folders?

Comment 62

[David :Bienvenu]

Comment on attachment 414077 [details] [diff] [review]
don't persist computed column

We could still add the "Who" column without making it a default, so I don't think we need to wait on that decision before landing.

Comment 63

[Bryan Clark (DevTools PM) [:clarkbw]]

Comment on attachment 414077 [details] [diff] [review]
don't persist computed column

(In reply to comment #61)
> This patch needs a little more cleanup, but I wanted to see what Bryan thought.
> E.g., do we want to make the "Who" column the default and stop flipping
> sender/recipient around when switching between sent and non-sent folders?

Making this the default  seems like a good change to me.

An aside.  I've been running with this for a day or so now and it always seems to show me for my sent folder instead of the recipient.

Comment 64

[Dale Wiggins]

(In reply to comment #61)
> I tweaked Dale's patch slightly to compute the who column lazily, and just
> persist whether sender is me, using essentially a tri-state property,
> "sentByMe", which will be empty if not computed, "1" if the sender is me, and
> "0" otherwise. I also fixed grouping by who.

I am getting back to this now. I will try to get a new patch out today that incorporates this change.

Comment 65

[Dale Wiggins]

(In reply to comment #63)
> Making this the default  seems like a good change to me.

I can do that in my next patch.

> An aside.  I've been running with this for a day or so now and it always seems
> to show me for my sent folder instead of the recipient.

There was broken logic in my earlier code that affected the out boxes. Hopefully this problem will go away with the new patch.

Comment 66

[Bryan Clark (DevTools PM) [:clarkbw]]

Comment on attachment 414077 [details] [diff] [review]
don't persist computed column

ok, giving this the plus as the general concept seems good just some bugs.  I'll look at the next one when it's ready.

Comment 67

[David :Bienvenu]

Comment on attachment 414077 [details] [diff] [review]
don't persist computed column

clearing review request since Dale is going to attach a new patch based on this one.

Comment 68

[Mitra Ardron]

Hi - Any reason this fix still hasn't made it ?

Comment 69

[Ludovic Hirlimann [:Usul]]

Bienvenu ^^^  ?

Comment 70

[David :Bienvenu]

see #c67 - Dale was going to attach a new patch, which he hasn't done, afaik. At the very least, this needs to be addressed:  "...it always seems to show me for my sent folder instead of the recipient."

Comment 71

[Andrew Sutherland [:asuth] (he/him)]

Comment on attachment 414077 [details] [diff] [review]
don't persist computed column

doxygen comments required explaining what the methods are trying to do.
unit tests required.
the NS_ASSERTION should not be an assertion; various sources are known to cram multiple addresses in there.

Comment 72

[Mitra Ardron]

Pity - this is a bit more important because ShowInOut isn't working on 3.2a1pre, hopefully there won't be a release that seriously breaks TB for those who keep sent & received mail in the same folder.

Comment 73

[Mitra Ardron]

Any chance of something happening on this (ever) - its been there for 8 years now, 66 votes, supposedly Assigned to someone, there is an extension that does it (but of course has to track the latest versions), how hard is it to incorporate the code from the Extension?

Comment 74

[WADA:World Anti-bad-Duping Agency]

FYI.
Similar(but may be different) and old request is found.
> Bug 36489 Combined To/From column in thread pane