Ben Bucksch (:BenB) Reporter
	Description • 25 years ago

From bug #18619

--- Description by Phil ---
Some of the early UE specs showed a To/From column instead of the 4.x-style
Sender column. Although I don't know for sure, I assume that the idea is to look
at the From header, and if it's the same as the current identity, show the To
(or Newsgroups?) header. This has the advantage that it works when you're
keeping a whole thread (both sent and received messages) together.

------- Additional Comments From mozilla@bucksch.org 2000-02-18 04:33 -------
Phil, I like your idea to compare the from with the email address of the current
identity. I always keep threads subject-based and the 4.x behaviour annoys me.

Will we have configurable columns? If yes, I suggest to offer the described
combined To/From field (default) and additionally separate to and from field,
for that case, the proposed logic fails (which may well happen in some advanced
cases).


I suggest for the combined column to not only compare with the From address of
the current, but all identities.

TkRat has this feature implemented.

	Ben Bucksch (:BenB) Reporter
	Comment 1 • 25 years ago

nomination for nsbeta2 consideration - this is not too hard to implement and
would give a noticable usability plus.

	Ben Bucksch (:BenB) Reporter
	Comment 2 • 25 years ago

Thsi bug would also fix bug 36488.

Please ignore my comment above about additional fields - I moved it out to bug
36492. This bug (36489) is now only about a more "intelligent" combined To/From
column. Sorry for the confusion.

	Phil Peterson
	Comment 3 • 25 years ago

[nsbeta2-]. This feature is not on our PRD

	selmer (gone)
	Comment 4 • 25 years ago

Sounds like this is simple to fix and it's really UI polish stuff. Marking M18.

	selmer (gone)
	Comment 5 • 25 years ago

Scott, looks in your area.

	risto.kankkunen
	Comment 7 • 23 years ago

I have attached a patch to implement a combined To/From column. In this column,
the sender is normally shown, unless it matches _any_ of the identities of the
user. In that case the recipient is shown in italics.

The patch adds a new column in addition to the normal Sender column, so the
existing functionality is retained.

There are still some open ends:

1. What to call the column? Currently it is named Identity. To/From could be
   an option, but doesn't match the current terminology with Sender and
   Recipient. Sender/Recipient is a bit long.

2. What should the appearance of the recipient be? The patch only applies to
   modern skin now, where it displays the recipient in italics. I would have
   liked to prefix the name with "To: ", but couldn't do it in CSS.

3. Currently the code matches against any of the user's identities. I have
   ifdeffed out code to match against the identities of the current server
   only. I think the former is better, but would like to hear what others think.

4. I'm wondering if the current switch statements (e.g. in
   nsMsgDBView::GetCellText) comparing just one character of the column names
   are according to the best coding standards...?

5. The code could be made faster by caching the identities, or maybe even the
   in/outbound status of each message.

6. This doesn't yet support sorting by the new column. I'll add that along
   other changes based on comments I receive.

Questions 1 and 2 are UI related, do we need the opinion of a UI expert here?

This is my absolutely first contact with the Mozilla code, so any guidance or
comments are extremely welcome!

[btw. I couldn't add the patch keyword]

	Ninoschka Baca
	Comment 8 • 23 years ago

jglick: Can you give input on items 1 and 2? I don't see the "To/From" concept
in the specs. 

	Ben Bucksch (:BenB) Reporter
	Comment 9 • 23 years ago

Risto, thanks for this code! I didn't try to, but quickly read over it*, and it
looks really good (as far as I understood it). Certainly more than a draft! :-)
Congrats.

*this is no review and I can't give one here

> In that case the recipient is shown in italics.

Italics is not pretty IMO and not hard to understand too. I would prefer an icon
with a left/right arrow (left for sent, right for recieved). Hm, I see that you
tried CSS ":before {content:", but it didn't work for you. Anybody knows why?

In the meantime, itaclis is probably an OK workaround.

> 1. What to call the column? Currently it is named Identity. To/From could be
>    an option, but doesn't match the current terminology with Sender and
>    Recipient. Sender/Recipient is a bit long.

"Identity" is bad, since it gives (me) no hint at what it does and can be
confused with our "Identities" (e.g. a user could think, the column shows, which
Identity in Mailnews sent the mail).

I vote for To/From. "Sender" (as used in Mailnews) is wrong anyway (there's a
bug about it). Author/Recipient would be correct, but is similarily long. Is
that a problem? Anyways, it's better than "Identity".

> static PRBool MatchEmail(nsISupports *aElement, void *aData);

You might want to label the args better and probably make the types more
specific too.

	Ben Bucksch (:BenB) Reporter
	Comment 10 • 23 years ago

Sorry, missed a few of your comments:
> 3. Currently the code matches against any of the user's identities. I have
>    ifdeffed out code to match against the identities of the current server
>    only. I think the former is better, but would like to hear what others think.

I prefer the former too, especially because Mailnews currently doesn't support
more than one Identity per Server. (But I do collect all mails in one Server.)

	risto.kankkunen
	Comment 11 • 23 years ago

Thanks for your comments, Ben! About italics, I agree with you. In the graphical
mail clients that I've seen this feature, italics has been used so I thought it
to be a good first approximation. Icons might be nice!

Anyway, I think this should be something that can be specified by the skin.
Unfortunately the :before pseudo element doesn't work here. If
:-moz-outliner-cell-text(outbound-message) is a pseudo element as it looks like,
the reason apparently is that only one pseudo element can be part of a selector
like the CSS spec states in chapter 5.2 "Selector syntax"
<http://www.w3.org/TR/1998/REC-CSS2-19980512/selector.html#q2>

I'm not too keen on Identity either. It's just there to remind that it should be
changed... ;-)

MatchEmail is a call-back function of the EnumerateForwards call on line 280.
Thus it should have the current types, I think. The names I stole from existing
code, but I'll give a thought about better ones.

	Peter Lairo
	Comment 12 • 23 years ago

