Notes from "KRunner Breakout"

[Vishesh Handa]

Hey everyone

These are the notes from the KRunner breakout session -

* We would ideally love to use Sprinter. However the author does not want it 
to be a part of the Plasma workspace. This can be re-evaluated in the future. 
Additionally, its GPL license can be rather limiting. It prevents us from 
making it a framework and having proprietary runners.

* Interface - We want to use the Milou [1] interface [2] as much as possible. 
It is already in QML, so no porting will be required.

* We want to move the runner library out of plasma, so that it can be easily 
replaced in the future. This also makes it more attractive to other desktop 
environments. The KRunner code shall be moved to Milou (preserving history), 
and future development can continue over there.

* There should be both a plasmoid and a stand-alone application available. The 
plasmoid can either be called "Milou" or some generic name.

* The current krunner process also has some additional responsibilities which 
are unrelated to the runner part -
- lock screen management - Already moved
- Session Switching - Move to KSMServer
- Ctrl + Esc and showing ksysguard - Should be moved to an independent 
process. The suggested name was kdumpster, but that was in gest. An actual 
name still has to be decided. The KSysGuard icon should still be added in the 
new UI for maintaining visual consistency.

* The KRunner task-oriented UI will be dropped

* Runner Library needs a certain amount of work 
- Add item type capabilities to the results
- Add preview capabilities
- Refactor so that async runners do not need to spawn an event loop and block

There was a lot of debate about the internal threading in RunnerManager on if 
each runner really needs a separate thread or can some / all be combined or if 
each runner should manage threading on their own. There was no real conclusion 
except that there is no magical answer for everything. 

* Discovering and managing runners is quite hard. A new KCM should be created 
for that purpose.

* There was a discussion on if one wants two search bars - One for searching / 
launcing applications and another for searching. Some people were of the 
opinion that two search bars might be better while some were of the opinion 
that it confuses the user. For now we're going with the one search bar 
approach.

Nothing stated above is set in stone. So, comments and opinions are welcome.

--
Vishesh Handa

[1] https://projects.kde.org/projects/playground/base/milou
[2] http://vhanda.in/milou.png