GNOME Bugzilla – Bug 460647
Support metacontacts
Last modified: 2010-08-27 12:17:59 UTC
Don't know why I hadn't filed this one yet. It's quite usual to have multiple contacts for only one person (because you have multiple accounts or because the person has multiple accounts, or both of those reasons). Metacontacts are really useful to make it easier to handle this.
We are planning to support that kind of thing using eds-sync. The idea of eds-sync is to get all contacts from all telepathy accounts and try to merge them into EDS using vcard fields. For example if you add a contact in evolution and set the Jabber and MSN vcard fields, eds-sync will see that msn and jabber contacts are the same than the evolution contact and will merge information from those accounts into one contact. Once that's working empathy should use that information to fill the contact list. That's not easy at all, but far better than stupid metacontact like in pidgin.
I don't use Evolution at all (GMail suits my needs better) and my Jabber/XMPP metacontact data is stored on the server. Can't see how eds helps here.
Stored on the server? Which server? You can't have a metacontact for a MSN + a Jabber contact representing the same real person at the moment.
I only use MSN/Gadu-Gadu/Tlen/ICQ through transports so metacontact data is stored on the appropriate XMPP server. That's tha only way for the configuration to follow me around between computers.
*** Bug 482553 has been marked as a duplicate of this bug. ***
What is the status of all of this? Are we still waiting for vcard support?
I think this bug should be discussed with Gnome Online Desktop project to store metacontact information in a centralised way. I don't have a clear idea yet of what needs to be done, can someone from GOD project help here?
*** Bug 460657 has been marked as a duplicate of this bug. ***
*** Bug 518690 has been marked as a duplicate of this bug. ***
We at the People project [1][2] are currently trying to define what should be meta contacts, done in the right way. Basically meta contacts as the users see it for now is just a folder were you put together different accounts for a single person entity. We could do much better. Among other things, People aims to provide a unique source of unique contact entities. That means that once you managed to reference the contact from your application, you have access to all the possible information associated (from Telepathy, Seahorse, Facebook, whatever). In the case of Empathy, the "account list" would vanish, being replaced by a real "people list". Meta contacts (and we actually need to find a proper term for what we want to achieve) are kind of complex and we need to define a way on how applications could request a Contact, that's why I ask some input here :) So, what are your thoughts on this? [1] https://launchpad.net/people-project/ [2] http://jprieur.wordpress.com/2008/03/28/people-a-contact-management-framework/
*** Bug 529954 has been marked as a duplicate of this bug. ***
*** Bug 536620 has been marked as a duplicate of this bug. ***
*** Bug 553482 has been marked as a duplicate of this bug. ***
*** Bug 565946 has been marked as a duplicate of this bug. ***
*** Bug 569422 has been marked as a duplicate of this bug. ***
*** Bug 576320 has been marked as a duplicate of this bug. ***
*** Bug 569424 has been marked as a duplicate of this bug. ***
Anybody considered using galago to do that ? We had to do some custom meta-contact list program at my preceeding job and had to write ugly custom code all over the place to query eds and empathy and keep things together while galago, eds-feed (with a few patches) and telepathy-feed did all that already (which represented a good share of what we wanted our software to do). The buddy-list would be a "simple" galago client in this approach. Maybe I'm lacking some obvious point, could devs comment on that idea ?
galago and eds-feed are unmaintained afaik.
indeed, we haven't been able to merge back the patches we had, but reviving them by having serious apps using it and/or asking chipx86 commit access shouldn't be a real problem.
*** Bug 584600 has been marked as a duplicate of this bug. ***
*** Bug 591007 has been marked as a duplicate of this bug. ***
"That's not easy at all, but far better than stupid metacontact like in pidgin." I don't personally find metacontacts in Pidgin stupid. I'm able to merge accounts from different protocols into one physical person, and since then the actual protocol I'm using to communicate with that person it's transparent to me. Also, you can merge contacts manually, but you will be offered to merge them automatically if you assign the same nickname to two of them.
it is stupid in the sense that it requires much more manipulations than needed when you have the data to make that automatically. That's what PIM databases are all about, avoid duplication of efforts.
I can't see any scenario managing the meta contacts where you can't drag and drop the contacts in IM apps like empathy (the user must associate them at some point), no matter what the backend looks like. So why not introduce that GUI with some simple "backend" like an XML file for now and replace the xml with something more integrated/intellegent/portable/<insert-attribute-here> as soon as that is available?
Do you really have the data to make it automatically? You actually need to provide it somewhere (evolution contact vCard fields or wherever). Do you really want to make that automatically? Someone may not want to use metacontacts, so should be asked. I just would like an easy interface to manage metacontact myself. The drag & drop + XML idea sounds like a good idea for now.
(In reply to comment #25) > So why not introduce that GUI with some simple "backend" like an XML file for > now and replace the xml with something more > integrated/intellegent/portable/<insert-attribute-here> as soon as that is > available? > For the same reason you don't bake a cake then throw it out soon after. If we're going to write the code, we're going write it correctly. Even a simple backend would require quite a bit of code that would only later be thrown out.
Ben, this bug has been opened for more than two years, and has had more than ten duplicates; sometimes it is better to have imperfect but working code than the idea of an elegant solution in a potential future.
I haven't seen the code, nor I know how good it is or how diffigult is to port it to Empathy, but metacontacts just look and work fine in Pidgin. Can't be taken as example?
(In reply to comment #27) > (In reply to comment #25) > > So why not introduce that GUI with some simple "backend" like an XML file for > > now and replace the xml with something more > > integrated/intellegent/portable/<insert-attribute-here> as soon as that is > > available? > > > For the same reason you don't bake a cake then throw it out soon after. If > we're going to write the code, we're going write it correctly. Even a simple > backend would require quite a bit of code that would only later be thrown out. > What would reusing Evolution's contacts system look like? BTW, would be using Empathy right now, using Pidgin instead, as libtelepathy farsight or something like that has a dependency (gstreamer-plugins-bad) that conflicts with the fluendo gstreamer package.
Why not do it this way? First, implement a simple, Pidgin-like drag-and-drop solution. Commit. Then, implement a function that will suggest a merge if two contacts have the same display name or the same vCard. I think this would be better than doing everything automatically and opaquely; it’s annoying when a program does such things (changing the “mental model” in your head, of how the program works, in the process) without asking you, and there will always be times when the user wants to merge/unmerge contacts manually. This way, we wouldn’t have to throw out any code, and we’d have a simple, working implementation early that we could improve upon.
The roadmap (http://live.gnome.org/Empathy/Roadmap) says that People (https://edge.launchpad.net/people-project) or Soylent (http://live.gnome.org/Soylent) will be used. Can we discuss the differences and start working on that?
*** Bug 597046 has been marked as a duplicate of this bug. ***
Please ensure that any solution: 1) Does not require the user to use Evolution. 2) Allows a user/contact to have more than one account for a single protocol. 3) Allows the priority of different accounts to be specified such that I can prefer a contact's (e.g.) Jabber account if it is available. 4) Allows me to see which account a conversation is using and switch between accounts. Thanks.
*** Bug 602330 has been marked as a duplicate of this bug. ***
So the following have all been mentioned: People (0.0.6 release two years old, https://launchpad.net/people-core) Soylent (no commits for 20+ months, http://git.gnome.org/browse/soylent) Galago (unmaintained, per comment #19) EDS-feed (unmaintained, per comment #19) EDS-sync (apparently no releases in 2+ years? http://vcs.maemo.org/svn/eds/trunk/eds-sync/ChangeLog) GNOME Online Desktop (apparently not actively developed) ...unless there is better evidence that these are or will become usable, that leaves: * No outside library to wait on, * One developer who thinks "metacontacts like in pidgin" are "stupid", and * 50+ others (including https://bugs.launchpad.net/bugs/392507 & duplicates) who want such "stupid" metacontacts. I would grant that, *if* any of the above projects actually was usable, they would be a better solution than Pidgin-style contact grouping. No one has explained how contact grouping is worse than no contact grouping.
*** Bug 616347 has been marked as a duplicate of this bug. ***
*** Bug 618213 has been marked as a duplicate of this bug. ***
How about using a local LDAP server for storing contact info?
Work is going on to implement metacontacts using the new libfolks library which will be able to support what ever crazy backend you may want and isn't restricted to Empathy, help on it would surely be appreciated. See here http://telepathy.freedesktop.org/wiki/Folks for more info.
Will libfolks theoretically be able to support People and Soylent like originally intended, or is it a replacement for such things?
(In reply to comment #41) > Will libfolks theoretically be able to support People and Soylent like > originally intended, or is it a replacement for such things? Folks won't be supporting either project directly (not least of which because neither is maintained); it's a replacement. (Technically, Soylent was a program, but I think you're referring to libsoylent). Soylent could be rebased upon libfolks, but it would be better to just rebase Anerley (which is similar, but maintained).
Thanks to the hard work of Travis and Philip, Empathy master is now able to link contacts together and meta-contacts are displayed in the contact list. I think it's finally time to close this bug \o/ For those wanting to test it, I suggest you to wait for Empathy 2.31.91 that will be released on Monday. Feedback is of course welcome but please do check if your bug has already be reported before opening a new one. They should be filled using the 'Meta Contacts' component [1]. I hope you'll like it! [1] https://bugzilla.gnome.org/buglist.cgi?product=empathy&bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&component=Meta%20Contacts