Re: [evolution-patches] Patch for custom mail headers

[Not Zed <notzed ximian com>]

On Fri, 2003-11-28 at 06:09, Grahame Bowland wrote:
> Hi all
>
> I sent an older version of this to NotZed and fejj yesterday, but 
> haven't heard back - I'm being impatient :-) The patch does 
> seems to work, could I have some feedback?
Patience, I just got back from New York (read: >30 hours of flying and airports), and Jeff is taking thanksgiving off (some weird USA holiday) :)

> Config dialog screenshot: 
> http://grahame.angrygoats.net/images/custom-mail-headers.png
> Viewing a mail:
> http://grahame.angrygoats.net/images/custom-mail-headers-view.png
>
> Patch attached, it should apply to the current CVS version of 
> evolution.
Looks pretty sweet, just a few comments.

- First, it has to include relevent ChangeLog entries (use C-x 4 a in emacs while editing the function).
- With header_sanitize_name, is there any way to override the character input to the cell editor instead, so invalid characters can never be entered in the first place?  Note there can't be a ':' anywhere in the name, for example, not just not trailing.
- if you enter a duplicate, it gets reset to the previous value, losing what the user entered, which doesn't seem very friendly
- although the inline editing is nice, i wonder if it isn't better just using a popup, since no other config list works like this, and it isn't obvious the first time that this is how you edit them (all the others popup a window).  This would let you add popup boxes or status lines for duplicates etc (or better, the 'ok' button wouldn't be sensitised until you entered a non-null, non-duplicate).  also simplifies (removes) the 'new-header' logic.
- need to trigger a re-draw on the current view if the values change (no direct api for this, but just copy what the emf_*_set methods use).
- i know the bounty said to use a string list, but if we're going to add options like bold, it should probably be an xml blob, set on a single key (or even a string-list of xml blobs?).  Otherwise we're going to get multiple updates to the key when we re-draw on change, and its just cleaner than tracking multiple keys.

Some of these are UI related, but currently we have no UI technician, so i'm not sure what direction we should take.  Consistency with existing similar UI elements seems the key though.

 Michael