Created attachment 197597 [details]
screenshot

Is 'Personal' a group you defined yourself or did it popup out of nowhere?

somebody from irc said that Personal is mapped on My Contacts address book from google contacts

(In reply to comment #0)
> See attached screenshot; most of the contacts seem to be duplicated in a
> 'Personal' group. I don't remember seeing this with 3.1.92, but I am also using
> a different version of folks.

Cosimo: the e-d-s categories get forwarded along through Folks as groups, and the e-d-s backend is new for this cycle. So if you'd like to remove them from that group, you can remove the "Personal" category in e-d-s. The fact that you can't do this from Empathy is another bug (which I've just filed as bug #660376).

But I'm not sure this is a bug itself (I'll let Guillaume decide that). I don't think we should be stripping out valid groups (unless our users are widely-aggravated by it, I think it's good to have consistent grouping between e-d-s and Folks here, particularly since it seems to be user-set).

(In reply to comment #4)

> Cosimo: the e-d-s categories get forwarded along through Folks as groups, and
> the e-d-s backend is new for this cycle. So if you'd like to remove them from
> that group, you can remove the "Personal" category in e-d-s. The fact that you
> can't do this from Empathy is another bug (which I've just filed as bug
> #660376).

Note that I never (at least willingly) manually added any contact in any category. This is just a default 3.2 account added with the Online Accounts panel.

> But I'm not sure this is a bug itself (I'll let Guillaume decide that). I don't
> think we should be stripping out valid groups (unless our users are
> widely-aggravated by it, I think it's good to have consistent grouping between
> e-d-s and Folks here, particularly since it seems to be user-set).

I am all for keeping grouping consistent, but duplicate contacts in the contact list don't make any sense IMHO.

