Fix sorting of details (sort_fields_helper)
Right (vcard) types for postal addresses
Better handling of writable properties, (notes, etc)
Error if add detail after removing all details (#653822)
Edit full name with no writable persona
Support editing of more fields: postal address, chat

Implement delete contact => Hmm, how to do this for telepathy ones?
Make "address copied to clipboard" window-osd like notification (#653823)
Save changes when a note is edited => linking API bad (#653728)
Update notes handling when we got a way to find writable stores/fields and which is the main store
Sort details in a more stable order (#652644)
Handle TYPES for URIs => 653623
Add more custom URI regexps
Change (via phone) text to icons (#653824)
Add title, company, etc to card => folks (#653619)
Need nicer fallback avatar
Fix the type fields for postal addresses => eds backend (#638281)
Load avatars async
In editing mode, need a better way to disabigue the different personas
In editing mode, persona source string is larger than image => bad clipping
In editing mode, handle the case where whole personas, or just single details are read-only
Implement birthday detail
Implement Link/Unlink contact
Implement Send contact
Implement application menu
Implement avatar picker


--------------------


folks issues:

"types" for e.g. phone, email, postal addres. Want translated display name for the standard stuff & custom names

company, title

nice display names for chats. maybe per-chat aliases

notes

nice display for different web services (flickr stream, twitter, etc)

other things: skype,

how is online status merged (should be max)


Log:
<alex> rgs: ping?
<alex> treitter: ping?
<treitter> alex: pong
<treitter> sjoerd: nice
<-- nielsle has quit (Ping timeout: 600 seconds)
<alex> treitter: I'd like to chat some with you and rgs about folks stuff in gnome-contacts
<alex> treitter: I've got the egs branch running here, and the readonly parts of the contacts app are starting to shape up.
<treitter> nice to hear
<alex> rgs: are you around?
<treitter> alex: it might be best to schedule a meeting for tomorrow if you've got time
<treitter> that way, I would have time to review the latest e-d-s backend changes
<treitter> and hopefully rgs will be available
<alex> Unfortunately I need to take care of a sick kid tomorrow. In fact, i'm unlikely to have much time the whole rest of the week
<treitter> alex: OK, I've got a little time now
<alex> But i said so to rgs earlier today, so I was hoping he'd be around now
<alex> Its a bit late, but kids don't fall to sleep on a schedule apparently
<treitter> yeah
* sjoerd just prodded rgs
<alex> I guess we can start without him. Maybe he'll show up
<-- Maiku has quit (Ping timeout: 600 seconds)
<alex> treitter: Do you have the edg backend built?
* rgs is back
<alex> eds i mean
<alex> Can you guys build the gnome-contacts gnome git module so we can discuss around it?
<alex> Should be a fast build
<treitter> sure, building
<rgs> alex: i hope to get avatars working by today (a patch to e-d-s is blocking that, should get reviewed soon)
<alex> Anyway, while building you could look at http://imgpaste.com/i/yciav.png which is the latest mockups
<alex> Lets start with the left side
<alex> It shows a list of all individuals
* rgs looks
<alex> It typically shows the full name, sorted by first name or surname
<alex> A couple of issues with this
<alex> First of all, its not at all uncommon for contacts to not actually have a full name
<alex> telepathy contacts generally only set alias
<alex> and for instance google contacts adds a contact for everyone you send mail to, and these often just have the email address, no name at all
<alex> So, i had to make my own class (Contacts.Contact) that add stuff to Folks.Individual. For instance the display name
<alex> This tries hard to give *some* kind of name for these
<alex> Rather than displaying empty stings in the list
<treitter> I think applications should just use fallbacks as they'd prefer
<sjoerd> having every applicaiton implement that by themselves sounds bad
<treitter> we've got the display name, which probably works for most applications
<sjoerd> would give a very inconsistent experience
<alex> It would be nice if there was some standard way to do this, as this will mean we show the same in all apps
<treitter> I don't think we fall back to IDs like email addresses, but we probably should
<alex> There is a display name? where?
<treitter> sorry, I guess we haven't implemented that yet. I'd be happy to add that
<alex> Yeah, i would like that
<rgs> we could do display_name = full_name || alias || nickname || email_address || im_id ?
<treitter> with the various related projects I've worked on, it can be hard to remember the state of implementation of things discussed
<treitter> sure
<treitter> Persona has display_id, but that's different
<alex> The second issue with that is that the display name i need can be sorted by surname
<alex> rgs: thats basically what i have
<alex> Display name by surname can be implemented by using the structured name
<treitter> alex: I'm trying to think of what we did in Maemo 5 - I think we silently sorted based on the stored structured name
<treitter> and kept the same display name
* rgs is taking note of agreed actions
<alex> But, that means we need to be able to get a structured name if there is none, or guarantee that there is one
<treitter> structured names are frequently unpopulated of course
<alex> eds has an api do do this
<alex> Which i was planning to use
<alex> but maybe it would be nice to wrap it in folks
<treitter> yeah, I had a look at that. I was hoping we wouldn't need to implement that in Folks, but it could be worthwhile
<alex> ENameWestern *e_name_western_parse (const gchar   *full_name);
<rgs> we guarantee that there is a structured name in an individual, and we have an is_empty () method
<alex> rgs: I don't mean that we guarantee that its non-null
<treitter> alex: note that it only really works for Western names, of course
<alex> rgs: but that we can create one from the full name, if needed
<alex> treitter: yes, as should be obvious by the name
<alex> treitter: I don't see any better approach though...
--> nielsle (~nielsle@4135136-cl69.boa.fiberby.dk) has joined #empathy
<alex> If there is no structured name and you're sorting by surname
<alex> ....
<treitter> alex: trying to parse a structured name from a flat string makes me a bit queasy :)
<alex> treitter: I'm not saying we should do it automatically really
<treitter> though the implementation in e-d-s is very intricate. I haven't checked how well it works in reality
<alex> treitter: but, it would be nice to at least have some way to get a StrucutredName guessed from a string (i.e. wrap the eds function)
<alex> treitter: I will need it at least in two ways
<alex> 1) To guess a surname when sorting by surname
<alex> 2) To split up the full name when clicking edit details on a full name that has no previous structured name
<alex> I can of course call eds and generate a StructuredName from ENameWestern
<alex> But, perhaps it would be nice to have that in folks so other apps do it the same way
<alex> shared bugfixing and whatnot
<alex> Anyway
<alex> Just an idea
<treitter> right
<alex> Continuing with the left hand side
<treitter> just a sec
<alex> ok?
<treitter> We can implement e-d-s' name parsing if it's really useful
<alex> Or just call it?
<alex> I guess you want the eds dep optional?
<treitter> we could - I don't really want to add hard deps quite like that
<treitter> we're going to make e-d-s the default primary backend
<treitter> so it will effectively be a hard dep
<alex> Its not a huge amount of code to copy
<treitter> I guess I'm just being a little pedantic about the way the deps work out
<alex> I can call eds manually for now to test how it works out
<treitter> I think there might be some license weirdness too - maybe it was LGPL 2.0-only? I'll double-check later
<treitter> OK
<alex> Then we can plan to possibly import it to folks later
<treitter> it would be good to prototype and try it out for a while
<treitter> yeah
<alex> So, next thing in the list is the im status
<alex> How exactly is it merged into the individual?
<treitter> personally, I only care about structured names if they come directly from the person
<treitter> but that may just be me
<treitter> anyway, moving on
<alex> Like, if some individual has multiple im presence personas
<treitter> presence is just a max() function
<treitter> the Individual just has the most-online presence amongst its PErsonas
<alex> Ok, so if any of the personas is availible i like to show that
<treitter> yeah
<alex> is the status ordered so that max works out+
<alex> ?
<treitter> it currently sets the message as the one matching the "winning" status
<alex> or was max() just a handwavy description, not an actual math.max()
<treitter> yeah, I'm just speaking broadly
<alex> cool. That sounds good
<treitter> so one odd bit there is that it's the "first found" message
<treitter> so if an Individual has 2 available personas, the message it ends up with is a little unstable
<treitter> not sure if that would ever matter
<alex> Not for me
<treitter> me neither
<alex> In the list i just show the icon
<alex> and in the detailed version the icon is per persona, with the message as hover over
<treitter> in practice, I've noticed that presence really collapses to ({available, offline}, "")
<treitter> (people set meaningless away messages for weeks or months at a time; many people set their status to permanently away, etc.)
<alex> yeah
<alex> So, another thing in the list
<alex> is that it filters
<alex> type anything in the entry and it filters by that
<sjoerd> treitter: that depends a lot on specific people/what they're used to though
<alex> I actually construct a string from a bunch of string based fields so that i can easily filter by string with a strstr()
<alex> Maybe we could have a matches_string() call on the individual?
<alex> Not sure, since you might want to match on different fields
<treitter> sjoerd: yeah. We'll do the most logical thing anyway
<treitter> assuming a world where there are meaningful values for those
<alex> Assume a spherical cow
<treitter> exactly
<treitter> alex: we're planning to add search-based retrieval for Personas
<treitter> so there should end up being some overlap there
<alex> treitter: Search and filter are not quite the same though
<alex> We want to support both, but we're not sure quite how the UI will look
<treitter> right
<alex> i.e. search would be to look up in an external db, like ldap, or a national phone nr database
<treitter> right
<alex> Whereas filtering is much faster, and on a wider number of fields
<alex> done for each character typed, etc
<alex> (try it, it works in gnome-contacts)
<alex> Even with the first-letter index thing, got some custom treeview model thing there
<treitter> I think with matches_string() we'd want some way to say which fields we care about
<treitter> the same way we'll do that for search
<alex> Its possible other people will need that, yeah, so that will affect the API
<treitter> and some matching shouldn't be a simple substring match (eg, phone number matching)
<alex> I'll not have such a complex query editor or language for filtering though, just pure substring match
<treitter> OK
<alex> You're not gonna remember a phone nr and type it in to find out the users name...
<alex> At least its just not the usecase the filtering was done fore
<treitter> yeah, probably not in this case
<alex> It should however filter by things like company, nickname, notes, etc
<alex> I basically split the filter string by whitespace and return all that individual thats matches all substrings (in some, possibly different fields)
<alex> Ok, over to the right hand side
<treitter> should we create a utility class for matching? It could have the set of fields to match upon and the search string.
<alex> For the top, i need Folks.Role implemented in the eds backend
<treitter> the class could just have a simple matches(Individual i) function
<alex> treitter: As long as there is some way to match all string fields without having to exhausitvely list them
<rgs> alex: i'll get to implement Folks.Role soon
<treitter> yeah, we could have them be a bit field and include an _ALL 0xffff... entry
<treitter> we'll need a class like that for searching anyhow
<alex> treitter: One reason i want this as a folks operation is that I'd like to have the implementation not actually strdup each field during a match op
<alex> treitter: And thats easier inside folks
<treitter> alex: right
<alex> Ok, next on the right side is the type fields
<alex> These have two issues
<alex> First, we want to have some consistent handling of these between backends
<alex> Secondly, for some set of generic (non-custom) types I really want to have translated nice looking names
<alex> i.e. not "mobile_phone", but _("Mobile")
<alex> I guess the two are related, because if there was some canonical list that backends used i could map those to a translated string
<alex> But i guess we also want the type to be able to be a custom value?
<alex> For instance google contacts allows that
<treitter> alex: in terms of vCard, contexts usually show up like TEL:TYPE=home,mobile;+123568
<treitter> there's a set of "well-known" types (home, work, mobile, fax, etc.)
--> elleuca (~luca@ppp-168-236.25-151.libero.it) has joined #empathy
<treitter> some of those are field-specific (like fax)
<alex> The current eds backend gives me things like "home_phone"
<treitter> but {home, work, other} (once set to a consistent case) are the main ones for all fields
<alex> And "email_1" or "email_2" for email
<treitter> rgs: we should fix that ^
<treitter> rgs: that's coming directly from EContact, right?
<alex> treitter: It would be easier to fix if there was a documented generic set :)
<rgs> treitter: yup
<treitter> we should really use the EVCard API when dealing with EContacts
<alex> treitter: So, these are expected to be vcard types then?
<treitter> alex: yeah, that's what I've got in mind
<treitter> EContact has historically been a pain for various reasons
<treitter> and supporting generic fields and properly handling vCard attribute params in particular are hard with EContact
<treitter> alex: we'll add some notes in the documentation about which field values are the most common/recommended
<alex> Ok, so it can be multiple values then ("home" + "fax", rather than "home_fax")
<treitter> I don't think the vCard RFC provides a canonical list, but it does use those in its examples, so they've been carried on
<treitter> alex: yeah, that's how it works in vCard
<alex> and i can look at the vcard rfcs for common ones and map these to translated nice names
<treitter> sure
<alex> unknown names can be shown as-is?
--> alsuren (~alsuren@184.163.125.218) has joined #empathy
<treitter> there can be arbitrary values too
<alex> To handle the "custom type"
<rgs> alex: better fallback to "Phone" or "Email" than whatever comes from the backend i'd say
<rgs> which would be _()-able
<alex> rgs: I already show "Phone" as a header
<alex> Its like
<alex>    Phone
<alex>    Home  +46-8-xxx
<alex>   Work   +46-23354
<treitter> alex: in practice I would guess most programs would use English if they set any arbitrary values (I doubt any programs have the user set this value themselves)
<treitter> but we might as well pass them through unmodified
<alex> treitter: try gmail contacts
<alex> treitter: if you set "custom" in the type for e.g. an email address you can type whatever there
<treitter> cool
<alex> treitter: I would typically use swedish for it...
<alex> no idea how its visible in the vcard though
<treitter> I'm wrong then :)
<alex> Its quite useful
<treitter> I would imagine it's copied in directly
<alex> Types can be things like "at parents" or "country house"
<treitter> yeah
<alex> for phone nrs
<alex> I'll do some testing and see what google produces so we make sure to handle that
<treitter> sure
<alex> For the IM ids i'd like the type field to say something useful raher than "jabber"
<alex> I'm not sure what the best way to do this is
<alex> Actually, i'm not sure i'm even displaying the right value for these
<alex> Right now it is like: jabber: -54352134@chat.facebook.com
<alex> Is that even useful to display?
<alex> It also gives IM status as icon + message as tooltip, and clicking lets you initiate a chat
<sjoerd> for facebook it's not
<alex> But it probably should say things like
<sjoerd> for most normal jabber addresses it can be
<alex> Facebook: Alex Larsson
<sjoerd> but you normally want to show the alias
<alex> or
<alex> GTalk: alexl@gmail.com
<alex> sjoerd: Yeah, for facebook
<alex> sjoerd: but maybe not for e.g. gmail...
<alex> Its tricky stuff
<sjoerd> on a telepathy level, it should just grab teh alias and that should always give you the right string to display
<treitter> I think Facebook is the one exception
<alex> sjoerd: Its not really right with the alias for e.g. gtalk though
<sjoerd> ?
<alex> sjoerd: because for gtalk the alias is very typically the full name, and we already show that
<alex> sjoerd: but showing the @gmail.com thing might be useful
<sjoerd> does the user really care about the protocol identifiers?
<sjoerd> i guess you could always show alias <protocol identifier>
<sjoerd> like you'd do for e-mail
<alex> I'd like to never show a facebook id, as they look utter crap though
<alex> Also, i dunno how useful it it to show the alias if its identical to the full name we already show
<sjoerd> then you need per protocol heuristics indeed
<treitter> sjoerd: I don't think users care about identifiers most of the time, but this is for the detailed view
<alex> Also, we have to show *something*
<treitter> in which case they're what we're after
<alex> And the full name is already visible in large bold text
<alex> so showing it again is kinda weird
<alex> Anyway, i'll have to do this heuristically
<alex> but, is there some folks/telepathy way to get the "highlevel" protocol type
<alex> like facebook, not jabber
<alex> without having to parse the id string and guess
<alex> rgs: Also, more things i want from the eds backend: urls, notes, birthday
<treitter> not yet
<treitter> we could add that
<alex> treitter: even via the folks-telepathy apis?
<alex> The urls need to get custom treatments for display too
--> Saviq_phone_afk (~Saviq@sawicz.net) has joined #empathy
<alex> Like, if its a twitter account, just show the Twitter: username
<alex> But i can handle that manually
<treitter> alex: you could figure it out from the TpContact, but that's a hassle
--> alsuren_ (~alsuren@184.163.125.218) has joined #empathy
--> jonnnylamb (~jonny@jonnylamb.com) has joined #empathy
<alex> treitter: easier to just look at the @gmail.com part (Etc)?
--> pochu_ (~emilio@pasanda.collabora.co.uk) has joined #empathy
--> inz_ (inz@idle.ircing.org) has joined #empathy
<treitter> easier once Folks adds a property for it :)
--> bigon_ (bigon@anor.bigon.be) has joined #empathy
<alex> Hehe
<alex> Also, the current eds backend gives me the full name string again in the alias property
<alex> i'd rather it was empty
<alex> since i don't want to show the name twice
<treitter> alex: you could work out "twitter" from the Persona.web_service_addresses property
<treitter> it would contain {"twitter": "username}
<alex> Actually, what is an alias? Is it something that is expected to be set from any source, or just for IM style sources?
<alex> If the later, then it wouldn't need to be shown at all for the individual, just for the per-chat persona item
<alex> treitter: Hmm, but how is that stored in eds? it just has a list of urls, no?
--> jonner` (~jonner@pasanda.collabora.co.uk) has joined #empathy
<treitter> alex: the idea is for alias to be user-set and nickname to be contact-set
<alex> Hmm
<treitter> full name could be either user-set or contact-set (but the user should always be able to override it)
<alex> So, if i call someone Alex "the dude" Larsson
<-- inz has quit (Ping timeout: 600 seconds)
<alex> Then that would be an alias?
<-- stefw has quit (Ping timeout: 600 seconds)
<treitter> yeah
<alex> (i.e. user-set)
<alex> Thats what i would call a nickname in the ui
--> cassidy (~cassidy@pasanda.collabora.co.uk) has joined #empathy
<treitter> it's a little ambiguous in Telepathy contacts, since we're using the contact alias (which is likely contact-set, but could be user-set, depending on the protocol and server)
--> ionte (~jonatan@c-f165e155.139-1-64736c11.cust.bredbandsbolaget.se) has joined #empathy
<treitter> though there's a Telepathy draft API for making the distinction clear
<alex> Also, i'd like to just show such a nickname when its specifically set
<alex> not just when someone has a IM persona that has an alias
--> harrykar (~harrykar@host28-172-dynamic.52-79-r.retail.telecomitalia.it) has joined #empathy
<alex> Because i'm showing it like 'Alex "the dude" Larsson' in the ui
<treitter> I think most UIs should use the alias if set, falling back to the nickname (if set)
<rgs> alex: i'd implement that interface when we get write support, as noted in the bug report
<treitter> since the user's value for something should override the contact in general
<alex> treitter: Thats not what i want though
<alex> treitter: I want a field that is generally not set for most users
<alex> treitter: except if they have a real life nickname
<alex> treitter: obviously this is appart from what we show on the IM detail lines
--> phako (~phako@jensge.org) has joined #empathy
<treitter> yeah
<alex> This is for the "business card" style thing at the top
<treitter> right
<alex> I want it to be:
<alex> [photo] Alexander Larsson
<alex> [photo] "The dude"
<alex> [photo] Developer, Red Hat, inc
<-- phi1rene (~phi1rene@208.124.228.195) has left #empathy
--- magcius_ is now known as magcius
<alex> And, showing the Alias inherited from some IM persona there is not what i want
<treitter> we don't have it well-established that the nickname is meant to be used that way
<treitter> so you want the second line to be both user- and contact-settable?
<treitter> there's Telepathy API to provide the Nickname field if the protocol provides it (I believe)
<treitter> but it's rarely filled in (then again, real-life nicknames are rare)
<treitter> and we will fill that into the nickname field on the Persona when we support it
<alex> yeah
<treitter> so you could just use the Individual.nickname directly for that UI
<alex> its just that I can't show it if its always (in the common case of no real-life nickname) is duplicating some other field like IM name
<treitter> we could change our API to make the nickname user-settable, I guess. In most cases, I would still have applications set the alias though. It only makes sense for the nickname to be user-settable in a full address book application (not Empathy)
<treitter> alex: right. We should clear that up - anywhere that's happening in the e-d-s backend is a bug
<treitter> rgs: ^
<alex> treitter: nickname exists in vcard, right? Isn't that meant to be used like that
<treitter> the name fields should only be populated if the original source populates them, not just because it's convenient to copy it over
<treitter> alex: yeah
<treitter> alex: anything else?
<rgs> treitter: whats would be a bug in the e-d-s backend?
<rgs> *what
<alex> Another thing i'd complained about before is the way we get images (by filename)
<alex> I would like to have a stream based api
<treitter> rgs: if we're duplicating various name values into others (eg, copying the alias into the full name)
<rgs> treitter: that was fixed today
<alex> rgs: for nickname yes, but not alias
<rgs> alex: alias is not implemented
<treitter> alex: yeah, we've got bgo#650414
<alex> oh
<rgs> alex: for e-d-s (since there is no write support yet)
<rgs> so you guys are sure you wanna make nickname a writeable property?
<rgs> i pretty much liked the definition of a) nickname as what comes from the source b) alias is set by the user and pushed back
<-- nielsle has quit (Ex-Chat)
--> seiflotfy_ (~seiflotfy@g230051253.adsl.alicedsl.de) has joined #empathy
<treitter> I do prefer that definition
<treitter> if we keep it, we will have a little weirdness with e-d-s, though, since it treats nickname as a read/write property
<-- seiflotfy has quit (Ping timeout: 600 seconds)
<alex> Yeah, or any other vcard type source
<alex> And its not what you expect from an address book style UI

<rgs> well, for e-d-s i'd treat the nickname property as the alias and maybe have no nickname? Or how would you map that? (sorry irc went crazy and lost track of part of the conversation)
<alex> Well, the problem i have is not really the exact user-set or contact-set thing
<alex> Its rather, can i use this field to mean the vcard style nickname (i.e. mostly unset, or real-life nickname)
<alex> I can't use the alias field as its automatically set to something else for all IM style personas
<alex> which will be merged into the individual
<-- ioni has quit (Remote closed the connection)
<treitter> I think the nickname field (from all of our sources) should fit your requirements (as long as we don't accidentally copy anything into it, like the alias)
<treitter> alex: do you require it be user-settable?
<alex> Yeah
<treitter> I guess I'm OK with making it user-settable. If they want to mangle their data, that's up to them
<treitter> alex: as long as we can set the alias in gnome-contacts
<alex> I mean, its certainly settable in e.g. google contacts
<treitter> though I doubt most users would understand the difference between the fields if you put them side-by-side
<alex> I don
<alex> I don't really understand what use the alias field is
<alex> It'll be shown for the chat details
<alex> But, I don't know what the merged one is useful for
<treitter> it makes more sense if you don't have a Full Name field (like we didn't until not-too-long ago)
<treitter> that's what I (and I think most people) use the alias for
<alex> Sure, its a useful fallback for fullname
<alex> I'll be using it for that
<alex> But not if you have a full name
--> ioni (~wonder@86.106.92.158) has joined #empathy
<-- ioni has quit (Leaving)
<treitter> yeah
<treitter> anything else? I haven't had lunch yet, and it's after 2 here :)
<alex> no, gotta sleep now :)
<treitter> OK, cool
<treitter> we'll follow-up on the points you brought up

-------------
finish editing
order personas in edit header

Make field sort be by TYPE
Don't show *all* InitData in type combo dropdown if never used (ttys anyone?)
HOME/WORK are duplicated in phone typeset, should not be visible
Typing an existing custom label as custom duplicates it in the combo




colors on presence in list view
