After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 225392 - Add column "real name" to mail message list (sender name only without email address)
Add column "real name" to mail message list (sender name only without email a...
Status: RESOLVED FIXED
Product: evolution
Classification: Applications
Component: Mailer
2.22.x (obsolete)
Other other
: Normal enhancement
: Future
Assigned To: evolution-mail-maintainers
Evolution QA team
: 236285 315318 317877 327768 509808 512964 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2002-05-28 16:14 UTC by Christian Kreibich
Modified: 2012-02-14 10:52 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
the patch itself, created using cvs diff. Apply with -p1. (26.72 KB, patch)
2002-05-28 16:15 UTC, Christian Kreibich
needs-work Details | Review
Screenshot of address-only display (22.20 KB, image/gif)
2002-05-28 17:36 UTC, Christian Kreibich
  Details
Shot of the usual name-and-address mode (22.62 KB, image/gif)
2002-05-28 17:37 UTC, Christian Kreibich
  Details
Shot of name-only mode (15.28 KB, image/gif)
2002-05-28 17:38 UTC, Christian Kreibich
  Details
Shot of the config dialog with new options (72.24 KB, image/gif)
2002-05-28 17:48 UTC, Christian Kreibich
  Details

Description Christian Kreibich 2002-05-28 16:14:10 UTC
This patch should apply cleanly against CVS HEAD as of 05/28/02.

It adds three config options to the Message Display section in the General
tab of Mail Preferences. You can choose whether you want to see name +
address, address or name only. The update of the current message list is
achieved through listening to the responsible config setting, which is

Bonobo/ConfigDatabase:change/Mail/Display:address_style

Cheers,
Christian.
Comment 1 Christian Kreibich 2002-05-28 16:15:04 UTC
Created attachment 41246 [details] [review]
the patch itself, created using cvs diff. Apply with -p1.
Comment 2 Anna Marie Dirks 2002-05-28 16:52:11 UTC
Can you make a screenshot of this, Christian? I am in the middle of an
Evolution build and would like to review your design ASAP. 

Thanks, Anna
Comment 3 Christian Kreibich 2002-05-28 17:36:59 UTC
Created attachment 41247 [details]
Screenshot of address-only display
Comment 4 Christian Kreibich 2002-05-28 17:37:57 UTC
Created attachment 41248 [details]
Shot of the usual name-and-address mode
Comment 5 Christian Kreibich 2002-05-28 17:38:30 UTC
Created attachment 41249 [details]
Shot of name-only mode
Comment 6 Christian Kreibich 2002-05-28 17:40:23 UTC
Anna, I've attached 3 shots to this report.

Hope this helps,
Christian.
Comment 7 Christian Kreibich 2002-05-28 17:48:30 UTC
Created attachment 41250 [details]
Shot of the config dialog with new options
Comment 8 Jeffrey Stedfast 2002-05-28 18:07:36 UTC
several things wrong with this patch before I even test it.

1. don't write your own address parser, use the one in camel.
2. what if the name is NULL? you don't handle this case. (same for if
the address is NULL)
3. You can't parse a string returned from summary_format_string() as
the result is meant for display purposes and may not be parsable as an
internet address.
4. applying this patch could potentially use a lot more memory. I'm
not sure that I'd go for that. (at *least* +16 bytes added to each
message-info just to keep track of 4 more strings (it's actually more
than that when using EPoolv - probably more like 32?), which, btw are
duplicates of a string that already exist in the same message-info and
so you add more memory there too, probably on average of 30 bytes of
duplication per message-info?).

this is actually puzzling, why is EPoolv on a per-MessageInfo? If it
was shared among MessageInfo's wouldn't it conserve more memory?
Comment 9 Jeffrey Stedfast 2002-05-28 18:11:59 UTC
> which, btw are duplicates of a string that already exist 
> in the same message-info and so you add more memory there too,
> probably on average of 30 bytes of duplication per message-info?).

reworded for correctness:

which, btw are substrings of strings that already exist in the same
message-info strcuture and so you add more memory there too,
probably on average of +30 bytes of duplication per address?).
Comment 10 Christian Kreibich 2002-05-28 18:53:51 UTC
Hi Jeff,

thanks for your comments. I wasn't aware camel had an address parser,
and you're right about the NULL returns -- they simply haven't
happened in my testing yet. Sorry about that.

Reg. 3): may I ask where can I get an address from instead?

Reg. 4): I'm aware of that. How would you go about doing this instead?
The way I understand the code I need to store the name and address
strings somewhere before I can return them from ml_tree_value_at
(message-list-c)?

Reg EPoolv -- I was wondering about this too, but thought someone must
have had a good reason for putting it per-MessageInfo.

I just learned that I won't have much time for updating this patch
over the next two weeks or so, so you're welcome to delete this patch
for now until I or someone else comes up with a better version.

Regards,
Christian.

Comment 11 Jeffrey Stedfast 2002-05-28 19:27:20 UTC
For #3, you can get the raw header value by using header_raw_find()

I should have given you an example of how to do #1 I guess:

CamelInternetAddress *ia;
const char *name, *addr;

