Opened 12 years ago

Last modified 2 years ago

#1710 new enhancement

even more improved "buddy list searching"

Reported by: vladr Owned by: deryni
Milestone: Component: pidgin (gtk)
Version: 2.0.1 Keywords:
Cc: seocam, Dawudd, teohhanhui, jolestar, Senfi

Description

Curently, buddy list searching ("Ctrl+F") only searches within the displayed buddies (if buddy is in a collapsed group, or is buddy is offline). Moreover, only buddies whose names BEGIN with the search-string are highlighted.

A configurable alternate search/filter would be useful that, while typing a search-string in the search box, would show a temporary view of the buddy list instead of the standard buddy list:

  • EXCLUDING buddies not matching the search string (hidden)
  • INCLUDING buddies CONTAINING (anywhere in their alias or ID) the search-string, even if buddies are offline (shown)

The temporary view would be shown while the search box is still being displayed, and the normal view would be shown when the search box is dismissed (Esc.)

This is necessary when:

  • I want to search for a string INSIDE aliases, not just the beginning
  • I want to search for a string inside IDs, not just aliases
  • the option "Show offline buddies" is disabled and/or some groups are collapsed (large buddy list), yet: + I want to quickly highlight (for IM sending) a user that is in a collapsed group,

OR

+ I want to quickly highlight (for IM sending - via native protocol support or via "Offline message emulation" plugin) a user that is offline

This is also the way Skype currently implements buddy-list searching.

Vlad.

Change History (33)

comment:1 Changed 12 years ago by dammbdf

I concur to this ticket. It should search the entire list, no matter if buddy is offline or if his group is collapsed.

comment:2 Changed 12 years ago by TrevorHart1

I really would love to see improvements to searching through buddy lists. Particularly, enhancing the auto-suggest feature within the Send IM window to match the search text as a wildcard against the person's ID AND alias.

Trevor

comment:3 Changed 11 years ago by datallah

Ticket #5776 has been marked as a duplicate of this ticket.

comment:4 Changed 11 years ago by datallah

Ticket #7102 has been marked as a duplicate of this ticket.

comment:5 Changed 11 years ago by kwanbis

I also see the need of a filtering search, like in live messenger, but I only think we need to have to show buddies CONTAINING (anywhere in their alias or ID) the search-string, even if buddies are offline (shown).

comment:6 Changed 11 years ago by datallah

Ticket #7763 has been marked as a duplicate of this ticket.

comment:7 Changed 10 years ago by tylla

Eventually the full Buddy list could be shown while searching (no need to hide non-matching Buddies) and the first matching Buddy should be highlighted after typing a letter in the search box. Furthermore, pressing the up/down keys should jump to the next/previous matching Buddy. And if no matching Buddy is found, then the topmost group should get the highlight.

I don't know which is easier to implement, but certainly the originally proposed one is the better (by hiding non-matching entries). I only wanted to show an alternative solution. If this is the price to get working searching capabilities in the Buddy list, let it be. :D

comment:8 Changed 10 years ago by datallah

Ticket #3761 has been marked as a duplicate of this ticket.

comment:9 Changed 10 years ago by datallah

Ticket #8006 has been marked as a duplicate of this ticket.

comment:10 Changed 10 years ago by rekkanoryo

Ticket #9175 has been marked as a duplicate of this ticket.

comment:11 Changed 10 years ago by deryni

Ticket #9548 has been marked as a duplicate of this ticket.

comment:12 Changed 10 years ago by rekkanoryo

Ticket #9741 has been marked as a duplicate of this ticket.

comment:13 Changed 10 years ago by rekkanoryo

It's not possible for us to change the behavior of the search feature--GTK+ provides that searching feature, not us. The best we can do is supply our own function for determining if a given row matches the search criteria (which we do) and have that function handle matching on multiple words sanely (which we don't yet do). The search only searches visible rows in the buddy list (which is a GtkTreeView); changing this behavior would require the GTK+ people agreeing that it's a necessary change.

comment:14 Changed 10 years ago by darkrain42

Ticket #10682 has been marked as a duplicate of this ticket.

comment:15 Changed 9 years ago by datallah

Ticket #11100 has been marked as a duplicate of this ticket.

comment:16 Changed 9 years ago by BoffinbraiN

Since I just created an account today to report on other bugs, I thought I would give some input here.

