Homerun sources and Plasma runners

[Aurélien Gâteau]

Le mardi 20 novembre 2012 20:16:17 Aaron J. Seigo a écrit :
> 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".

My mistake. Should have written "Qt models is the right API design for content 
providers".
> 
> 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.

I am not advocating for the first option. I would like something between 2nd 
and 3nd option.

Homerun AbstractSource class is not a model. It inherits from QObject and 
provide virtual methods to create models. A source must implement at least:
"QAbstractItemModel *createModelFromConfigGroup(const KConfigGroup &group)"
and optionally:
"QAbstractItemModel *createModelFromArguments(const QVariantMap &args)"

Trying to map the way sources work to runners, instead of having a runner 
calling RunnerContext::addMatches(), a runner would have a createModel() 
method which would be called by RunnerContext or RunnerManager to reach the 
runner data.
This gives runners the ability to use whatever model class is more 
appropriate: a model inheriting QAbstractListModel, or a simple 
QStandardItemModel, or maybe a proxy model on top of an existing model 
provided by a library, etc.

> > 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.

The doc for this method needs an update then because it also says:

"Also, all matches need to be reported once this method returns. Asynchronous 
runners therefore need to make use of a local event loop to wait for all 
matches."

But OK, I am not going to pretend all my docs are always up to date.

> > 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.

I have no problem throwing away code, I don't see throwing away code as a 
waste of time because know I learned more about the problem and possibly 
improved my skills by writing that code. But I am against throwing away code 
if I am not convinced the new replacement code is better.
Creating your own API to expose an array of data is fine as long as your needs 
do not go beyond "clear the list, then append items". Now that there are other 
needs I have a problem with reimplementing what is already solved with Qt 
models.

> > 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.

Well, I picked the ones which have similar features as Homerun, but fair 
enough, history often gets in the way of the simplest solution.

> 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.

That would mean different APIs to provide content... I am not sure I want to go 
in that direction.

> > 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.

Yes, that is why I am reluctant to go io-slaves.

> >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.

I actually don't like the idea of trusting every runner code to be thread-
safe. This is all the more dangerous when Homerun is running as a containment 
because in this case the Homerun process is the Plasma Desktop process. I want 
to experiment with writing a proxy model which would run its source model in a 
separate process. Don't know how well it is going to perform, but I am going 
to give it a try. If it is good enough it would be IMO a safer alternative to 
having heavily multi-threaded code.

> 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.

That is not correct. A basic source can indeed provide a model which expose 
all its data, Homerun will then provide a generic filter on top of it. But a 
source can also provide a model with a "query" property, in which case the 
model is responsible for implementing searching/filtering itself.

Aurélien