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
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
