On Wed, 2003-12-10 at 10:09, Ross Burton wrote: > Hi, > > In writing contact-lookup-applet I've found some issues with the ebook > API: > > e_book_async_get_book_view(...) doesn't allow me to specify the maximum > number of records, whereas e_book_get_book_view(...) does. Should the > async version be extended to take the extra argument? This looks like a > trivial patch to me.
Yeah, that was basically laziness on my part. I didn't expect many people (anyone, really) to use the async api so I figured it'd be less work to not change the parameters from the old get_book_view ebook call. > ECardCursor has gone! I was planning on using it (or something similar) > in contact-lookup-applet to handle the case where the address book has > many contacts which match the typed name. It's not a common case, but > if I pointed my applet at a large LDAP server and typed "John", > e_book_get_contacts() could take some time to retrieve the data and > create the EContacts for the completion. I will be switching to > e_book_async_get_contacts() to reduce UI blocking, but this could still > involve creating a large lists of contacts. Is there a better way I've > missed? As Dan mentioned, a book view is definitely what you want if you want to avoid blocking the UI. The old CardCursor stuff basically fit someplace in between the current get_contacts() and get_book_view() on the ease-of-use/blocking-the-ui spectrum. Chris _______________________________________________ evolution-hackers maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/evolution-hackers