[SEMI SPAM]
Lotus Notes has this "combined" collumn too and I find it very confusing (e.g.,
to see my own name there at times). Also for mailing lists (many TO:'s), you
don't know whether you are the sender or just the first recipient on the list.
There are just too many factors that the user has to be aware of (field contains
*two* sets of info: to & from; sepecial cases: mailing lists, use of aliases,
sender also on recipient list, etc.). It would just be replacing the current
suboptimal solution with another suboptimal solution.

Therefore, if this is ever checked in, I suggest to make it an option only, and
off by default.
[/SEMI SPAM]

	risto.kankkunen
	Comment 13 • 23 years ago

Peter, like I say on 2001-08-27 13:14: "The patch adds a new column in addition
to the normal Sender column, so the existing functionality is retained."

If this and the current ones are suboptimal solutions, would you please tell
what is the optimal solution?

(After using it even at the moment it feels much less suboptimal than the
current thing. And after all, I haven't met anything optimal in my life yet...)

	Peter Lairo
	Comment 14 • 23 years ago

[OT]
Risto: I read almost all the bug but must have overlooked the part where the
"to/from" collumn" would be an "additional" collumn - sorry.

PS. "Optimal" would be if I could pose a question to Mozilla with my thoughts,
and ... ;)
[/OT]

	risto.kankkunen
	Comment 16 • 23 years ago

I have attached a new patch I feel is ready for review. Since I didn't receive
any input from the UI folks, I decided those issues on my own. They can be
easily changed later on, and shouldn't affect the code review...

1. I named the column "Author/Recipient". "From/To" would have been my
   favourite, but since those terms are not (yet?) used in the thread pane,
   I think there would have been too much disparity (even if the mail composer
   uses the terms "From" and "To" already...).

2. Instead of the word "To:", I added an icon as suggested by Ben. I like this,
   because it was easier to do than the word, it doesn't need localization and
   it stands out clearly enough. I used one of the general arrows of the skin,
   someone could design a distinctive icon later on if needed.

   I used the icon only to mark the "Recipient" case, having icons for every
   line looked messy to me. But this is easy to change with a style sheet
   anyway. Italics aren't used anymore.

3. The code still matches against all identities, I removed the ifdeffed
   alternative completely.

4. The code now implements sorting, both from the menu and by clicking the
   headers.

This patch affects the Classic skin, too. I also changed some of the parameter
and variable names as suggested. No caching is done.

There are a couple of cases with news articles where you could maybe do differently:

1. If I post a message to a newsgroup which I Bcc to myself, the column shows
   '>"undisclosed recipients:;"' or something similar instead of the newsgroup
   name. It's hard to do better, since Mozilla can't/shouldn't know that
   "undisclosed recipients:;" means that a proper "To:" field is missing (this
   is mail server specific anyway).

2. In a newsgroup, you'll see in your own posts only the arrow icon in the
   column. Again, it's not clear what else to do. It dosn't make sense to show
   the sender (that is, you) there, nor does it make sense to show the newsgroup 
   name there. So while perhaps a bit odd  at first, I think the empty field
   highlights nicely your own posts.

	Peter Lairo
	Comment 17 • 23 years ago

RE #1.) How about *Sender* / Recipient (instead of "Author")? That would makie
it consistent with the terminology for the current "Sender" collumn. ("Author"
sounds so formal and stuffy)

BTW. How did you get your numbered list to "indent" in a text form?

	jglick
	Comment 18 • 23 years ago

I see the benefit of allowing users to have two columns, "Sender" and 
"Recipient".  Showing only the appropriate column by default (Sender for Inbox 
and Recipient for Sent) and enabling users to show the additional column if they 
 want.  But I'm not real clear of the benefits of a combined "Sender/Recipient" 
column. I'm worried it will be confusing to users as far as what information 
this column is displaying. Is it showing the Sender? The Recipient? Is 
the info displayed (sender vs recipient) potentially different for each thread? 
I'm not sure a 'general arrow icon' will help users understand "Recipient" 
information is being shown (vs Sender).

Do you have a screenshot of how this might look to a user?

Cc'ing Mail team engineering leads, sspitzer and mscott for their input and mpt 
and timeless for design/ui thoughts.

	risto.kankkunen
	Comment 19 • 23 years ago

Peter, I used Author as Sender is clearly wrong and Ben already mentioned that
there is a report submitted to change that. I think he was refering to bug 40934.

[About the list and indenting, it was just done by adding linefeeds and spaces...]

	risto.kankkunen
	Comment 20 • 23 years ago

Jennifer, the idea of the Sender/Recipient column is the same as the idea behind
the currently alternating Sender and Recipient columns: to show the most useful
information.

The difference is that Sender/Recipient makes this decision on a message by
message basis. If a message is sent by you, you don't want to see your name, but
the recipient's name. If the message is sent to you, you don't want to see your
name, but the sender's name.
Anyhow, this is an optional and additional column, off by default, so users not
wanting this can just ignore it.

I'll attach a screen shot.

	risto.kankkunen
	Comment 22 • 23 years ago

The screen shot shows both the new Author/Recipient column and the current
Sender column, so you can compare the information shown. Normally a user would
select only one or the other depending on their taste.

You can see, that the Author/Recipient column shows the recipient prefixed by an
arrow for the two messages sent by me. The Sender column just shows my name; not
very informative.
Sorting by the combined column can be useful, too.

	jglick
	Comment 23 • 23 years ago

Thanks for the screenshot. The twistie icon makes it look like the name is 
expandable, and doesn't really indicate that "Ben" is Recipient. Its also 
confusing to have "Author/Recipient" instead of "Sender/Recipient".

	Ben Bucksch (:BenB) Reporter
	Comment 24 • 23 years ago

Risto, I see you managed to get the icon in there. Great!

> I used the icon only to mark the "Recipient" case, having icons for every
> line looked messy to me.

I'd use an icon in both cases. I find it confusing that there's no icon in one case.

- How about using an icon like the green arrow in the "unread message" icon
  in the very left? You could use a higer resolution and turn it 90°/-90°
  respectively.
- I'd insert some space between the arrow and the text.

I am aware that all of this can be adjusted in the skin.

> nor does it make sense to show the newsgroup name there.

Why?

> So while perhaps a bit odd  at first, I think the empty field
> highlights nicely your own posts.

Agreed.

> Sorting by the combined column can be useful, too.

Right.

Jen wrote:
> But I'm not real clear of the benefits of a combined "Sender/Recipient" 
> column.

Separate Recipient/Author columns waste vertical space, because one of them will
(almost) always show my own name, which is not very useful.

The current Sender column, which switches to Recipient for Sent folders, does
not work, if you file messages by topic.
E.g. if I have a folder for ProjectX, and I sort there all messages about that
project. With the current Sender/Recipient column, all of the messages that I
sent will have "Ben Bucksch", and I have to open the message to see to whom I
sent it. The column suggested and implemented here will do the right thing.

Summary:
- The current (standard) Sender/Recipient column works only, if you have only
  INBOX, Sent and Draft as folders. It breaks, if you sort messages by topic.
- The separate columns waste space.
- The suggested solution works in all cases and does not waste space.

	risto.kankkunen
	Comment 26 • 23 years ago

I added a screen shot from the classic skin, where the arrow is much clearer.

Ben:
> > nor does it make sense to show the newsgroup name there.
>
> Why?

If you are in a newsgroup n.p.m.ui, why should the thread pane repeat this
information in the Author/Recipient column for those messages you have posted?
That the message was posted to that group should be as obvious than your own
name... In a mail folder things are different, that was my case #1.

	risto.kankkunen
	Comment 28 • 23 years ago

Another go of the attachment of classic skin. Please ignore id=48652, it's a
BMP. I didn't have permissions to edit it...

	Jesse Ruderman
	Comment 29 • 23 years ago

If this was made the default, it would be more obvious to users that they *can* 
organize their messages by topic.  I think that seeing the column name change 
from "sender" to "recipient" when switching to the sent folder discourages 
users from trying to organize their messages by topic.  If the column label 
remained the same and the arrows appeared in the sent folder, many more users 
would figure out that they can organize messages by topic, including ones they 
sent themselves.

	Ben Bucksch (:BenB) Reporter
	Comment 30 • 23 years ago

Jesse, making it default is the logical consequence from my analysis :-) , but I
didn't want to hold up the implementation / check in by the discussion. what
shoul dbe the default. Let's check it in as optional column, use it for a while,
shake out any possible problems and then advocate to make it the default.

	risto.kankkunen
	Comment 31 • 23 years ago

I'm still looking for r= (and sr=) for this. Any takers?

	(not reading, please use seth@sspitzer.org instead)
	Comment 32 • 23 years ago

sorry for the slow response.  putterman's the wrong owner for this, I'll take it.

	Matthew T (active 1999-2002)
	Comment 33 • 23 years ago

Please don't use an icon. 4.x didn't have or need one, and I think using one 
substantially overestimates the importance of the indicator.

Also, is there any reason not to use `To/From' like 4.x did? `Author/Recipient' 
seems a lot clumsier, and is at much greater risk of being cropped.

	Ben Bucksch (:BenB) Reporter
	Comment 34 • 23 years ago

> Please don't use an icon. 4.x didn't have or need one, and I think using one 
> substantially overestimates the importance of the indicator.

I think the indicator is important. In other cases, the 2 types of messages are
even in different folders. Remember that the column is optional.

I am not aware that 4.x had any column like that.

I think that the icon helps a lot in the visual recognition.

> Also, is there any reason not to use `To/From' like 4.x did?

Yes, read up.

	scottputterman
	Comment 35 • 23 years ago

I wanted to add some comments.

I think this should be off by default which it appears to be from what I've
read.  If you're going to have a long name, then I think we should use
Sender/Recipient instead of Author/Recipient to be consistent with the other
columns.  I'm not against To/From either but I don't want to start that debate
again :)  I'm also concerned about the icon.  I don't think it really conveys
anything in its current form.  I'd suggest that we should either come up with a
better icon or leave it blank.

I'd also be interested in folder loading and scroling performance impact, if
any, when this column is showing.

	Ben Bucksch (:BenB) Reporter
	Comment 36 • 23 years ago

I wrote:

> > Also, is there any reason not to use `To/From' like 4.x did?
> 
> Yes, read up.

Oh, I was confused. I thought about "Sender". "To/From" is fine with me.
(I think ;-P .)

	risto.kankkunen
	Comment 37 • 23 years ago

> I'm also concerned about the icon.  I don't think it really conveys anything in
> its current form.  I'd suggest that we should either come up with a better icon
> or leave it blank.

You are not the first one to suggest that the icon be left out. I wonder do you
really understand what this column is all about? You say we should have a column
that either displays the author or the recipient of the message without any
indication about which one. How should/could the user figure out that?

It should be clear, that there has to be a per message indicator telling which
information the cell is displaying. We have already ruled out text style change
(italics is used in some other mail readers for this). I would rule out a
textual indicator as a localization nightmare: prefixing recipient name with
"To:" might be feasible in English, but for some other languages (e.g. Finnish)
you don't have any short and meaningful prefix. To me it then seems we need some
kind of a symbol.

