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 657715 - [contact search] Be able to do more things with the contact
[contact search] Be able to do more things with the contact
Status: RESOLVED WONTFIX
Product: gnome-contacts
Classification: Core
Component: general
unspecified
Other Linux
: Normal enhancement
: ---
Assigned To: GNOME Contacts maintainer(s)
GNOME Contacts maintainer(s)
: 662518 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2011-08-30 14:33 UTC by Guillaume Desmottes
Modified: 2014-04-01 08:57 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Guillaume Desmottes 2011-08-30 14:33:48 UTC
Atm clicking on a contact in Shell's overview opens it in gnome-contacts, which is cool. But it would be even cooler to be able to do more things (start a chat, call, send an email, etc).

We considered different approach for this during the hackfest:
https://live.gnome.org/Hackfests/IMContacts%20Social2011/Tasks/ShellDesignContacts

Personally I really like the keyword approach: "chat guillaume<enter>" opening a text chat; same for 'call', 'mail', etc.
Comment 1 Guillaume Desmottes 2011-10-25 07:40:21 UTC
*** Bug 662518 has been marked as a duplicate of this bug. ***
Comment 2 Guillaume Desmottes 2012-04-30 07:02:22 UTC
Allan: what do you think about this? I'd really like to implement something like that.
Comment 3 Allan Day 2012-05-03 09:44:08 UTC
There's a few things to consider here.

First, the long term plan for search in the shell is to have different apps providing results. (You can find more information about these designs on the wiki [1].) Searching for a contact should, ideally, produce results from contacts, chat, mail, documents, etc. Generally I'd expect people to jump to these apps to start different types of communication - go to mail to start a mail, chat to do IM, and so on.

The second thing to consider is how we intend to use context menus more generally in the shell. It might not make sense to have a context menu here if we don't have them for other types of search results.

tl;dr - could be a nice feature, but I'd like to make sure it integrates well with the rest of the shell search design.

[1] https://live.gnome.org/GnomeShell/Design/Whiteboards/Search
Comment 4 Florian Müllner 2012-05-03 10:09:18 UTC
Another thing to consider: I'd like to remove all built-in search providers (except for application search) in favor of remote providers provided by the corresponding application itself (like Documents now). It is of course possible to extend the protocol to allow context menus, but it seems like a bad idea doing it for a single provider.
Comment 5 Guillaume Desmottes 2012-05-04 08:10:05 UTC
And what do you thing about using action keywords when searching? Maybe prefixed with '+' or something?
So typing something like: "+chat allan <enter>" would open a chat window with you.

I'd personally use a lot at leat +chat +call and +mail
Comment 6 Alexander Larsson 2012-05-04 08:54:09 UTC
Maybe we could "split up" the search results at some level. Like, if your search only returns a single contact, but that contact happens to have both a chat address and an email address, maybe the result could be two items, on for the chat and one for the email?

Just an idea...
Comment 7 Florian Müllner 2012-11-02 14:36:12 UTC
The current idea is that empathy, evolution, ... provide their own search results to the shell like contacts does, and users can configure what providers they are interested in and in which order results should appear.

If we want to implement something like this anyway for contacts, it'll need to be implemented in the application, as the internal contacts provider is gone.
Comment 8 Allan Day 2014-04-01 08:57:19 UTC
I still think we are best to provide the requested search functionality by other applications providing their own search providers. As such, I don't think we want to keep this open (but please feel free to argue otherwise!)