GNOME Bugzilla – Bug 225392
Add column "real name" to mail message list (sender name only without email address)
Last modified: 2012-02-14 10:52:39 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.
Created attachment 41246 [details] [review] the patch itself, created using cvs diff. Apply with -p1.
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
Created attachment 41247 [details] Screenshot of address-only display
Created attachment 41248 [details] Shot of the usual name-and-address mode
Created attachment 41249 [details] Shot of name-only mode
Anna, I've attached 3 shots to this report. Hope this helps, Christian.
Created attachment 41250 [details] Shot of the config dialog with new options
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?
> 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?).
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.
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.
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.
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)
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.
could be a dup of 29384, not totally sure though...
*** bug 236285 has been marked as a duplicate of this bug. ***
works in 1.5 afaict
oops, wrong window.
still valid in evolution1.5-1.5.90.0.200407191630-0.snap.ximian.8.1.
Apologies for any spam... cc'ing usability-maint on all Evolution usability bugs. Filter on EVO-USABILITY-SPAM to ignore.
*** Bug 315318 has been marked as a duplicate of this bug. ***
*** Bug 317877 has been marked as a duplicate of this bug. ***
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.
rephrasing summary
*** Bug 327768 has been marked as a duplicate of this bug. ***
updating patch status as commented
*** Bug 512964 has been marked as a duplicate of this bug. ***
Bumping version to a stable release.
*** Bug 509808 has been marked as a duplicate of this bug. ***
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.