I chose the arrow icon because I don't pretend to be an icon designer, so I had
to take some existing one as a place holder. However, I believed an arrow symbol
to be quite clear. It is typical (at least in Finland) to use "->Risto" in
hand-written post-it notes to designate the receiver of a memo/fax/letter
whatever. And to my knowledge this hasn't been a problem in our company with
employees of over 10 nationalities. The only reservation I have is with the
looks of the (Modern theme) arrow, but that I consider a bug of the theme.

It would of course be great, if someone came up with a unique and meaningful
icon other than an array for designating the direction of the mail message flow.
But I doubt it. The icons in mailnews toolbar and everywhere, while stylish,
don't really tell me anything before I have learned what they mean. The only
thing I notice is that many of them seem to have some kind of an arrow... ;)

So to clarify: do you (in plural) think the _looks_ of the current arrow icon
are wrong, or is it that you think an arrow to show to/from information doesn't
work in general? Please take a look at both the Classic and Modern screenshots.

	scottputterman
	Comment 38 • 23 years ago

I believe that the current icon doesn't convey what this is about.  I honestly
don't know what icon would or what text style would, but this one looks like
it's a twisty and makes me want to click on it to open a thread.  BTW, I'm not
trying to criticize you for using this icon.  I obviously don't know what to use
either.  But I think it needs to be something else.  My comment about using no
icon was about the fact that I think it would be less confusing than using
something that looks like a twisty.

I also think putting Author/Recipient is confusing when the other columns say
Sender and Recipient.

	jglick
	Comment 39 • 23 years ago

I see the value of the feature but I think the implementation needs some 
tweaking:

1. Column title should be "Sender/Recipient" to match the existing columns. Not 
Author/Recipient or From/To. If it doesn't match the existing columns, i think 
its potentially confusing to users why its the same info as the other columns 
but different wording.

2. Off by default. While this feature maybe useful to some, I don't think 
average users will have the need for it or understand it. Let the users who want 
to use it turn it on. 

3. Icon. If you're going to have an icon here, its needs to be really clear. The 
existing icon looks like a twistie. I'm not sure what could be used to better 
convey the concept.

	Ben Bucksch (:BenB) Reporter
	Comment 40 • 23 years ago

putterman, jglick, I agree with you that a twisty is a bad icon for this column.
How about the little green arrow that is used for the INBOX icon, just without
the container and pointing to the left/right instead of down?

	Ben Ruppel
	Comment 41 • 23 years ago

Looking at the screenshots, I definitely thought the arrow used in modern skin
was a twisty.  HOWEVER, the arrow used for classic is fine.  It's got a trunk,
and I think that is different enough to distinguish it.  Can't you just use that
arrow for both skins?

	risto.kankkunen
	Comment 42 • 23 years ago

OK, I gather that the shape of the Modern theme arrow is the problem here. To me
it would then mean to file a bug about that ("modern theme arrow ugly and looks
like a twisty"), after all that icon is used in other places in Mozilla, too.

Or someone should come up and design a specific icon for this purpose. (I can
try to take the green arrow from the inbox icon, like Ben B. suggests... Or I
can the general arrow from Classic theme to this particular use in the Modern
theme, like Ben R. suggests.)

	risto.kankkunen
	Comment 44 • 23 years ago

OK, I didn't take the green arrow from inbox (it signals something new), nor
steal the Classic right arrow, but took it from the Sent folder: it is already
used to mark something outgoing. See attachment 55065 [details], what do you think now?

	risto.kankkunen
	Comment 45 • 23 years ago

Btw. To avoid confusion, it would be nice, if someone with the powers would mark
attachment 48652 [details] as image/bmp and obsolete. Thanks.

	Peter Lairo
	Comment 46 • 23 years ago

I think you might want to considers having an arrow for every *received* mail,
or for *every* mail. The current screenshot (25.10.01) makes the user do mental
loops trying to analyze which special case applies in each case. 

--> "OK, if there is no arrow, then it's something I received... no wait, it's
also something I sent, but... what are the arrows for then ... ah, if I send
something to myself.... but why then is Ben B. in the collumn *without* an
arrow? (see screenshot) He didn't send it to himself (there would be an arrow),
if it was sent TO him, it would list the sender, if it was sent BY him, it would
list the recipient. Oh no, now my head is spinning - bye.

	risto.kankkunen
	Comment 47 • 23 years ago

To stop your head spinning, the logic is:

  1. No arrow: received mail, Author (From) is shown
  2. Arrow: sent mail, Recipient (To) is shown

If you send something to yourself, you get "->Your name".

Having left arrows for received mail could be done. I tried that, but to my eye
it made the output more restless and hard to read: I had to look very carefully
at the icons to notice which were pointing to what direction. Now I only need to
notice there is some blob before the name to know it's outbound message (once I
have grasped the logic). This is also what I have seen in other mail clients.

	Ben Bucksch (:BenB) Reporter
	Comment 48 • 23 years ago

I agree with Peter that it would be nice to have icons in both cases, but I of
course havn't seen/compared it in practice.
If it is hard to distinguish the left and right arrow, then "fix the arrow".

I think, it would be visually much more pleasing, if there was a small gap
between the arrow and the name.

	Peter Lairo
	Comment 49 • 23 years ago

How about colored arrows:

Black = sent      ( -> recipient@jehaw.com )
Red   = received  ( <- sender@jehaw.com )

That way the stuff we want to read is RED ;)

	timeless
	Comment 50 • 23 years ago

imo mirror imaged icons are not a good idea because of RTL issues

perhaps one that has a Pen[cil] and one that has glasses.

An alternative is two views of an envelope:
Flap side (torn slightly open) for incoming, and (valid, not yet voided) Postage
Mark side for outgoing

	risto.kankkunen
	Comment 52 • 23 years ago

Ben, per your request I'll attach a new screenshot with arrows both for incoming
and outgoing. I'm using that version now myself and still maintain that while it
looks more consistent overall, it is harder to see the direction.

And while "fix the arrow" is in general the right answer, there is not so much
you can do with the available pixels. The difference between an arrow and a
missing arrow is always much bigger.

	Peter Lairo
	Comment 54 • 23 years ago

The envelope solution is too subtile. The difference is not obvious enough.

The glasses / pencil idea sounds good. It would be nice to see an example.

I still think that color coded arrows is the best way to go. Any other graphic
will likely be too blurry and indiscipherable at that small size. The arrows
could easily be vastly improved by making the *horizontal line* part of it thinner.

At a minimum, the graphic s have to be *immediately* differentiable; preferably
by all of these: color, shape, and even size.

	risto.kankkunen
	Comment 57 • 23 years ago

More screen shots for your pleasure. Attachment 55241 [details] might be my current
favorite: it has the original to-only arrow idea, but now the names are aligned
to give a more consistent look.

Attachment 55242 [details] is based on timeless' icons. Not too bad, thanks for the fresh
ideas! (Unfortunately it seems I mixed the from and to icons, but I think you
still get the general feeling of those icons in action).

Peter: color coding would be helpful, but I'm not sure what colors to use. Green
and red seem to be tied with the meanings new and deleted respectively. And the
selected colors should perhaps match with the theme somehow, we don't want to
make this a christmas tree...

	Ben Ruppel
	Comment 58 • 23 years ago

For color coding: the new labels feature in the works would intersect with this.
 I believe you will be able to set it up so all messages from you are a certain
color anyway (eventually).

I agree with risto in that 55241 is my favorite, I just wish I could back it up
with a good argument.  I would say that having both arrows is graphical
overload, and that one should be able to assume that a name is the sender (the
case we're used to from the "sender" column we have now) unless there's an arrow
next to it.  I'll try looking at mail in threaded view to see what comes up.

	Peter Lairo
	Comment 59 • 23 years ago

The colors should apply to the icons only, not the text! Therefore, it would not
interfere with the new "labels" feature.

All we really need is ONE color, since as I suggested before, SENT messages
would remain BLACK, and only received messages would have some color. Maybe this
one color could be chosen to fit-in with the current theme. Modern could have
some shade of blueish-gray.

BTW The aligned version with a "TO" arrow looks pretty spiffy ;) , but I think
your screenshot is a bit misleading, showing ONLY Ben as the recipient. It could
quickly become confusing if there is a *variety* of names on both received and sent.

PS. I still think, after *color* arrows, that a pencil and glasses are the
better-sounding option :)

	Peter Lairo
	Comment 60 • 23 years ago

BTW. The open/closed envelopes could be too easily confused for read/unread
mail, sorry.

	Jesse Ruderman
	Comment 61 • 23 years ago

There should only be an icon for messages you sent.  The to/from column should 
look like the from column in a folder with no sent messages, because there's no 
reason to add visual clutter to those folders.  Also, having only one icon will 
make it easier to see at a glance which messages you contributed to a thread.

	risto.kankkunen
	Comment 64 • 23 years ago

