On Thu, 20 Jun 2013, Jan Kundrát wrote:
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 :).
speaking of the interface, one addressbook plugin I would like to see (and may
get time to try and write later) is one that supports using the pine remote
addressbook.
this stores the addressbook as a message in the addressbook folder on the IMAP
server.
So please try and keep the addressbook plugin from being too QT specific and
make it be something that can support a simple use case like this or a simple
local file.
David Lang
