Homerun sources and Plasma runners

[Aaron J. Seigo]

On Tuesday, November 20, 2012 18:12:47 Aurélien Gâteau wrote:
> First, I am convinced using Qt models is the right API design for Homerun. I

nobody is saying "don't use Qt models in homerun".

the question is which of the following makes sense:

* AbstractRunner should be a model (BIC)
* AbstractRunner should export a model (SC & BC)
* RunnertContext should provide a model for RunnerManager to expose (SC & BC)
* A Qt Model should sit on top of RunnerManager (SC & BC)

assuming we don't need the first option, and i keep noting that we don't 
(really, we don't), i really don't understand what you mean by your first 
paragraph.

> Furthermore, apart from the browsing issues, there is another fundamental
> difference between runners and sources which I don't think we can bridge: a
> runner is expected to run for a limited time. As stated in
> AbstractRunner::match() doc: "Returning from this method means to end
> execution of the runner.". Homerun sources, on the other hand, should be
> able to update themselves whenever they detect changes. This is especially
> important when Homerun is used as a containment because it needs to update
> itself without any user intervention.

the apidox has misled you, even though it is accurate. once a runner returns 
from match(), it is assumed to be done for the purpose of the query. however, 
it can continue to add matches to the RunnerContext object. that was what the 
whole discussion about updateMatches was about.

> At one point I thought we could at least make use of the single-runner mode
> of AbstractRunner to implement some of the simplest sources. While that can
> work for, say, the Power or Session sources, it cannot work for other
> simple sources like "Recent Documents", again because such a source needs
> to be able to update itself.

please re-read my previous emails about adding an updateMatches to 
RunnerContext.
 
> A runner is like a one-time search, whereas a source is more like a live-
> search folder.

i get the impression you are very set on just keeping AbstractSource alive, 
perhaps because you've put so much effort into them.

if there is good reason to keep AbstractSource, fine. however, i've offered 
valid solutions to this problem and i have yet to see a good reason for their 
existence.

> Considering prior art, Kickoff and Folder View are not built on top of
> runners either (true, Kickoff uses runners to implement searching, but not
> for browsing), so I am not sure why runners would be appropriate for
> Homerun but not for them?

you picked two of the oldest plasmoids which also happen to have the most 
complex internal implementations.

kickoff's use of runners was retrofitted as at one point it even implemented its 
own search -> that was seen as a bug by our users (different results in 
different places) and so was corrected. 

browsing the tree of applications *as a tree* (consider that it also needed to 
provide a traditional qmenu based implementation) was most easily accomplished 
with a model written for it though it could just as easily be done with a 
runner in the full kickoff UI given how it works. in fact, it would probably 
work *better* as the transition animation would not be unecessarily interupted 
due to processing results for the model (alternatively, the model could be 
threaded). 

browsing the file system makes sense using model for directory listings. all 
the functionality is there for it, which explains why folderview does not use 
runners.

homerun appears to present, predominantly, a set of query results. these could 
easily be done with runners.

the exception is when it goes to list full directory contents. and as i've 
stated elsewhere, imo this should be done with a KDirModel directly without 
any wrapper around it.

with some necessary additions to the runner functinality in libplasma, i don't 
see anything in homerun, other than directory listings, that could not be done 
as well with runners as it is now.

> In a sense, ioslaves would make more sense as
> content providers for Homerun

for directory listings, yes. for everything else probably not as you'd not 
only still need to construct a query system for them but kioslaves revolve 
around the idea of file-like items. lock/logout/hibernate/etc do not map nicely 
to this. during kde3 times we had people writing all sorts of kioslaves for 
non-filesystem-like things and they tended to work rather horribly.

> To sum up, I don't think we should try to shoehorn the source concept into
> the existing libplasma1 runner API. 

fine.

>I am all for creating a more complete
> implementation of sources in libplasma2, on top of which runners could be
> based.

this makes very little sense. sources are models which are not written in a 
threadsafe manner to be used from runners which are built on a threaded model. 
behind the scenes they all access similar / the same convenience API. 

search on sources is implemented apparently by filter models, which means 
having to load entire datasets into the model and then filter based on the data 
.. rather than querying first to pull just the data needed.

at the most, source and runner are two very different concepts.

realistically, runners can comfortably provide for everything source is 
currently doing (and better, by not blocking the UI for instance) with the 
exception of listing on-disk directories which is better left to KDirModel (or 
the QML component that provides access to it) .. so source is a duplicatoin of 
runner + kdirmodel when, if everything is treated as a model, is unecessary.

i support bringing an updatable item model to runners along with an easy way 
to handle collections of matches segregated by runner (and perhaps other 
criterion), but i'm not in favour of inverting the design.

-- 
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/20121120/23e337ba/attachment.sig>