Despite using Pidgin for about 2 years, I didn't find out about the type-to-search feature until recently, which unfortunately shows how undiscoverable and unintuitive it is. Also, it's not as powerful as the auto-suggest feature in the New IM window because it only works for usernames (and it's already been mentioned that hidden contacts are not revealed). Even the New IM functionality doesn't cater for all needs because sometimes the user may want to perform some arbitrary action on a contact which doesn't involve sending them a message or opening a conversation window.

To solve all these problems, I really believe Pidgin's interface should include a prominent search bar above the contact list which, when used, will override all views and filters to show contacts that match the search by e-mail or username (and yes, partial match at any position please!).

comment:17 Changed 9 years ago by deryni

Ticket #11435 has been marked as a duplicate of this ticket.

comment:18 Changed 9 years ago by deryni

comment:ticket:1325:13 and comment:ticket:1325:15 are likely helpful here. Also recently I believe we accepted a patch which added an additional data field to the values the type-to-find search searches (what that field is I can't recall offhand and I'm too lazy to look right now) which should help with the actual finding of possible buddies and could be expanded if more was still needed.

The part of the patch in #5876 that I still intend on accepting when I can finally get time to sit back down to working on it is possibly also relevant here.

comment:19 Changed 9 years ago by deryni

  • Owner set to deryni

comment:20 Changed 9 years ago by eagleoneraptor

This could be solved "relatively easy" using a simple list widget (GtkList? for example) or other GtkTreeView?, that is hidden when the search bar is empty, and when you type part of a buddy name in this, hide the buddy list and show GtkList? or GtkTreeView? with search results, simplifying the issue of having to hide buddies on the original list.

It's just an idea, since I have not any little idea of the structure of the Pidgin code :(.

Regards

comment:21 Changed 9 years ago by BoffinbraiN

I have experience in Java and Swing, but sadly not in C++ or GTK. Still, I thought I'd put in a few more opinions.

I would certainly hope that the buddy list extends from some sort of tree view, since it is essentially a list with expanding sub-categories. What's really important is how the model is implemented, and whether buddies that are not visible in the list are still present in this model.

If they are always there, but hidden, the find feature can simply toggle the visibility of these list items. If not, we clear the buddy list view (remembering its prior state) and then rebuild a flat list of matching buddies. I imagine this _could_ possibly be implemented by having the standard buddy list state in one tree view model, and switch it out to replace it with a search results model while searching. That means that if people go on/offline in the meantime, Pidgin can still update the model even if it isn't currently linked to a component, and it will still be correct when switching back.

What I'm hinting at, is that we shouldn't need to add any new components to the window at all.

comment:22 Changed 9 years ago by datallah

Ticket #12352 has been marked as a duplicate of this ticket.

comment:23 Changed 9 years ago by jolestar

i think this is a basic feature for a im tool.

comment:24 Changed 8 years ago by datallah

Ticket #13755 has been marked as a duplicate of this ticket.

comment:25 Changed 8 years ago by daniels.vasconcelos

Hi guys.

Why this ticket is not "active"? I think this feature is so basic for an IM (I know that would not be simple to implement, but is so useful) and pidgin should have this improvement.

Regards and thanks for this application.

comment:26 Changed 7 years ago by fwmfftvh

Does developers have any understanding of ergonomics? It is totally impossible to use Pidgin without this feature! This is not feature request, this critical bug! Please, change the status of this ticket.

comment:27 Changed 7 years ago by Rudloff

Note that Adium does this.

comment:28 Changed 7 years ago by mvastola

Without impugning the abilities of the developers (who are clearly competent, having created such a popular IM tool), I would like to add my name to the list of those who strongly support the inclusion of this feature in some manner.

I would personally find it quite useful and I believe the search functionality would be more intuitive if changed.

Being unfamiliar with Pidgin's internals, I cannot offer very specific suggestions or approaches, but if GTK+ search feature isn't sufficient, can't it be overridden and/or replaced with similar code modified to do what is needed?

Additionally, can someone confirm if the thirteenth comment by rekkanoryo is still applicable/true today, three years later? (Perhaps GTK has added the feature in the interim, making this ticket readily resolvable.)

Finally, I'm intrigued by "changing this behavior would require the GTK+ people agreeing that it's a necessary change". What exact change would need to be requested of the GTK+ people? I would be interested to see if there were a pending request for this that I could support and I would be further interested in submitting one if there weren't.

comment:29 Changed 6 years ago by Senfi

I can't believe, this ticket exists for six years... I strongly +1 this enhancement.

comment:30 Changed 6 years ago by risingfish

Wow, have to agree with Senfi. 6 years is to long for this ticket not to of been taken care of. This would be an incredibly nice feature to have.

Last edited 6 years ago by risingfish (previous) (diff)

comment:31 Changed 5 years ago by hsg92

Hi Pidgin fellow developers, I found this ticket interesting to solve and thus I did some ground work. I have implemented the "search" feature by assuming the data set to be my phone book contacts ( currently considering only full name ). This is a great start and we can discuss more on the algorithms that we can employ to have the best im search feature. Please have a look at newest/top post here:[algoandtech.tumblr.com]

Thanks, Harshal

comment:32 Changed 3 years ago by Pastafarianist

I join those who are eagerly looking forward to seeing this feature implemented. Searching in the buddy list becomes a great hassle when it contains many people with the same first name but different last names.

comment:33 Changed 2 years ago by Murz

I also vote for this feature, filtering contacts by full substring is very useful!

Note: See TracTickets for help on using tickets.
All information, including names and email addresses, entered onto this website or sent to mailing lists affiliated with this website will be public. Do not post confidential information, especially passwords!