Homerun sources and Plasma runners

[Aaron J. Seigo]

On Monday, November 19, 2012 15:31:46 Aurélien Gâteau wrote:
> Le samedi 17 novembre 2012 12:56:13 Aaron J. Seigo a écrit :
> > On Friday, November 16, 2012 17:04:04 Aurélien Gâteau wrote:

> > > Sources features missing in Runners:
> > > - model-based => more QML friendly
> > 
> > as with Marco, i don't see any real need to have this in the libplasma
> > API,
> > but if we do want this in the libplasma API, we don't need to expose it
> > from AbstractRunner ..
> 
> Just answered Marco on this point.

it's not relevant to runners, though. it's can be relevant to an application 
using runners depending on how its UI is designed (which is a clue that it may 
be a visualization issue, not a data issue) or if the application is using 
runners along side other sources of data (e.g. a datadir) .. but again, that's 
not relevant to runners.
 
> > implementation detail: this could be done using a hash to keep lookup
> > fast.
> > since id's are not guaranteed to be unique, this would need to be a
> > multihash, or possibly a hash of lists.
> 
> I didn't know ids where not guaranteed to be unique. That sounds dangerous.

it allows the same id to be re-used for different results across queries, or 
entire sets of results to refered to together. only the runner can really know 
where and when it matters to distinguish between results.

note that 2 runners are prevented from having identical id's for matches, 
though, to avoid collisions between plugins.

> > a) RunnerContext gets a new updateMatches(const QList<QueryMatch>
> > &matches)
> > method which would add the matches and update matches with the same id.
> > (implementation: it could actually just remove the old match(es) and add
> > the new ones; as long as there is a model tracking the row<->match
> > correlation properly, these updates could be communicated via dataChanged
> > signals)
> > 
> > b) RunnerContext::addMatches treats all calls as updates, so if a runner
> > calls addMatches more than once and there are matches with the same id's,
> > they'd get replaced. this could be problematic, however, as it would
> > create
> > a change in behaviour for runners that call addMatches multiple times in
> > their match method and don't call setData or setId on the matches
> > explicitly. for this reason, i prefer (a)
> 
> I prefer (a) as well. I would actually prefer using the existing Qt model
> API, but that would not be source compatible.

er.. and how would this work with threading? RunnerContext is used to colate 
results from multiple threads, and the threads notify the RunnerContext of new 
matches being available .. the Qt model API doesn't come into this at all.
 
> > > - "standardized" favoriteIds
> > 
> > because it uses strings and relies on parsing of them, i really dislike
> > this mechanism. it's too easy to get wrong (e.g. a runner that by chance
> > uses one of the prefix strings in a match id) and makes it unecessarily
> > difficult to change in future.
> 
> I don't think this could happen, favoriteIds are not the same concept as
> querymatch ids. 

but they could be the same if favorite ids were implemented a bit better.

> > RunnerContext has this enum in it:
> >         enum Type {
...
> This sounds good to identify favorites, but it does not define how to get
> the actual data. There need to be at least a convention on how to get the
> url of a file or directory from a match (I guess from mimeDataForMatch()),

yes, via QMimeData.

> same for application name.

you don't need the application name. you just need the application sycoca 
entry id from which the name is easily and quickly retrieved. and by using 
type enum, one could simply use the name as returned by the runner for the 
match!

if it does turn out to be absolutely required (which i doubt), then define a 
mimetype string for it and use that with the QMimeType data to store the 
application name. but i don't think this is necessary in the least.

>From an API point-of-view, I'd rather ignore the RunnerContext enum and
>define
> a MatchCategory in QueryMatch.

it could be put in QueryMatch, but then we just have a duplicated enum for no 
particular benifit.

> I am actually wondering how
> RunnerContext::Type is defined and where it is used.

some runners tend to only produce matches for certain kinds of queries, e.g. 
something that is a file on disk. runners were duplicating code (and cpu 
cycles) to compute such things. RunnerContext does this once and makes that 
information available to the runners.

> > to make this easier and less hacky, a new value could be added to
> > QueryMatch::Type; e.g. QueryMatch. then items that can be re-used to query
> > the source runner can be marked with that type. voila.
> 
> This sounds promising, but isn't it going to be a problem for KRunner? If a

not really. worst case scenario it will need to be treated similar to 
Informational runners; but it may well need no additional work.

> > > - future need: reorder items
> > 
> > can you describe the needs here more clearly? because i think this is
> > already possible given that sorting is done by the visualization anyways.
> 
> For the FavoritePlaces and FavoriteApps sources, we want users to be able to
> reorder items.

ok .. i have a few (divergent) thoughts on this, but am still mulling over 
which might more sense.

> > something that is not covered here which would actually be very useful is
> > results paging. so a runner would return at most N results (so for a set
> > of
> > M runners, the maximum number of returned matches would be N*M) but then
> > could be requested to get anothe rset of N results.
> 
> This is solved by Qt models as well with QAbstractItemModel::fetchMore() and
> canFetchMore().

if you assume that one runner is returning results at a time in a single 
serialized thread .. then yes.

but that is not how runners work.

behind the QAIM fetchMore/canFetchMore there needs to be API to provide a 
multi-runner, thread-safe approach.

-- 
Aaron J. Seigo
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/plasma-devel/attachments/20121119/4b4dbfe4/attachment.sig>