ia = camel_internet_address_new ();
camel_address_decode (CAMEL_ADDRESS (ia), header_raw_find (&h, "To",
NULL));
camel_internet_address_get (ia, 0, &name, &addr);

if course, you might want to do error checking on
camel_address_decode(); and instead of just getting the first address
(0), you'd want to get each and every address by looping and I guess
concat them together into a single string?

ah, now that's another problem with your patch. It doesn't work if you
get messages to multiple recipients. Nor does it work if From:
contains more than a single address (which it is legally allowed to do
btw).

as far as #4, well - I'm not sure. Nothing really "wrong" with the way
you did it I guess, it's just more wasted space. Unfortunately, as you
mentioned, ETable needs a const char * to be returned in the
get_value_at() callback (or whatever it's called, I forget) and so
parsing it there and returning a g_strdup'd value will just leak it.
Not to mention parsing the string everytime ETable decides that it
needs the value (which is everytime it redraws itself for whatever
reason) will be awefully slow, so we'd need some place to cache the
results so that we only ever parsed them once. This could probably
actually be done in the mailer by adding a cache to the MessageList
object and using the raw CamelMessageInfo strings as the keys.

Of course, at this point - we're back to square one as far as
duplicatiing strings again and so we're no better off than if we
cached them on the CamelMessageInfo instead.

If the EPoolv was global (or at least shared among all MessageInfo's
on a given CamelStore?) then we'd greatly minimize the amount of
memory wasted by duplicate strings (we'd still use a bit more than if
we didn't cache the parsed addresses but at least it wouldn't be as
bad).

Actually...no we wouldn't. Now I see the problem. Since the from/to/cc
strings are strings containing multiple addresses, the order in which
those addresses are listed greatly reduces the liklihood that strings
will be identical (which is what EPoolv is counting on).

*sigh*

It's just not worth doing this I don't think.
Comment 12 Christian Kreibich 2002-05-28 20:10:18 UTC
Hehehe ... Jeff, you know, I thought this would be a simple little
hack to get more familiar with Evo's code -- looks like I was wrong
:o) Thanks for your detailed comments, they're much appreciated.
Comment 13 Jeffrey Stedfast 2002-05-28 20:18:06 UTC
yea, I would have thought this would have been easier too :\

btw, I just had a friend turn off EPoolv in his build (he's got a ton
of mail) to see what memory usage would be like and it doubled over
what was being used with EPoolv so EPoolv must be doing it's job even
so.

73 Meg (w/ EPoolv) to 141 Meg (w/o EPoolv)
Comment 14 Jeffrey Stedfast 2002-08-08 22:21:03 UTC
since I'm going through mail marked as important and I notice that I
never updated this bug report about my findings of EPoolv, turns otu
that each EPoolv structure shares a global string pool, which is why
it works.
Comment 15 André Klapper 2004-04-05 13:03:56 UTC
could be a dup of 29384, not totally sure though...
Comment 16 André Klapper 2004-04-14 13:44:07 UTC
*** bug 236285 has been marked as a duplicate of this bug. ***
Comment 17 Jeffrey Stedfast 2004-06-11 19:55:15 UTC
works in 1.5 afaict
Comment 18 Jeffrey Stedfast 2004-06-11 19:56:50 UTC
oops, wrong window.
Comment 19 André Klapper 2004-07-27 14:10:30 UTC
still valid in evolution1.5-1.5.90.0.200407191630-0.snap.ximian.8.1.
Comment 20 Calum Benson 2005-07-28 10:38:53 UTC
Apologies for any spam... cc'ing usability-maint on all Evolution usability
bugs. Filter on EVO-USABILITY-SPAM to ignore.
Comment 21 André Klapper 2005-09-06 07:12:55 UTC
*** Bug 315318 has been marked as a duplicate of this bug. ***
Comment 22 André Klapper 2005-10-06 11:43:20 UTC
*** Bug 317877 has been marked as a duplicate of this bug. ***
Comment 23 Karsten Bräckelmann 2005-11-22 17:51:47 UTC
Proposal (as discussed on IRC the other day):

* Have a new column for the list, that displays the real name only, if
  available (similar to Date vs. Received).

* Display the entire From (real name and email address) with a tooltip.
Comment 24 André Klapper 2006-01-11 10:18:53 UTC
rephrasing summary
Comment 25 André Klapper 2006-01-20 14:10:51 UTC
*** Bug 327768 has been marked as a duplicate of this bug. ***
Comment 26 André Klapper 2006-05-12 18:15:23 UTC
updating patch status as commented
Comment 27 André Klapper 2008-01-30 02:05:58 UTC
*** Bug 512964 has been marked as a duplicate of this bug. ***
Comment 28 Matthew Barnes 2008-03-11 00:37:24 UTC
Bumping version to a stable release.
Comment 29 André Klapper 2012-02-14 10:46:04 UTC
*** Bug 509808 has been marked as a duplicate of this bug. ***
Comment 30 André Klapper 2012-02-14 10:52:39 UTC
A "Sender" column has been available for a while which provides this functionality - you can use it instead of the "From" column. 
Closing as OBSOLETE / FIXED.