GSoc : Better Buddy Search.
ssatthy at gmail.com
Mon Apr 29 08:49:04 EDT 2013
Please make comment on this.
I want to do the “Better Buddy Search” project. The Pidgin is one of the
great messengers that we can find on the internet. But it’s search
functionality performs poorly as its stated on the idea page and the bug
report. I want to make it better by improving the search functionality and
adding some cool new functions.
Better Buddy Search
Currently, the “pidgin_blist_search_equal_func” function in gtkblist.c
handles the search function. This function should be improved to get a
Writing a search algorithm that will do the following.
Buddies will be listed regardless of they are online or offline (But
status will be shown and online buddies will be shown first).
The entered string will be matched to label or their IDs (entered
string would be anywhere in the label or ID. e.g:beginning,
middle or end).
Search results will be categorized by their group (group by default
will be expanded).
Matched string in every Alias or ID will be highlighted.
Save and Search Chat Log using SQLite
Pidgin currently saves it’s chat history on a html file per a
conversation in each folder for each user. This is very inefficient way as
number of buddies increase to store chat history and makes Pidgin hard to
retrieve it’s chat history. Because of this Pidgin doesn’t have a
functionality to search its local chat history. This function will enable
users to store and search their local chat history efficiently.
Add Buddy from search box.
When user enter a valid ID into the search field and that ID is not i
the list, then Add Buddy function (pidgin_blist_request_add_buddy) will be
called to send a request to that ID.
“Seen” Chat Notification
When a buddy send us a message, this function let them know if we have
seen their message or not.
May 27 - June 15 : Get started
Go through libpurble documentation and source code
Get familiar with libpurble and Pidgin APIs.
Analyze and discuss the current search function with the mentor and
Analyze and select effective string matching algorithm.
June 16 - July 15 : Implement “Buddy Search” using selected algorithm
Analyse possible data structures that can be effectively searched.
Add offline buddies to the list to be searched.
Add syntax highlighters to highlight the matching strings
July 16- August 10 : Implement “Save Chat Log”
Analyze and discuss existing functions
Implement functions to store in SQLite database
August 11- September 03 : Implement “Search Chat Log”
Analyze efficient database search algorithm
implement functions to retrieve results
September 04 - September 13 : Implement “Add Buddy from search box
implement necessary functions to add buddies directly from search box
when user enters a valid ID.
September 14 - September 23 : Implement “Seen Chat Notification”
Capture and tigger window focus event.
Implement a function to notify users if their message has been seen
On Sun, Apr 28, 2013 at 11:57 PM, Sanket Agarwal
<sanket at sanketagarwal.com>wrote:
> Hi all,
> On Sun, Apr 28, 2013 at 10:22 AM, Mark Doliner <mark at kingant.net> wrote:
>> On Fri, Apr 26, 2013 at 9:54 PM, Sathyavarathan Sivabalasingam
>> <ssatthy at gmail.com> wrote:
>> > 3. the default buddy list will be replace by a temporary GtkTreeModel to
>> > show only the contacts that our algorithm finds.
>> Have you checked if it's possible to accomplish this without using a
>> temporary GtkTreeModel? It could possibly be cleaner and more
>> efficient to remove/re-add buddies in our existing GtkTreeModel.
> I think it's possible. We might need to look at how we currently use
> buddylists. As I know all the calls in gtkblist.c which gets the buddylist
> (PurpleBuddyList) through purple_get_blist() function in blist.c. We need
> to add a mechanism whereby each fetch of PurpleBuddyList requires a search
> term. The obvious advantages are:
> * Search can be inherent to libpurple, so other UI's (such as Finch,
> Pidgin, Adium and what not) can directly benefit from a new search feature.
> * As you suggested, it'll be cleaner and won't require touching the UI
> part. Also it can be much more efficient than having a temporary
> * We could think more about incremental search (because users type
> incrementally) by saving search state inside blist.c.
> I think it's about time we did something about this functionality.
Undergraduate (BSc Engineering)
Department of Computer Science and Engineering
University of Moratuwa
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Devel