Attachment 56700 [details] [diff] contains the latest patch now complete with the jar.mn changes
to incorporate the new icons. The only thing missing are the 4 icons themselves.
Should I attach them here as separate files?

Attachment 56701 [details] is a screen shot of how the Classic skin currently looks,
implementing the same aligned style already shown for Modern but otherwise with
the same (and accepted as far as I understood) icons.

Is there something I still could do to make this accepted into the trunk?

	Aleksey Nogin
	Comment 65 • 23 years ago

Can you attach something complete, with all the icons? Thanks!

> Is there something I still could do to make this accepted into the trunk?

You could add it to the tracking bug 123569 if you thing all the conditiones
listed there are satisfied by your patch.

	Olga
	Comment 66 • 23 years ago

*** Bug 112047 has been marked as a duplicate of this bug. ***

	Matthew T (active 1999-2002)
	Comment 67 • 23 years ago

> Is there something I still could do to make this accepted into the trunk?

The minimum changes I would regard as necessary for this to appear in a 
professional-quality app would be:
(1) replace the existing Sender and Recipient columns, rather than offering a
    confusing alternative to them;
(2) get rid of the icons.

Both these changes are 4xp. Given the current gap between Mozilla and
professional-quality apps, however, getting the patch is checked in may not 
depend on fixing those things.

	Ben Bucksch (:BenB) Reporter
	Comment 68 • 23 years ago

> (1) replace the existing Sender and Recipient columns, rather than offering a
>     confusing alternative to them;

For now, this is only offered optionally via the column selector.
If we (and Netscape) are confident with how this works, we can swtich which
columns are shown by default.

> (2) get rid of the icons.

How would removing the icons make Mozilla more professional???

Anyways, because the is opt-in and hardly noticable for normal users (but
extremely useful for advanced users), none of this is a blocker for checkin. The
patch would be a strict improvement.

	Aleksey Nogin
	Comment 69 • 23 years ago

I would like to test this patch, can you attach the icons please? Thanks!

	Matthew T (active 1999-2002)
	Comment 70 • 23 years ago

> For now, this is only offered optionally via the column selector.

Exactly. As a replacement it would make Mozilla simpler, but as an addition it 
would make Mozilla more complicated, and Mozilla is already too complicated.

> How would removing the icons make Mozilla more professional???

