Just my 2 cents on the matter. Feel free to ignore me. 2012/11/16 Aurélien Gâteau <agat...@kde.org>: > A preliminary subject is API compatibility: I don't think it is possible > to extend the current AbstractRunner interface in a BC way to meet our > needs. Would you be ready to create a new runner interface? > > This would require: > - Defining and implementing this new interface (let's call it > AbstractRunner2 for now) > - Implementing an adapter to load old AbstractRunner-based runners > - Porting KRunner to use AbstractRunner2 and the adapter > - Progressively porting runners shipped in KDE SC to AbstractRunner2
<brainstorm from="someone who dug into the runners api a little bit"> Beyond that, I think it would be nice if runners were turned into a library (something like librunner) so that other applications can benefit from it. After all, their purpose is very generic: generating a list of actions from a given input. An example of where this could be useful is in rekonq (the concept of its "omnibar" si very close to the one of krunner). </brainstorm> > [...] > Sources features missing in Runners: > [...] > - browsing support (as in: entering/leaving folders, application > groups...) by invoking the source with named arguments > [...] > Q: Do we want the ability to browse in the Runner interface? I really don't think it's a good idea enable browsing _inside_ the krunner widget. It is meant enable the user to quickly run whatever action you're looking for, priorizing only the few most important results. If the user doesn't find what he wants there, then krunner should provide a "More results..." action which opens a full window with complete results (krunner kio maybe?). -- Luiz Romário Santana Rios _______________________________________________ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
