Searchresults API

[Evan Schoenberg]

On Jun 26, 2007, at 2:40 AM, Mark Doliner wrote:

>> When additional results
>> arrive, I can  simply reference my object via the data parameter of
>> notify_searchresults_new_rows. So far, that should work fine.
>> However, when the user closes the search results window, and
>>  afterwards notify_searchresults_new_rows gets called, I'd get a
>>  dangling pointer and the app would crash. There's no way to tell
>> the  API that I don't want to receive any further information.
>
> When the user clicks the red bubble to close the search results  
> window, you
> should call either purple_notify_close() or  
> purple_notify_close_with_handle()
> to destroy the libpurple side of the search results window.  That  
> will call
> the close_notify ui_op in Adium (your code), which should in turn  
> close the
> search results window.  Does that make sense?

What if you return a retained (rather than autoreleased) pointer to  
your windowController when the search results window is first handed  
back to libpurple (adiumPurpleNotifySearchResults) , then release  
that when the close_notify op is called (adiumPurpleNotifyClose)?   
Conceptually, that's doing memory management as Mark suggested --  
letting the libpurple search results API 'own' the window controller.  
There can be any number of owners -- the beauty of reference counting!

(The other notify functions may need to be modified to behave  
similarly... though I don't think so since we simply ignore the  
notifyClose ui_op for those types)

-Evan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://pidgin.im/pipermail/devel/attachments/20070626/3679c9b2/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 186 bytes
Desc: This is a digitally signed message part
URL: <http://pidgin.im/pipermail/devel/attachments/20070626/3679c9b2/attachment.sig>