Re: [Evolution-hackers] Old thoughts on the "self" contact

[Chris Toshok <toshok ximian com>]

On Thu, 2004-02-12 at 20:40, Chris Toshok wrote:
> Back in November, Ettore, JPR, and I talked about the self entry.  In an
> effort to let everyone know what we talked about (and to see what we
> might be able to get in to the UI for 2.0), here's the list.  I'll
> respond to this mail with some status about what we've implemented, etc.
> 
> Chris
> 
> ---
> 
> 
>       * Operations possible on the "me" vcard:
>               * The "me" vcard can't be deleted.

This would be pretty easy - it'll have to be handled in libedatabook, as
we want to protect it from all apps, not just evolution.  We can use
e_book_is_self and return PERMISSION_DENIED if the rv is TRUE.  simple.

>               * The user can add, remove or modify email addresses in
>                 the "me" vcard.

This was just to clarify that even though it's populated when you make
changes to your mail account list, the user can still edit the email
addresses from the contact editor.

This also brings up another failing in the contact editor dialog.  It
only shows 3 email addresses, but I have way more email accounts
configured just to get the email addresses than that.

>       * When user configures an email account:
>               * If there is no "me" vcard, it adds one with name and
>                 email address.
>               * If there is a "me" vcard, it adds the email address.
>               * If there is a vcard with the same email address, we ask
>                 the user if he wants to use that as his "me" account
>                 after showing its contents.
> 
>       * When user changes email account:
>               * It updates the "me" vcard accordingly.
>                 
>       * When user deletes email account:
>               * If the address is in the "me" vcard, we ask the user if
>                 he wants to remove it.
> 
>       * We need settings:
>               * Whether the "me" vcard needs to be sent along with the
>                 email message.
>               * Whether to send the photo along with the "me" account
>                 (default to off).
>                       * The setting is grayed out if there is no picture
>                         in the "me" account.
>                       * If the user sets a photo in the "me" account, we
>                         ask him whether he wants to send the picture or
>                         not.
> 
>       * When we send the "me" vcard, we strip out all the email
>         addresses that are not the one we are sending mail from.

This is a privacy thing.  You don't want your boss knowing you sometimes
send mail as "l33thax0r hacktheplanet net" when you work at a bank or
something.

Of course we could go more fine grained than that, and allow the user
(with checkboxes or something) to choose which parts of the contact are
sent along, but that seems like wayyyy too much work.

Most of the work for the above bullets is in the mailer, and it's mostly
UI work that imo should be pushed out.

>       * Setting:
>               * GConf key with URI + UID.

Right now we assume the contact is in the local addressbook, and we just
store a UID.

>               * User can change it from either the contact editor or the
>                 main addressbook UI.  (Probably it wants confirmation
>                 too.)

This is very little work.  A menu item or two, a popup menu entry, and a
tiny bit of code in each place.

>               * User can't select an LDAP card for the "me" account.

This is mostly because we don't have caching support for ldap, so
disconnected operations wouldn't be able to locate the self contact.

>       * We need an icon to identify the vcard that is "me".

This would only need to show up in the minicard view.  I'm not sure we'd
want to add a column to the table view for an icon that will be present
in zero or one row.  Maybe a special color for that one row?  can
e-table/gtktreeview do that?

>       * We need an API to get the "me" entry.
>               * e_book_get_self()

We have this, as well as a corresponding e_book_set_self api.  The
e_book_set_self api, though, is misleading in its current form.  It
takes an EBook argument, which isn't used.  We should at least make sure
it's the local addressbook and return an error if it isn't.

Chris