After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 631215 - Allow assigning priorities to contacts inside meta-contact
Allow assigning priorities to contacts inside meta-contact
Status: RESOLVED OBSOLETE
Product: empathy
Classification: Core
Component: Meta Contacts
2.32.x
Other Linux
: Normal normal
: ---
Assigned To: empathy-maint
empathy-maint
: 632972 649664 655202 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2010-10-03 09:56 UTC by Mihai Capotă
Modified: 2018-05-22 14:22 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Mihai Capotă 2010-10-03 09:56:41 UTC
Thanks for introducing meta-contacts. They're great!

I'll just quote a comment from the Ubuntu meta-contacts fixed bug [1]:

"Just one additional thought: this should support priorities, on a general and per-contact basis. For example, given a contact with both jabber and MSN, a FOSS user may prefer to contact someone through Jabber as a general rule. But a particular user may use jabber in work, and MSN on his phone, in which case MSN might be the better choice for that contact.

"I'd suggest implementing a protocol-priority widget, and adding instances to both session-wide preferences, and individual contact properties."

Additionally, I think assigning priorities for multiple IDs of the same protocol is also needed; someone can have both Jabber at work and Jabber at home.

[1] https://bugs.launchpad.net/empathy/+bug/256478/comments/25
Comment 1 Guillaume Desmottes 2010-10-04 08:17:09 UTC
The big problem here is that the notion of "default" individual is not clear. We can do lot of things with contact (chat, invite them to a room, call, send files, share desktop, etc.), the "default" one for one action can be different for another action.
So that's mostly an issue of having a good UI allowing user to tweak that.
Comment 2 jorchube 2010-10-05 21:49:12 UTC
not clear?

Well, I think we dont need an "über-detailed" priorities system... but deciding if double click opens a chat with my girlfriend's msn or jabber account should be my choice, not random/magic/empathy's choice.

The normal(or most common) behaviour is to start a chat, and then, from inside the chat, when it's necessary, start a call, a transfer or share the desktop... IMHO

Anyway, thank you for your awesome work.
Comment 3 Travis Reitter 2010-10-06 20:40:06 UTC
(In reply to comment #1)

> So that's mostly an issue of having a good UI allowing user to tweak that.

Agreed. I think this is the hardest part (to get right). We could throw together a UI that exposes this directly, but it would be very complicated.

Within Folks itself, we do have the concept of contact prioritizing. We haven't exposed this in Empathy (yet) since we need to come up with a clean way to expose this (if at all).

Mock-ups greatly welcome.
Comment 4 Andre Lima 2010-10-13 03:09:06 UTC
I think it is easy to solve. just add a drag and drop feature to reorganize the contacts at the link UI so the priority starts on the top.
Comment 5 Guillaume Desmottes 2010-10-25 09:12:25 UTC
*** Bug 632972 has been marked as a duplicate of this bug. ***
Comment 6 Robert Marcano 2010-11-11 13:25:25 UTC
I concur on the linked accounts reordering via drag and drop, but I think the ordering must not be the only way to select the account, statuses must be used too, for example:

1 - MSN - Busy
2 - GTalk - Available
3 - Yahoo - Away

When starting a new chat, the GTalk account must be used as default. It would be nice to see more easily on the chat window which account was autoselected (hovering over the name is not easy enough) and to have a way to change it without closing the chat window, using the same example, assume Yahoo is his personal account and the GTalk one is his work one, being able to tag each account when linked is helpful (when not linked each account name could be edited, when linked only one name is shown), in this case when the chat window opens autoselecting the GTalk account (with the label "Work"), I want an easy way to switch to the Yahoo one to send a message to his personal account and not the work one
Comment 7 Philip Withnall 2011-05-08 19:20:14 UTC
*** Bug 649664 has been marked as a duplicate of this bug. ***
Comment 8 Philip Withnall 2011-07-24 13:10:16 UTC
*** Bug 655202 has been marked as a duplicate of this bug. ***
Comment 9 Chow Loong Jin 2013-07-19 09:14:49 UTC
(In reply to comment #6)
> I concur on the linked accounts reordering via drag and drop, but I think the
> ordering must not be the only way to select the account, statuses must be used
> too, for example:
> 
> 1 - MSN - Busy
> 2 - GTalk - Available
> 3 - Yahoo - Away
> 
> When starting a new chat, the GTalk account must be used as default. It would
> be nice to see more easily on the chat window which account was autoselected
> (hovering over the name is not easy enough) and to have a way to change it
> without closing the chat window, using the same example, assume Yahoo is his
> personal account and the GTalk one is his work one, being able to tag each
> account when linked is helpful (when not linked each account name could be
> edited, when linked only one name is shown), in this case when the chat window
> opens autoselecting the GTalk account (with the label "Work"), I want an easy
> way to switch to the Yahoo one to send a message to his personal account and
> not the work one

This gets a bit problematic with FB chat. I frequently end up mistakenly choosing FB chat over Gtalk when double clicking the contact because FB chat's status handling is broken (all contacts are always available).
Comment 10 GNOME Infrastructure Team 2018-05-22 14:22:21 UTC
-- 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/280.