It's a subtle point, but an important one. The thread pane should support drag 
selection (bug 114637) -- drag a rectangle around the messages you want to 
select. But how do you distinguish between making a drag selection and dragging 
an individual item? The answer is to have a `primary column' for the listbox. 
If you drag on the contents of the primary column you're wanting to move/copy 
the item, whereas if you drag on the contents of any other column you're 
wanting to begin a marquee selection. So how does the user tell which is the 
primary column? That's easy. The primary column contains both icons and text, 
and it's the *only* column which contains both icons and text. In a file 
manager, the primary column is the one which contains the icon and the name for 
a file or folder. In a bookmarks window, the primary column is the one which 
contains the icon and title of the bookmark. And in a thread pane, the primary 
column is the one which contains the icon and the subject line for the message. 
(This means that Mozilla's current behavior of having these as two separate 
columns is a bug.)

So, if you add icons to the To/From column, once drag selection is implemented 
people will inadvertently try dragging the arrows instead of dragging the 
messages, and get annoyed that it starts a drag selection instead. So the icons
*will* have to be ditched once bug 114637 is fixed, and it will be less painful 
to do that now than later.

	Jesse Ruderman
	Comment 71 • 23 years ago

I don't think the icons are a problem, but if you remove them, please replace
them with the text "To " rather than simply removing them.

	Oskar Berggren
	Comment 72 • 23 years ago

I also vote for using "To:" on sent mail (and nothing on recieved). This is also
what 'pine' do.

Any chance of this being included soon? I consider this to be one of the major
drawbacks of using mozilla. 

	laurel
	Comment 73 • 23 years ago

*** Bug 136440 has been marked as a duplicate of this bug. ***

	laurel
	Comment 74 • 23 years ago

*** Bug 141616 has been marked as a duplicate of this bug. ***

	Mike Fedyk
	Comment 75 • 22 years ago

What is the status of this?  It looks very promising.  Also why has Bug 36492
been marked for 1.2alpha and this one not?  Seems kinda backwards since this one
has a patch already.

	Philip Andrew
	Comment 76 • 21 years ago

I was going to file an enhancement request to make the "Recipient" column field
available to *ALL* folder views, rather than just in folders that Mozilla thinks
are "Sent" folders, because at work I like to archive my "Sent" message copies
on a quarter-by-quarter basis (I save a lot of the message for possible future
reference), and I haven't found a way to tell Mozilla that my archive folders
should display the "Recipient" field instead of the "Sender" field (which of
course is always "me").

But then I found this thread.  When I first started reading it, it looked very
promising -- I'd much rather have a self-ajusting "Sender/Recipient" field that
displays the recipient if the sender is "me", and the sender otherwise.  But
then, as with many interesting Bugzilla threads, it seems to have gotten bogged
down in minutiae, and the original clarity of intent lost.  That's the only
explanation I can find for why this hasn't been rolled into the released version
of Mozilla, since so much work seems to have gone into it!

The main objection I've seen (and I'd actually thought of it myself as well) is
that it can be confusing to look at this field and not know whether the name
listed is the Sender or the Recipient.  To which I have the following
suggestion:  If the "Sender" is being displayed, use the normal font; if the
"Recipient" is being displayed, change the text somehow -- my preference would
be to italicize it, but it could be a different color, or even user-configurable
through a pref.

BTW, I think this field should be used by default (instead of "Sender" or
"Recipient"), and in fact would obviate the need for "Sent" folders to be
treated differently w.r.t. the availability of the "Sender" and "Recipient"
columns -- in an Inbox-type folder, the Sender would usually be displayed (or in
cases where I send a message and copy myself, the Recipient in italics), and in
a "Sent"-type folder, the Recipient in italics would always be displayed.

In keeping with this all-folders-are-created-equal spirit, I'd like to see the
"Sender" and "Recipient" fields available in all folders, rather than have
Mozilla try to guess which one I'll want to use.  If you think this is a topic
best discussed in a different enhancement request, please let me know.

Obviously, the current "Sender" and "Recipient" fields can be left available
(off by default) for those users who prefer the current behavior.

	Dan Jenkins
	Comment 77 • 21 years ago

I've been converting many clients from Outlook to Mozilla, primarily for reasons
of viruses (of course). One of the major problems is this lack of the Recipient
column in any folder. I've had people convert back to Outlook because of this
single problem. Now that bug 75866 has been ameliorated with some recent
patches, there are now only two remaining sticking points among my clients
preventing them from migrating to Mozilla. (The other is Calendar/To Do, which
I'm addressing in other ways.) 

While a debate on the aesthetics of different arrows and interfaces may be of
value, fixing the underlying problem with a non-aesthestic solution would be, in
my humble opinion, more valuable. We can always redo the interface in the next
release. At least the boat floats, the paint job can be done back in drydock later.

	Christian :Biesinger (don't email me, ping me on IRC)
	Comment 78 • 21 years ago

> One of the major problems is this lack of the Recipient column in any folder. 

upgrade

	Dan Jenkins
	Comment 79 • 21 years ago

Christian Biesinger wrote:
> upgrade

Why? I'm running Mozilla 1.5. It doesn't allow me to display Recipient except in
the Sent messages folder. (So, I can't have multiple Sent messages folders - for
archival purposes.) Nor to mix Sent & Received in a single folder and display
the appropriate Sender/Recipient header. I read the descriptions of the issues
addressed with 1.5 and found nothing relevant.

I would have thought this bug would be closed if it had been fixed in a recent
release.

	Jacek Piskozub
	Comment 80 • 21 years ago

The trunk builds allow you add a Recipient column to the pane.

It's not done in 1.5 but it has been added to the recent nightly builds (meaning
not mozilla1.5 or mozilla1.4 branches but the trunk). 

By "upgrade", Christian meant downloading a recent nightly trunk build.

	Dan Jenkins
	Comment 81 • 21 years ago

Thanks for the clarification. As I only use Mozilla in a production environment,
I never considered the nightlies. Guess I'll have to wait until it freezes and
is released.

	Mike Cowperthwaite
	Comment 82 • 21 years ago

*** Bug 231497 has been marked as a duplicate of this bug. ***

	Friedrich Lobenstock
	Comment 83 • 21 years ago

Currently running Mozilla 1.7a (Build ID: 2004013007).

I have to say that I would like to be able to specify in which
folders I want to have the Recipient column displayed instead
of the Sender.

Eg. I have the following structure of folders on my IMAP account:
Ablage/
   2002/
      Inbox
      Sent
   2003/
      Inbox
      Sent

So in the Inbox folder I obviously want to see the Sender and
in the Sent folder the Recipient. Currently if I go to the 
folder Ablage/2002/Sent and change the colums to only display
the Recipient then this also effects the main inbox and I have
to undo everything.

Would be nice if the current feature could be extended a little
bit. 

Maybe call the check-box in the preferences
   "guess folder type from its name".

Eg. if one set to save copies of sent mail in the folder 
"Sent" then make every other folder with the same name an
outbox kind folder (by displayin the Recipient instead of
the Sender column).

Otherwise I could think of a feature where one selects the 
kind of folder by right clicking on the folder and changing 
it there.

	Russell East
	Comment 84 • 21 years ago

I'd like to echo the comments of  Philip Andrew ( 2003-10-19) and Dan Jenkins 
(2003-10-19) and encourage the folks who started working on this, way back in
2001, to try and make this happen.  A combined Sender/Recipient (To/From,
whatever...) column would *really* be a useful feature, whatever the UI ends up
becoming, and whether or not it is optional.  Please!  Can you give it another
try?   I have a laptop with limited screen-estate, that's why I kind of need it.
  Thanks, you guys do a wonderful job!

	jwq
	Comment 85 • 18 years ago

 I'm prompted to follow up this bug because I saw the combined From/To column suggested by someone else in the Mozilla wiki "Talk:Thunderbird:2.0 Product Planning" <http://wiki.mozilla.org/Talk:Thunderbird:2.0_Product_Planning#Major_Usability_Redesign_of_Folders_.26_Threads_.28in_4_Steps.29>

 I think that a combined From/To column would be really useful for Thunderbird.

 My former email client, Claris Emailer, uses a combined From/To column which was very intuitive. For incoming messages the sender display name is listed in the From/To column; for outgoing messages, a boldface "To: " is prefixed to the recipient name(s) in the From/To column. This style would require even less UI effort than the icon style above.

	Wayne Mery (:wsmwk)
	Comment 86 • 18 years ago

(In reply to comment #85)
>  I'm prompted to follow up this bug because I saw the combined From/To column
> suggested by someone else in the Mozilla wiki "Talk:Thunderbird:2.0 Product
> Planning"
> <http://wiki.mozilla.org/Talk:Thunderbird:2.0_Product_Planning#Major_Usability_Redesign_of_Folders_.26_Threads_.28in_4_Steps.29>
> 
>  I think that a combined From/To column would be really useful for Thunderbird.

that would be bug 274232


looks the idea got clubbed to death and risto ran out of energy - too bad, could have been delivered 5 years ago.

	Ben Bucksch (:BenB) Reporter
	Comment 87 • 18 years ago

*** Bug 274232 has been marked as a duplicate of this bug. ***

	Wayne Mery (:wsmwk)
	Comment 88 • 18 years ago

http://www.ggbs.de/extensions/ShowInOut.html extension does a great job in thunderbird

	Russell East
	Comment 89 • 18 years ago

Excellent, I like it !!!!!

	David :Bienvenu
	Comment 90 • 18 years ago

Lovely, it looks like the custom column handler stuff was useful for that extension.

	Philip Andrew
	Comment 91 • 18 years ago

Is there any interest in folding something like this into the base Thunderbird itself?

	David Peters
	Comment 92 • 17 years ago

Throw my vote in for this, as well as a screenshot of my current TB setup:

http://tinyurl.com/2uoghh

David.P

	WADA:World Anti-bad-Duping Agency
	Comment 93 • 17 years ago

FYI.
Penelope(Eudora based on Tb) already has "unified Who column", although current implementation by Eudora 8.0.0b1 is not final goal(see Bug 400090).

	Peter Lairo
	Comment 94 • 16 years ago

Would it be possible to use the code from the "Show InOut" Add-on?

https://addons.mozilla.org/de/thunderbird/addon/3492

	WADA:World Anti-bad-Duping Agency
	Comment 95 • 13 years ago

Ben(bug opener), same request as bug 359270?

	Mitra Ardron
	Comment 97 • 13 years ago

This must hold the record for a feature requested for over ten years; lots of votes & comments; with code that could be grabbed from an existing extension, and the default in pretty much every other mailer I've used. 

ShowInOut works well, but is often not available on the alpha/beta versions and of course doesn't get the support it would if it was integrated.   

Can someone please integrate it.

	Wayne Mery (:wsmwk)
	Comment 98 • 13 years ago

(In reply to WADA from comment #95)
> Ben(bug opener), same request as bug 359270?

if 359270 is going to be kept as a duplicate, then this bug must move to mailnews. Or dedupe.

	Wayne Mery (:wsmwk)
	Comment 99 • 13 years ago

bug 359270 comment 70 + 71 specifies the state of a patch much more current than this bug's unreviewed patch

	Thomas D. (:thomas8)
	Comment 101 • 11 years ago

FTR: This nice idea first filed by Ben has 64 votes on bug 359270 currently marked duplicate of this bug, and 24 non-duplicate votes (out of 25) on this bug, which makes a total of 87 votes (including mine which I've just added :)

	neil@parkwaycc.co.uk Assignee
	Comment 102 • 10 years ago

I wrote this without comparing with previous patches or the extension. Instead I adapted the code used for replying to your own messages (including the pref).

It creates a single column which includes a direction indicator (currently stolen from elsewhere in the theme) and a correspondent name.

	neil@parkwaycc.co.uk Assignee
	Comment 103 • 10 years ago

This version always checks against all identities. It also checks for reply-to addresses as well. It caches all the email addresses in a hash set which makes sorting a little faster. Also I think part of the first patch got truncated.

	Mitra Ardron
	Comment 104 • 10 years ago

If this works it would be great to get it integrated, this is a LONG overdue request.

	Ben Bucksch (:BenB) Reporter
	Comment 105 • 10 years ago

Comment on attachment 8486524 [details] [diff] [review]
WIP

> It caches all the email addresses in a hash set which makes sorting a little faster.

Yes, that's good. I agree that we need that, for fast display of large folders.

I superficially looked over the code and it looks very reasonable to me.
feedback+

	:aceman
	Comment 106 • 10 years ago

Comment on attachment 8486524 [details] [diff] [review]
WIP

Review of attachment 8486524 [details] [diff] [review]:
-----------------------------------------------------------------

Thanks for enabling this for TB. I assume you do the corresponding SM changes in a later iteration.
I have yet to build/run this, but here are my nits:

::: mail/base/content/folderDisplay.js
@@ +372,5 @@
>      "attachmentCol",
>      "flaggedCol",
>      "subjectCol",
>      "unreadButtonColHeader",
> +    "correspondentCol",

So is this suddenly becoming the default instead of the old columns? We should run it through UX people.

::: mail/base/content/mailWindowOverlay.js
@@ +312,5 @@
>        sortType == nsMsgViewSortType.byPriority ||
>        sortType == nsMsgViewSortType.bySubject || sortType == nsMsgViewSortType.byTags ||
>        sortType == nsMsgViewSortType.byRecipient || sortType == nsMsgViewSortType.byAccount ||
>        sortType == nsMsgViewSortType.byStatus || sortType == nsMsgViewSortType.byFlagged ||
> +      sortType == nsMsgViewSortType.byAttachments || sortType == nsMsgViewSortType.byCorrespondent);

byDirection does not support grouping?

::: mail/base/content/messenger.xul
@@ +500,5 @@
>                          <splitter class="tree-splitter"/>
>                          <treecol id="idCol" persist="width" flex="1" hidden="true"
>                                   label="&idColumn.label;" tooltiptext="&idColumn2.tooltip;"/>
> +                        <splitter class="tree-splitter"/>
> +                        <treecol id="directionCol" flex="1" label="Direction"/>

&directionColumn.label ?

::: mailnews/base/src/nsMsgDBView.cpp
@@ +2252,5 @@
> +
> +    identity->GetReplyTo(email);
> +    if (!email.IsEmpty())
> +      mEmails.PutEntry(email);
> +  }

When does this get run so that the mEmails are populated? What if identities change in a session?

	neil@parkwaycc.co.uk Assignee
	Comment 107 • 10 years ago

(In reply to aceman from comment #106)
> Thanks for enabling this for TB. I assume you do the corresponding SM
> changes in a later iteration.
I'd just forgotten to include them.

> > +    "correspondentCol",
> So is this suddenly becoming the default instead of the old columns? We
> should run it through UX people.
Fair enough.

> > +      sortType == nsMsgViewSortType.byAttachments || sortType == nsMsgViewSortType.byCorrespondent);
> byDirection does not support grouping?

> > +                        <treecol id="directionCol" flex="1" label="Direction"/>
> &directionColumn.label ?
I can't remember whether I completed the support for this column. (I didn't add support for it to SeaMonkey for instance.)

> > +    identity->GetReplyTo(email);
> > +    if (!email.IsEmpty())
> > +      mEmails.PutEntry(email);
> > +  }
> When does this get run so that the mEmails are populated? What if identities
> change in a session?
It gets run every time you switch folder.

	:aceman
	Comment 108 • 10 years ago

(In reply to neil@parkwaycc.co.uk from comment #107)
> > > +      sortType == nsMsgViewSortType.byAttachments || sortType == nsMsgViewSortType.byCorrespondent);
> > byDirection does not support grouping?
> 
> > > +                        <treecol id="directionCol" flex="1" label="Direction"/>
> > &directionColumn.label ?
> I can't remember whether I completed the support for this column. (I didn't
> add support for it to SeaMonkey for instance.)
It looks like useful feature that will be needed to manage the messages if only the combined column is shown. Could you finish it? It also seems people requested it in the comments (proposing colors or arrows to indicate direction).

	neil@parkwaycc.co.uk Assignee
	Comment 109 • 10 years ago

(In reply to aceman from comment #108)
> It looks like useful feature that will be needed to manage the messages if
> only the combined column is shown. Could you finish it? It also seems people
> requested it in the comments (proposing colors or arrows to indicate
> direction).

Ah, I remember now, the arrows appear in the combined column, so there's no need for a separate column, I probably just forgot to remove it from Thunderbird.

	Blake Winton (:bwinton) (:☕️)
	Comment 110 • 10 years ago

Comment on attachment 8486524 [details] [diff] [review]
WIP

Review of attachment 8486524 [details] [diff] [review]:
-----------------------------------------------------------------

So, the icons bug me, but I'm not entirely sure why.  I also think they'll be problematic in RTL languages, although hopefully that's fairly easily fixable.
I'm adding Richard, to see if we can get better icons, or if he's happy with these.  (Maybe something less curved and more straight would look better?)

I do like the functionality, and think that it's lightweight enough to use as the default, though, so other than the icons, it would get a ui-r+ from me, I think.

	Richard Marti (:Paenglab)
	Comment 111 • 10 years ago

Comment on attachment 8486524 [details] [diff] [review]
WIP

I'm also not happy with using the replied/forwarded icons. On Linux/Windows they are additionally blue and green. I give ui-r+ with the requirement of a followup bug for this icons.

And the conversation view needs this column as default, as I think, the most because this view has always both directions in the same list.

Is it possible to set this default only for mail accounts? RSS- and news accounts have normally only the in direction.

	neil@parkwaycc.co.uk Assignee
	Comment 112 • 10 years ago

(In reply to Blake Winton from comment #110)
> So, the icons bug me, but I'm not entirely sure why.  I also think they'll
> be problematic in RTL languages, although hopefully that's fairly easily
> fixable.
I think you can style things differently using :-moz-locale-dir pseudoclasses.

> I'm adding Richard, to see if we can get better icons, or if he's happy with
> these.  (Maybe something less curved and more straight would look better?)
They weren't intended to be the final icons, but I'm not a graphic designer, so I just used something that was conveniently available.

(In reply to Richard Marti from comment #111)
> And the conversation view needs this column as default, as I think, the most
> because this view has always both directions in the same list.
What's a conversation view?

> Is it possible to set this default only for mail accounts? RSS- and news
> accounts have normally only the in direction.
I don't know, I'd have to look to see how column defaults work (if at all).

	Richard Marti (:Paenglab)
	Comment 113 • 10 years ago

(In reply to neil@parkwaycc.co.uk from comment #112)
> (In reply to Richard Marti from comment #111)
> > And the conversation view needs this column as default, as I think, the most
> > because this view has always both directions in the same list.
> What's a conversation view?

On a message, right click and select "Open Message in Conversation". Then you see the whole thread in a list in a new tab.

	Richard Marti (:Paenglab)
	Comment 114 • 10 years ago

This patch is the same as from Neil but with special arrow icons.

	neil@parkwaycc.co.uk Assignee
	Comment 115 • 10 years ago

* Includes arrow icons from attachment 8545366 [details] [diff] [review]
* Correspondent column is now displayed by default for non-news folders
* Correspondent column replaces sender/recipient columns in non-news folders
That is to say, if a non-news folder had either the sender or recipient column, then that column gets replaced with the correspondent column. If they had both, then the sender column is removed and the recipient column is replaced. This is a one-time operation.

	Blake Winton (:bwinton) (:☕️)
	Comment 116 • 10 years ago

Comment on attachment 8553906 [details] [diff] [review]
Proposed patch

Well, ui-r- based on https://www.dropbox.com/s/oavw08oeqnn9uvj/Screenshot%202015-02-08%2014.50.53.png?dl=0 but if you want to post a try-build or some screenshots, I'll be happy to re-ui-review it (and much faster this time)!

	neil@parkwaycc.co.uk Assignee
	Comment 117 • 10 years ago

https://treeherder.mozilla.org/#/jobs?repo=try-comm-central&revision=c11f110b3d75

	neil@parkwaycc.co.uk Assignee
	Comment 118 • 10 years ago

Premature save :-( I got bitten by Bugzilla's tabbing order.

	neil@parkwaycc.co.uk Assignee
	Comment 119 • 10 years ago

Here's that Try build you asked for:

https://treeherder.mozilla.org/#/jobs?repo=try-comm-central&revision=14cdd3c11c22

	Blake Winton (:bwinton) (:☕️)
	Comment 120 • 10 years ago

Comment on attachment 8553906 [details] [diff] [review]
Proposed patch

Okay, I like the arrows, and it mostly seems to make sense, so I'm going to say "ui-r=me", but…

I've run into a few cases where email not from me got marked as being from me, perhaps because I have multiple accounts…  (Perhaps it could check for the address of the current account, instead of all my sending addresses, or something?)

	:aceman
	Comment 121 • 10 years ago

(In reply to Blake Winton (:bwinton) from comment #120)
> I've run into a few cases where email not from me got marked as being from
> me, perhaps because I have multiple accounts…  (Perhaps it could check for
> the address of the current account, instead of all my sending addresses, or
> something?)

Were you sending and email from one of your addresses to another one? Or how should we understand this problem?

	:aceman
	Comment 122 • 10 years ago

I have cleaned up the obsolete patches but I don't know if the remaining screenshots represent the current patch in any way.

	Blake Winton (:bwinton) (:☕️)
	Comment 123 • 10 years ago

Yeah, or from an address I only have in a news account…

	Kent James (:rkent)
	Comment 124 • 10 years ago

I build this, and the Correspondent column is blank. Am I supposed to do something for that to work?

	neil@parkwaycc.co.uk Assignee
	Comment 125 • 10 years ago

(In reply to Kent James from comment #124)
> I build this, and the Correspondent column is blank. Am I supposed to do
> something for that to work?

Huh, that's two of you (see comment #116). Is my patch different from my Try push?

	Kent James (:rkent)
	Comment 126 • 10 years ago

I should have mentioned that the patch application did not go perfectly, though I *thought* I fixed it, so I suspect that is the issue. Could you please try regenerating the patch?

	Magnus Melin [:mkmelin]
	Comment 127 • 10 years ago

Comment on attachment 8553906 [details] [diff] [review]
Proposed patch

Review of attachment 8553906 [details] [diff] [review]:
-----------------------------------------------------------------

I couldn't get the patch to apply so haven't tested it yet.

::: mail/base/content/messenger.xul
@@ +500,5 @@
>                          <splitter class="tree-splitter"/>
>                          <treecol id="idCol" persist="width" flex="1" hidden="true"
>                                   label="&idColumn.label;" tooltiptext="&idColumn2.tooltip;"/>
> +                        <splitter class="tree-splitter"/>
> +                        <treecol id="directionCol" flex="1" label="Direction"/>

use localiced label and add the tooltip

::: mail/base/modules/dbViewWrapper.js
@@ +1361,5 @@
>      return Boolean(this.displayedFolder &&
>                     (this.displayedFolder.flags & nsMsgFolderFlags.Newsgroup));
>    },
>  
> +  get isRSSFolder() {

I think isFeedFolder is a more correct naming

	neil@parkwaycc.co.uk Assignee
	Comment 128 • 10 years ago

I've rebased the patch so hopefully you'll be able to apply it now. (There were no manual merges necessary as a result of the rebase so I'm not sure why you weren't able to apply it.) I also made that minor rename you requested.

	Magnus Melin [:mkmelin]
	Comment 129 • 10 years ago

Comment on attachment 8568429 [details] [diff] [review]
Updated patch

Review of attachment 8568429 [details] [diff] [review]:
-----------------------------------------------------------------

I like it, except for the label "Correspondent". Especially as it's not a singular data... and sounds very formal. Eudora had "Who" - what do you think?

Please also add the column in the search dialog.

	neil@parkwaycc.co.uk Assignee
	Comment 130 • 10 years ago

(In reply to Magnus Melin from comment #129)
> I like it, except for the label "Correspondent". Especially as it's not a
> singular data... and sounds very formal. Eudora had "Who" - what do you
> think?
I think that's between you and bwinton...

> Please also add the column in the search dialog.
Eww. It took me some time to find some UI to even get there, and then I think the columnpicker might be broken...

	Ben Bucksch (:BenB) Reporter
	Comment 131 • 10 years ago

"Who" doesn't fit the other columns. They are not called "What" and "When", but "Subject" and "Date", which is also formal, so I personally think "Correspondent" fits well. (And I think that's fine even if there are several recipients.)

	Wayne Mery (:wsmwk)
	Comment 132 • 10 years ago

I don't think there is anything formal about the other column names. They are straight forward, plain jane descriptors. Correspondent is decidedly singular.  And I suspect the first thing that comes to people's mind for the term Correspondent is reporter or journalist.

My gut preference is for Who, but I'm OK with whatever the UI folks decide.

	Russell East
	Comment 133 • 10 years ago

From http://www.thesaurus.com/browse/correspondents, "Writer" is considered a synonym for "Correspondent".  Writer has many meanings within differing contexts, but it might make sense here.

	neil@parkwaycc.co.uk Assignee
	Comment 135 • 10 years ago

(In reply to comment #130)
> (In reply to Magnus Melin from comment #129)
> > Please also add the column in the search dialog.
> Eww. It took me some time to find some UI to even get there, and then I
> think the columnpicker might be broken...
It is, so I reverted it back to the toolkit columnpicker.

	Magnus Melin [:mkmelin]
	Comment 136 • 10 years ago

Comment on attachment 8572050 [details] [diff] [review]
Updated patch

Review of attachment 8572050 [details] [diff] [review]:
-----------------------------------------------------------------

Blake, what's your take on the wording?
I don't like Correspondent label as it is singular and the column data is multiple addresses (most of the time). "Who" like Eudora was suggested.

If we use Correspondent it should at least be changed to Correspondents imo.

	Blake Winton (:bwinton) (:☕️)
	Comment 137 • 10 years ago

"Participants", maybe?  I'm tempted to go with "Corresponders", and see what people offer as suggestions when they're disgusted with that option…  ;)

	Blake Winton (:bwinton) (:☕️)
	Comment 138 • 10 years ago

Comment on attachment 8572050 [details] [diff] [review]
Updated patch

(I could live with "Correspondents", if we can't find anything better.)

	Jim Porter (:squib)
	Comment 139 • 10 years ago

(In reply to Magnus Melin from comment #136)
> If we use Correspondent it should at least be changed to Correspondents imo.

Well, we use "Recipient" for the recipients column, so "Correspondent" is actually consistent (in a bad way).

	Magnus Melin [:mkmelin]
	Comment 140 • 10 years ago

Yeah bug 522886...

	Thomas D. (:thomas8)
	Comment 141 • 10 years ago

Just my 2 cents (from a qualified language person):

"Correspondent" accurately describes the content of this column:
Latin roots: (cum-)respondens - the person answering (with (me))
So the original meaning of "correspondent" is exactly "the other partner communicating with me / I'm communicating with".

While this might be a bit less frequently used in English (because you rarely talk about people you talk to in an abstract way), it's a good template for other languages, which might well have better terms: e.g. German "Gesprächspartner" (talk partner) sounds quite natural, no sophistication.

"Who" is somewhat fresh and short (not bad actually), but perhaps also slightly inconsistent as the odd one out between other descriptive column headers all using nouns like "Sender" (currently "From", we should change that), "Recipients", "Subject", "Location" (and not question words like "what" or "where").

Singular vs. Plural: I think "Correspondent" is better than "Correspondents". My language feeling says that "Correspondents" (plural) is actually more prone to imply "all parties corresponding with each other", i.e. sender AND recipients in our context. But what we really mean here is "the other party I'm communicating with", which is conceptually singular, even if they happen to be many. ;) Think of communication models having "Sender" and "Recipient", which are just common collective terms regardless of the actual number. So I believe "Correspondent" will be the more accurate collective term without any preclusions about singular or plural.

Just my 2 cents. :P

As a sidenote, by analogy we COULD also use "Recipient" (singular) for Bug 522886, but there are some reasons that might justify to use "Recipients" (plural):
- using plural provides a hint that we include ALL TYPES of recipients in this column (To, CC, BCC)
- "Recipients" are very likely be many whereas in our "Correspondent" column, for all mails from others it will always be a single sender, and we tend to receive more mails than we write (so there'll be more single senders in this column than multiple recipients).
- it will not be semantically ambiguous like "Correspondents", because "Recipients" are always "the other party, seen from sender"

	Thomas D. (:thomas8)
	Comment 142 • 10 years ago

(In reply to Ben Bucksch (:BenB) from comment #131)
> "Who" doesn't fit the other columns. They are not called "What" and "When",
> but "Subject" and "Date", which is also formal, so I personally think
> "Correspondent" fits well. (And I think that's fine even if there are
> several recipients.)

So I agree with Ben! :p

(In reply to Russell East from comment #133)
> From http://www.thesaurus.com/browse/correspondents, "Writer" is considered
> a synonym for "Correspondent".  Writer has many meanings within differing
> contexts, but it might make sense here.

"Writer" wouldn't work because it would be synonymous with "Sender", but this column alternately displays Sender OR Recipient(s).

(In reply to Blake Winton (:bwinton) from comment #137)
> "Participants", maybe?  I'm tempted to go with "Corresponders", and see what
> people offer as suggestions when they're disgusted with that option…  ;)

Yeah, but "Participants" of a conversation would usually include myself unless we declare this to mean "other participants execpt myself" ;) "Corresponders" is cool, let's just create those words English is lacking! ;P

	neil@parkwaycc.co.uk Assignee
	Comment 143 • 10 years ago

(In reply to Thomas D. from comment #142)
> "Corresponders" is cool, let's just create those words English is lacking! ;P

The English language embiggens as more words become cromulent ;-)

	Magnus Melin [:mkmelin]
	Comment 144 • 10 years ago

Apparently "Who" is also what Lotus Notes use.

Made up words may be challenging for localizers ;)

	Ben Bucksch (:BenB) Reporter
	Comment 145 • 10 years ago

If we use "Who", then we should change the rest to "What" and "When", too.
http://www.bucksch.org/xfer/music-for-friends/Tujamo-Who.mp3  :-)

> (I could live with "Correspondents", if we can't find anything better.)

That's good for me. Let's go with that.

	Magnus Melin [:mkmelin]
	Comment 146 • 9 years ago

Comment on attachment 8572050 [details] [diff] [review]
Updated patch

Review of attachment 8572050 [details] [diff] [review]:
-----------------------------------------------------------------

Oh well, let go for Correspondents then. r=mkmelin with that

	Ben Bucksch (:BenB) Reporter
	Comment 147 • 9 years ago

Neil: Please commit

	Magnus Melin [:mkmelin]
	Comment 148 • 9 years ago

(the patch should be updated with the added "s" before checkin)

	Ben Bucksch (:BenB) Reporter
	Comment 149 • 9 years ago

"s" added to labels

Carrying over:
mkmelin+mozilla: review+
bwinton: ui-review+

	Ben Bucksch (:BenB) Reporter
	Comment 150 • 9 years ago

Icons:
Using it, I notice the icon is too subtle. The "Replied" icon is big, fat and blue, while the "I wrote this" icon is small and thin and green.
- It should be much bigger and much more prominent.
- The color should be stronger, e.g. in red or a dark green.
- The arrow should be just straight to the left, not down and then left.
- There should be an icon for incoming, too. This one should be less prominent, in another color, e.g. in yellow.

The goal is that I can see just with my peripheral vision whether this is incoming or outgoing, and that my outgoing ones stand out and can be clearly distinguished  with peripheral vision only.

	neil@parkwaycc.co.uk Assignee
	Comment 151 • 9 years ago

Pushed comm-central changeset 88e60fbcd53a.

The push hook insisted I changed nsMsgViewSortType's uuid which I did since nobody uses it anyway.

	neil@parkwaycc.co.uk Assignee
	Comment 152 • 9 years ago

Backed out in https://hg.mozilla.org/comm-central/rev/9907b50b939f for test failures in https://treeherder.mozilla.org/#/jobs?repo=comm-central&revision=88e60fbcd53a

	neil@parkwaycc.co.uk Assignee
	Comment 153 • 9 years ago

Relanded with test fixes in comm-central changeset 8567e72b848b.

	Joe Sabash [:JoeS1]
	Comment 154 • 9 years ago

I'm not seeing the direction arrow in the correspondents column in todays nightly
Although I did see it in a local build which included the first application, before yhe backout.

	neil@parkwaycc.co.uk Assignee
	Comment 155 • 9 years ago

(In reply to Joe Sabash from comment #154)
> I'm not seeing the direction arrow in the correspondents column in todays
> nightly
> Although I did see it in a local build which included the first application,
> before the backout.

Oops, I forgot to reland the image changes. (Because Mercurial won't let me graft a patch that got backed out, I did it manually, and messed up the images.) Pushed comm-central changeset 4436cbc215df.

	Jorg K (CEST = GMT+2)
	Comment 156 • 9 years ago

Is there an option to switch off this new function?

I'm running TB 39 (Earlybird) and it imposed the "Correspondents" column and got rid of the "From" column. Going back to TB 38 I'm left with no column indicating the sender. That's not exactly backward compatibility ;-) I'd like to avoid having to switch all folders manually.

	:aceman
	Comment 157 • 9 years ago

Jorg, I think the old columns of From and Recipient are not lost, just hidden by default. If you toggle them on in TB39 (and hide correspondent), it they could be round-tripped correctly between TB38?

	Jorg K (CEST = GMT+2)
	Comment 158 • 9 years ago

The behaviour is this for the Inbox:
1) Start TB 39: From removed, Correspondents enabled.
2) Start TB 38: No From (and no Correspondents). Switch on From manually again.
3) Start TB 39: From removed, Correspondents enabled, same as in 1)
4) Still in TB 39: Switch off Correspondents, turn on From.
5) Start TB 38: From is still there. So far so good, but not for long.
6) Start TB 39: Guess what: From removed, Correspondents enabled.
Are you tired yet of switching columns back on/off? I am.

I can understand what happens, but I don't think it's good.

IMHO, we should force a UI change onto the user. If they want "Correspondents", they can select it. If they don't select it, the behaviour shouldn't change.

If we must force the new good stuff onto the user, there should be a switch/preference to disable the unwanted goodness.

	Jorg K (CEST = GMT+2)
	Comment 159 • 9 years ago

What about sorting by "Correspondents"? Should the
--> correspondent (as recipient) and
<-- correspondent (as sender)
not be separated so one can specifically look for a sent or received message?
Currently they are mixed together.

	Jorg K (CEST = GMT+2)
	Comment 160 • 9 years ago

(In reply to Jorg K (at the beach until 22nd April) from comment #158)

> IMHO, we should force a UI change onto the user.

I think the "upgrade" to the new scheme is just a little to aggressive:
https://dxr.mozilla.org/comm-central/source/mail/base/content/folderDisplay.js#693

What's wrong with leaving it turned off by default?

	:aceman
	Comment 161 • 9 years ago

We should probably discuss this in a new bug. The feature is finally there (thanks Neil!) the toggling of it can be improved now in followup bugs. This one is already too long.

	Jorg K (CEST = GMT+2)
	Comment 162 • 9 years ago

Done. Bug 1152706.

	David E. Ross
	Comment 163 • 8 years ago

I did not want this change in my setup, but it was implemented as the default.  Now I have to manually change back to what I had in 40+ E-mail folders (not counting subfolders).

	Jorg K (CEST = GMT+2)
	Comment 164 • 8 years ago

(In reply to David E. Ross from comment #163)
> I did not want this change in my setup, but it was implemented as the
> default.  Now I have to manually change back to what I had in 40+ E-mail
> folders (not counting subfolders).
No you don't. That's why I implemented an option to switch the auto-upgrade off: Bug 1152706.
mailnews.ui.upgrade.correspondents

	Ben Bucksch (:BenB) Reporter
	Comment 165 • 8 years ago

You can also set the inbox folder and have its column setup apply to all contained folder. That's another feature that was implemented a few years ago.

	Anje
	Comment 166 • 8 years ago

The release notes state: 'Add a Correspondents column combining Sender and Recipient.'

downloaded version 45 from http://ftp.mozilla.org/pub/thunderbird/releases/ as it not available on release channel nor via main website.
Result:
FROM  column is auto not displaying and so has to be manually enforced. Not impressed.
FROM is essential not a 'only if you want it' option and should never be disabled by default with the exception of the 'Sent' folder where 'Recipients' should be enabled by default.

In the 'Sent' folder, 'Correspondents' is exactly the same as 'Recipients' with the exception that a grey arrow pointing to right - not sure what that is supposed to mean. 
It only displays all contact names who received an email from me = 'Recipients' column.

In all other folders, 'Correspondents' column is exactly the same as the 'FROM' column with the exception that a grey arrow pointing to left - not sure what that is supposed to mean, but if I send an email to myself, then it will appear to point to the right - opposite direction, so I'm assuming the left and right indicated whether I sent the email or not....somehow I think I might notice that.
It only displays the contact name of person who sent an email to me = 'FROM' column.

I fail to see why so much time and effort was employed in duplicating something that already existed.
The only difference is that it is enabled by default and FROM is not selected as a default column header.
It most certainly does not combine sender and recipient in any folder.

	Anje
	Comment 167 • 8 years ago

As this 'correspondents' column header is a complete failure in all aspects and the default removal of the essential 'FROM' column from auto display, should I start a new bug?

	Jorg K (CEST = GMT+2)
	Comment 168 • 8 years ago

No one forces you to use it. Set the preference mailnews.ui.upgrade.correspondents to false as per bug 1152706 and continue life as before.

	Anje
	Comment 169 • 8 years ago

What is the point of shutting the gate after the horse has bolted?
I downloaded and it was already set up.
I noted that people had either wasted a load of time reinventing the 'Recipient' column to have a little useless arrow which increases the width of the column OR this is a massive bug and has totally failed.

The 'correspondents' column header does not do as it is supposed to do..it does not combine FROM and Recipient info. 

Only after finding this bug do you get to know how to switch off the item I had already wasted time in removing and then resetting the correct column headers.

Can I assume that the developers think it is perfectly correct to not have any 'FROM' details showing by default in the list of emails ?

	Kent James (:rkent)
	Comment 170 • 8 years ago

(In reply to Anje from comment #167)
> As this 'correspondents' column header is a complete failure in all aspects
> and the default removal of the essential 'FROM' column from auto display,
> should I start a new bug?

In short, if you want to propose any modifications to this feature (including removal) in future versions of Thunderbird, then yes that needs to be done in a new bug.

	justforpublic@gmail.com
	Comment 171 • 8 years ago

(In reply to Anje from comment #169)
> What is the point of shutting the gate after the horse has bolted?
> I downloaded and it was already set up.
> I noted that people had either wasted a load of time reinventing the
> 'Recipient' column to have a little useless arrow which increases the width
> of the column OR this is a massive bug and has totally failed.
> 
> The 'correspondents' column header does not do as it is supposed to do..it
> does not combine FROM and Recipient info. 
> 
> Only after finding this bug do you get to know how to switch off the item I
> had already wasted time in removing and then resetting the correct column
> headers.
> 
> Can I assume that the developers think it is perfectly correct to not have
> any 'FROM' details showing by default in the list of emails ?

That's not quite true. The From: person is still showing by default in most mailboxes, it's just labeled "Correspondents" and has an arrow pointing away from the sender, to indicate that the message came from the name listed. In a typical mailbox, this is a semantic, rather than functional change. 

However, if you mix both your sent email and received email in the same mailbox, then the value of the Correspondents column shows up: it's not meant to show both sides of the conversation, just the side that is "not you". So for mail you've sent, it shows the recipient (with an arrow towards the name to indicate that the email went to that person); for mail you've received, it shows the sender (with an arrow pointing away from the name to indicate that the email went away from that person). 

I'm not sure, yet, that I like this change; maybe it's self evident that the emails in a thread that say they are from you are to whoever you replied to. But it makes perfect sense—there's presumably never any need to know that you are one of the correspondents in your own email. What the user typically cares about is the other correspondent. 

I think Anje's confusion is a good argument for going with singular "Correspondent" over plural "Correspondents", however. Even before getting to their post, that was what I was thinking. Since it typically only shows you one person at a time, and never both sides of the communication, the plural is misleading.