Spent yesterday evening trying to think about this topic from all edges. First, I am convinced using Qt models is the right API design for Homerun. I have a very hard time giving up on them for the sake of not breaking source compatibility, to the point where I think it is better to do a clean break in libplasma2.
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. 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. A runner is like a one-time search, whereas a source is more like a live- search folder. To me, the runner concept is a subset of the source concept: it should be possible to build a runner on top of an existing source. Going the other way around means giving up some sources abilities. 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? In a sense, ioslaves would make more sense as content providers for Homerun, I am actually thinking about it, but they lack features like custom order and the API is complicated, not something I would expect lots of people to build on. To sum up, I don't think we should try to shoehorn the source concept into the existing libplasma1 runner API. I am all for creating a more complete implementation of sources in libplasma2, on top of which runners could be based. I would like to see libhomerun as a brainstorm of this work, adding there what is missing from existing runner API. Aurélien _______________________________________________ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel