On Thursday, 2013-06-20, Jan Kundrát wrote: > 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.
I was mostly considering the completion case when I wrote this.
> 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.
Well, the completion job would basically have a very similar interface to what
is currently proposed. let me do a draft.
class CompetionJob : public QObject
{
Q_SIGNALS:
// emitted whenever completion results arrive
// could be only at the end
void receivedCompletions(const QStringList &completions);
// emitted when job is finished, both on success and on failure
void finished(CompletionJob *job);
// could have additional method/signals for status, error, progress
// could accumulate results and offer them through a getter method
};
class AddressbookInterface
{
public:
virtual CompletionJob *findCompletions(....) = 0;
};
The application code would ask the addressbook plugin for completion, just
like in the current draft. It would get a job back and connect to the signals
(or only finished signal if it has result accumulation).
If another completion has to be done that invalidates the current one, just
delete the job (but could also have a cancel method to be more explicit) and
create a new query.
The second signal would allow to populate the completion popup while
completion results are coming in. Depending in the plugin implementation that
could just be one time, at the end, before finished is emitted.
Cheers,
Kevin
--
Kevin Krammer, KDE developer, xdg-utils developer
KDE user support, developer mentoring
signature.asc
Description: This is a digitally signed message part.
