Re: [Evolution-hackers] IM entry fields patch

[Chris Toshok <toshok ximian com>]

On Tue, 2003-11-25 at 00:41, Christian Hammond wrote:
> On Sun, Nov 23, 2003 at 02:56:29PM -0800, Christian Hammond wrote:
> > Hello.
> > 
> > I'm Christian Hammond, from the Gaim project. I'm working on one of
> > the gaim<->evolution bounties, and have a couple of patches for your
> > review and, hopefully, acceptance into CVS.
> > 
> > The first patch adds the ability to set data types of
> > E_CONTACT_FIELD_TYPE_LIST in evolution-data-server.
> > 
> > The second patch adds fields to the Contact Editor window in evolution
> > so that a person's AIM, ICQ, Yahoo, MSN, and Jabber accounts can be
> > set.
> > 
> > Let me know if you'd like me to make any changes.
> > 
> > Thank you.
> > 
> > Christian
> 
> (You may get this e-mail twice. The attached files went over the
> message limit, so I've uploaded them and will post a link. Sorry for
> the inconvenience.)
> 
> I updated things a bit. First off, the patch to evolution-data-server
> had a bug where list types could not be unset. That's fixed now.
> 
> Second, I replaced the UI for adding a contact's instant messaging
> accounts to be closer to what Nat and I discussed. Whether I got it
> exactly how he was describing, I don't know, but it's easy to use and
> it works.
> 
> See http://www.chipx86.com/evolution_im_3.png for an example.

This is pretty close to what everyone seems to have independently
decided would be the best layout :)  I think it'd look a bit tighter
with the add/edit/remove buttons over on the right hand side of the
table, though.  What do you think?

> The patches and tarball for evolution (unpack in the evolution
> directory) are here:
> 
> http://www.chipx86.com/patches/evolution/eds-list-type-20031124-1609.diff

This looks good and should go in.  I've been thinking, though, that
LIST_FIELD might not be the best way to represent the im screen names,
since it lock you into 1 set of parameters per list.  What I mean is,
EContact won't let you do:

X-AIM;TYPE=WORK:toshokwork
X-AIM;TYPE=HOME:toshokhome

Instead you're forced to do:

X-AIM:toshokwork;toshokhome

with no metadata per screen name.

so I'm thinking of changing the im fields to be MULTI_ELEM_STR_FIELD,
and add synthetic E_CONTACT_IM_<protocol>_HOME and
E_CONTACT_IM_<protocol>_WORK fields to get the different sublists, and
maybe HOME_1, HOME_1, and HOME_3 (same with WORK_) for the individual
items, ala the EMAIL fields.

how's this sound?  it shouldn't affect your code too much - an
additional field in the table/editor that lists whether or not it's a
home or work screen name, and a little additional code.

Chris