On Wednesday, 19 June 2013 12:15:30 CEST, Kevin Krammer wrote:
One thing that might be interesting, depending on how the rest of the code in Trojita dealing with that interface looks like, is a "job" interface for the completion task (or for both asynchronous tasks).
That's a good advice for general purpose APIs, IMHO. However, in Trojita's case, we are deliberately limiting the API of the contect plugin; there are no "native contacts" classes encapsulating the contact details to pass around, no concept of a "unique identifier of a contact", etc. The interface is deferring as much as possible to the plugin implementation -- there's even no common "edit contact" window in Trojita; instead, the interface defines an entry point for requesting a "show me a native window for editting the contact", etc. If there was a job-based interface, some translation layer would have to be present to convert the results of these jobs into something to e.g. feed to the completion popup widget, something to manage the lifetime of the individual jobs when the user types a few more characters, etc. I think that this "simpler", or rather tightely-coupled-to-what-Trojita-needs-now interface is a better way to go at this point. That said, I can very well be wrong -- and it would not even be the first time :). Cheers, Jan -- Trojitá, a fast Qt IMAP e-mail client -- http://trojita.flaska.net/
