krunner update

worked a little on krunner this evening, including integrating a few patches. since the plasma project has essentially adopted this part of the desktop as well, a number of people who were waiting for things to do have jumped on the opportunity to work on this. hopefully this trend passes over to plasma itself as we're raring up that road now and even continues post-4.0.

as of tonight krunner loads plugins at runtime (the stubbed-in search runner is such a plugin) and you can run commands via kservice. which means you can type "Mouse", hit enter, and the mouse control panel pops up. neat.

i also finally implemented the inexact matches bit of the api, so that each runner can display possible matches that aren't exact. it still doesn't show up in the user interface, but you can see them in the debug output on konsole. this way, for instance, a math runner might return an icon of a calculator showing the result of the current text which will (eventually, anywways) get shown in the middle third of the dialog. runners take care of doing whatever it is that should be done by listening to the triggered() signal for the actions it creates.

i've been leaving off the user interface bit for the inexact matches of krunner as i need to both bug the artists for some ideas/concepts as well as decide exactly how to arrange the results. for example, informational "matches", such as the calculator example, should probably appear first in the list.

at the next oxygen meeting (tomorrow evening, i believe) we'll be discussing art needs for krunner so perhaps that will start to address the first issue a bit.

ordering of plugins is another unsolved issue at the moment: what order should runners be called?

so far the non-screensaver/locking/startup code in krunner is less than 900 lines. that includes the runners (3 out of 4 of which actually do something useful =), the display code, the restarting application stuff, dbus interface glue... so i'm pretty happy with that.

if you'd like to write a krunner plugin, just implement a subclass of Runner as found in workspace/lib/runner.h. i need to find a better home for Runner, which may end up being libplasma, actually. yet another thing i need to investigate this week.

i'll be primarily working on libplasma guts (engines) and the kdebase reorg this week, so the krunner stuff will mostly fall to the gaggle of contributors in #plasma who have been hacking on various bits of it over the last week. =)