(In reply to comment #5)
> (In reply to comment #4)
> 
> > Cosimo: the e-d-s categories get forwarded along through Folks as groups, and
> > the e-d-s backend is new for this cycle. So if you'd like to remove them from
> > that group, you can remove the "Personal" category in e-d-s. The fact that you
> > can't do this from Empathy is another bug (which I've just filed as bug
> > #660376).
> 
> Note that I never (at least willingly) manually added any contact in any
> category. This is just a default 3.2 account added with the Online Accounts
> panel.

“Personal” represents the “My Contacts” group in Google Contacts, and is what all your contacts are added to automatically by Google Contacts. Any change to not list contacts in that group by default should probably be in the ‘google’ EDS backend.

> > But I'm not sure this is a bug itself (I'll let Guillaume decide that). I don't
> > think we should be stripping out valid groups (unless our users are
> > widely-aggravated by it, I think it's good to have consistent grouping between
> > e-d-s and Folks here, particularly since it seems to be user-set).
> 
> I am all for keeping grouping consistent, but duplicate contacts in the contact
> list don't make any sense IMHO.

They're not duplicate contacts, they're listings of the same contact in several groups (if the two contacts are actually different – e.g. they show different stuff in the Information dialogue – then that is a bug).

(In reply to comment #6)

> “Personal” represents the “My Contacts” group in Google Contacts, and is what
> all your contacts are added to automatically by Google Contacts. Any change to
> not list contacts in that group by default should probably be in the ‘google’
> EDS backend.

> They're not duplicate contacts, they're listings of the same contact in several
> groups (if the two contacts are actually different – e.g. they show different
> stuff in the Information dialogue – then that is a bug).

Okay.

[ Dragging those contacts out of the Personal group into the same group as their "copies" worked as expected! ]

So, did I get the big picture?

1. Google has a My Contacts group by default where it automatically places people you regularly or spontaneously contact.
2. The My Contacts group is automatically mapped to a Personal group in folks.
3. e-d-s/folks fetch the addressbook, and it will see e.g. contact foo@bar.baz is in the My Contacts group. If foo@bar.baz is also a TP contact in my contact list, it will show up in a Personal group in addition to Ungrouped or whatever other groups the TP contact might be associated with.

The issues I see with this approach are:
- I never created the My Contacts group myself
- Nothing tells me Personal in Empathy maps to My Contacts
- You cannot remove them from the group "the usual way" from the Edit dialog, which is bug 660376

Given that My Contacts is not really a manually managed group, I think all of this is quite confusing and Empathy should just ignore it. Or at least special case and
- not show the Ungrouped entry if there's a Personal one?
- not show the Personal entry if the TP contact is already in a custom group?

(In reply to comment #7)
> (In reply to comment #6)
> 
> > “Personal” represents the “My Contacts” group in Google Contacts, and is what
> > all your contacts are added to automatically by Google Contacts. Any change to
> > not list contacts in that group by default should probably be in the ‘google’
> > EDS backend.
> 
> > They're not duplicate contacts, they're listings of the same contact in several
> > groups (if the two contacts are actually different – e.g. they show different
> > stuff in the Information dialogue – then that is a bug).
> 
> Okay.
> 
> [ Dragging those contacts out of the Personal group into the same group as
> their "copies" worked as expected! ]
> 
> So, did I get the big picture?
> 
> 1. Google has a My Contacts group by default where it automatically places
> people you regularly or spontaneously contact.
> 2. The My Contacts group is automatically mapped to a Personal group in folks.
> 3. e-d-s/folks fetch the addressbook, and it will see e.g. contact foo@bar.baz
> is in the My Contacts group. If foo@bar.baz is also a TP contact in my contact
> list, it will show up in a Personal group in addition to Ungrouped or whatever
> other groups the TP contact might be associated with.

Yup, that's correct.

> The issues I see with this approach are:
> - I never created the My Contacts group myself
> - Nothing tells me Personal in Empathy maps to My Contacts
> - You cannot remove them from the group "the usual way" from the Edit dialog,
> which is bug 660376
> 
> Given that My Contacts is not really a manually managed group, I think all of
> this is quite confusing and Empathy should just ignore it. Or at least special
> case and
> - not show the Ungrouped entry if there's a Personal one?
> - not show the Personal entry if the TP contact is already in a custom group?

I agree that something needs to be improved here, but I'm not sure how. Guillaume?

(In reply to comment #8)
> (In reply to comment #7)
> > (In reply to comment #6)
> > 
> I agree that something needs to be improved here, but I'm not sure how.
> Guillaume?

Humm, we can see the Empathy contact list as a view on a specific subset of
all your contacts: those having at least an IM persona. I think this approach
makes sense as this contact list offers a more traditionnal approach of IM
and so shouldn't be cluttered with loads of non IM contacts.

So maybe the solution here is that Empathy should only show groups which are
defined on IM as well?

Not sure if Folks allow me to easily know the source of a group though.

(In reply to comment #9)
> (In reply to comment #8)
> > (In reply to comment #7)
> > > (In reply to comment #6)
> > > 
> > I agree that something needs to be improved here, but I'm not sure how.
> > Guillaume?
> 
> Humm, we can see the Empathy contact list as a view on a specific subset of
> all your contacts: those having at least an IM persona. I think this approach
> makes sense as this contact list offers a more traditionnal approach of IM
> and so shouldn't be cluttered with loads of non IM contacts.

I think it's fine to filter out Individuals who contain no Telepathy Personas (which Empathy already does), so long as Individuals appear consistently in all applications.

This is something that Android gets wrong (eg, the Google Talk app only shows the equivalent of bare Personas from a single account) and the inconsistency stands out when you switch between the contacts app and the chat app.

My general goal with Folks is that different applications might show different views on the Individuals or arrange them differently, but if you put representations of a person from different applications next to each other, it would be obvious that they matched in a split second.

> So maybe the solution here is that Empathy should only show groups which are
> defined on IM as well?

For a few groups, I think there are some reasonable mappings we can do:

- My Contacts/Personal ~= someone added to your contact list -> (ignore the group)

- Starred in Android ~= Favorite
  * yes, that's literally the name of the group (though at least it's a good hint out-of-context what will happen if you remove the label)
  * it's mapped this way on my phone (which is what added it to that group in the first place)
  * one downside to this mapping is that it would require a different method to remove it than TpLogger favorites
  * think there's a connotation that you will have at most 5 or 6 "Starred in Android" contacts to fit UI requirements

> Not sure if Folks allow me to easily know the source of a group though.

No, we only store groups as simple strings.

But if you're just interested in the group of contacts that come from Telepathy, you can iterate through the Personas and only include the groups on Tpf.Personas.

If we can come up with a clear, compelling reason or few, we could add a groups-detailed property that maps sources and group names. But I suspect filtering like above should work well enough without requiring new API.

(In reply to comment #9)
> (In reply to comment #8)
> > (In reply to comment #7)
> > > (In reply to comment #6)
> > > 
> > I agree that something needs to be improved here, but I'm not sure how.
> > Guillaume?
> 
> Humm, we can see the Empathy contact list as a view on a specific subset of
> all your contacts: those having at least an IM persona. I think this approach
> makes sense as this contact list offers a more traditionnal approach of IM
> and so shouldn't be cluttered with loads of non IM contacts.
> 
> So maybe the solution here is that Empathy should only show groups which are
> defined on IM as well?
> 
> Not sure if Folks allow me to easily know the source of a group though.

Given the issues outlined in comment #10, I think it would be reasonable to ignore groups that don't come from IM personas (since Empathy is an IM application).

On a broader level, I think only Google+-style "circles" are meaningful groups. And they only matter if you're concerned about who will be receiving your broadcasts.

In the context of an IM app or contacts app, the only distinction that matters to me is favorite/non-favorite (because it makes sense to feature the favorites more prominently in some UI). In nearly every case, I'm going to search immediately because I've got someone in mind.

Some people also browse contacts by availability for idle communication (though I think this makes the most sense for games).

OK, so the right fix for this bug is simply to filter out contacts which are not in Telepathy. This shouldn't be hard to do using the new ContactList API; I really don't want to write more code using the crappy old API.

http://telepathy.freedesktop.org/spec/Connection_Interface_Contact_Groups.html#Property:Groups

Of course that means that groups from CM still living in the past would be filtered out but we need to move forward so I'm considering depending on ContactList for 3.4.

That means we won't be able to fix this bug for 3.2 unfortunately.

For the record, I opened https://bugs.freedesktop.org/show_bug.cgi?id=41357 about making ContactList mandatory.

(In reply to comment #10)
> - Starred in Android ~= Favorite
>   * yes, that's literally the name of the group (though at least it's a good
> hint out-of-context what will happen if you remove the label)
>   * it's mapped this way on my phone (which is what added it to that group in
> the first place)
>   * one downside to this mapping is that it would require a different method to
> remove it than TpLogger favorites
>   * think there's a connotation that you will have at most 5 or 6 "Starred in
> Android" contacts to fit UI requirements

I always tought that the logger wasn't the right place to store favorites.
Maybe it's time to move this to Folks?
- It makes more sense as that's the component dealing with contacts.
- We should mark an invidiual as favorite, not a persona
- It's the best one to automatically tag as favorite personas from such magic
groups.

(In reply to comment #14)
> (In reply to comment #10)
> > - Starred in Android ~= Favorite
> >   * yes, that's literally the name of the group (though at least it's a good
> > hint out-of-context what will happen if you remove the label)
> >   * it's mapped this way on my phone (which is what added it to that group in
> > the first place)
> >   * one downside to this mapping is that it would require a different method to
> > remove it than TpLogger favorites
> >   * think there's a connotation that you will have at most 5 or 6 "Starred in
> > Android" contacts to fit UI requirements
> 
> I always tought that the logger wasn't the right place to store favorites.
> Maybe it's time to move this to Folks?
> - It makes more sense as that's the component dealing with contacts.
> - We should mark an invidiual as favorite, not a persona
> - It's the best one to automatically tag as favorite personas from such magic
> groups.

See bug #660908 for supporting favorites in the EDS backend (so we can have consistent favorites for non-Telepathy personas as well).

Note that you should already be able to replace code in Empathy that explicitly sets favorites in the logger with code that sets an Individual as a favorite already, and it should all be done transparently for you.

Each of the Individual's personas who support setting a favorite will have it set/unset when you set/unset as a favorite. (Technically, you can't set an Individual as a favorite, since Individuals aren't stored on disk anywhere; they're just reassembled in a consistent way). The Telepathy backend would just happen to store the fact that it's a favorite in the Telepathy Logger. Once we add support in the EDS backend, then it would also be stored there (but these values would be kept synchronized automatically).

Ok, so we should:

- Clean up Empathy to just use Folks to grab favorites; I opened bug #661489
- Ignore non Telepathy groups in Empathy; I renamed this bug to that.
- Improve Folks to consider contacts from the "Starred in Android" group as favorites. I opened bug #661490

Let's finish bug #663387 as its branch touches a lot of the individual store/view code.

(In reply to comment #16)
> - Ignore non Telepathy groups in Empathy; I renamed this bug to that.

Bug #665083 may be an easier way to fix this actually.

(In reply to comment #18)
> (In reply to comment #16)
> > - Ignore non Telepathy groups in Empathy; I renamed this bug to that.
> 
> Bug #665083 may be an easier way to fix this actually.

Not really: there are still non-system, non-Telepathy groups which come from EDS (such as if I create a contact group in Google Contacts). Those wouldn't be ignored by ignoring system groups.

I thought that fixing this would be easy now that I added empathy_connection_aggregator_get_all_groups() but actually it's not.

Let's consider the following scenario:
- A is added to the Telepathy group G
- Folks gets the notification and update A's individual
- Empathy checks if G is a Telepathy group but think it is not because it didn't get the change notification from TP yet.

Problem is, we can't know who will receive the notification first (empathy or folks), so that mean empathy will have to re-filter the whole contact list each time a TP groups is added/removed, which doesn't sound great.

I think the right solution here is to have API in Folks giving me all the groups for a specific backend, which is mostly bug #627398.

What do you think?

*** Bug 665163 has been marked as a duplicate of this bug. ***

*** Bug 660376 has been marked as a duplicate of this bug. ***

> Problem is, we can't know who will receive the notification first (empathy or
> folks), so that mean empathy will have to re-filter the whole contact list each
> time a TP groups is added/removed, which doesn't sound great.

How often would this be updated that filtering a couple of hundred contacts would be so difficult?

*** Bug 671495 has been marked as a duplicate of this bug. ***

*** Bug 672664 has been marked as a duplicate of this bug. ***

This is also very annoying to me. It would be great, if grouping could be
disabled at all or switched to custom (i.e. don't use Folks for that).
A lot of my contacts are in more then one group, I see this more as a tag or label. But for an overview as in Empathy, having contacts displayed multiple times in different groups, it's sadly not that neat.

(In reply to comment #26)
> This is also very annoying to me. It would be great, if grouping could be
> disabled at all

You can do that using:
gsettings set org.gnome.Empathy.ui show-groups false

> or switched to custom (i.e. don't use Folks for that).
> A lot of my contacts are in more then one group, I see this more as a tag or
> label. But for an overview as in Empathy, having contacts displayed multiple
> times in different groups, it's sadly not that neat.

You may be interested in bug #670125 which is about switching to a tag model.

*** Bug 673639 has been marked as a duplicate of this bug. ***

*** Bug 677768 has been marked as a duplicate of this bug. ***

*** Bug 678355 has been marked as a duplicate of this bug. ***

-- GitLab Migration Automatic Message --

This bug has been migrated to GNOME's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/empathy/issues/438.