New design:

Add to my contacts button

online/readonly:
  on editable store change -> redo contact pane
  more editable checks (add/delete/avatar/name/etc)
  For readonly stores folks sets trust level partial, doesn't that break links?
  
Show all contacts option?

Support password dialog on eds?

high contrast theme - labels on contact pane not visible when prelighted

list not via treeview (seit working on this?)
qr codes?

show contact from shell no workie -> seems to work, needs more test

--
suggestion: click on suggestion to show that contact...

Overlap list if not enough horizontal space

Nicer detection of what window key events should go to search (see treeview hack)
notifications cover up the border line of the toolbar

Punt:
Add separators between first letters in ContactsView
no toolbar for search entry, but new edit look
Implement import
Wide screen mode
Add photo stream
Add recent messages


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

delete contacts with telepathy personas. How?
abstract out the "first line of business card", plug in title, company, later social stuff
Show nickname in details as well (if not in card)
Support editing of more fields: chat, nickname, alias (readonly)
Implement Link/Unlink contact (See 653728 below for folks issue)
clean up css
Better handling of writable properties, (notes, etc)
Sort details in a more stable order (#652644) (Contact.sort_fields)
Add more custom URI regexps
Load avatars async
Add title, company, etc to card => folks eds backend
Implement birthday detail
When edited contact is renamed, scroll it to view on the left
Notes: Don't add a FakePersona if there is a persona with a writeable notes property (see #657789 for folks issue though)
Display didn't find dialog when not finding commandline specified contact, needs quiescent

Possibly post 3.2:
Allow selecting subset of image when picking avatar
When loading custom avatar, pass in a reference to the in-memory pixbuf rather than having folks load it again by uri

----------

Folks:
Can't delete eds google contacts
Bug 657783 - Prefer data from primary store when picking Individual values
  also: Can't pick avatar to override gtalk avatar
auto-link gtalk & gcontact (657142)
Can't edit avatars/notes on google: #657789 (folks)
pick up default eds backend (657141)
Bug 653728 - linking APIs need work (worked around for now)
Merging google contacts and local contacts doesn't work (not trusted, folks bug)

Desktop:
some place to set the google contacts account as the default eds store


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

Post 3.2:
Implement Send contact
Implement application menu
Make "address copied to clipboard" window-osd like notification (#653823)
Handle TYPES for URIs => 653623












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
