krunner and user switching

after working through a pile of email today (days after releases are usually more busy in that respect for me) and going through a bit more "how to reorg kdebase" thinking i dove into krunner for a bit.

well, first i did some work on devnewtechbase: finish out the "introduction to kconfig" tutorial and punt around on a few other bits and pieces. discovered we need a mediawiki plugin to do imagemaps, which i need for the isv section and the cool image that pinheiro whipped up. the image is modelled after the "complete product" concept, which inge wallin brought up while he and i were talking about isv and system integrator information issues a few weeks ago.

runners in krunner can now return a list of actions that may match the text entered thus far. so one can type in an exact phrase, press 'enter' and have it work as expected; or one can type away and select from options that will be shown in the middle 70% or so of the dialog. there's a lot of interaction possibilities that open up with this.

i also added some api documentation to the runner class which is now in libkworkspace (kdebase/workspace/lib) so people working on runners can figure out what i was thinking ;) runners are pluggable, well, almost: thanks to work done by gaël ebaudoin it's fairly easy to write a plugin that contains a runner and they are seen (though not yet instantiated) by krunner. runners can also supply matches in an async manner.

an interesting side effect is that when the "switch session" (aka "fast user switching") keyboard shortcut is pressed the krunner dialog will pop up and the SessionRunner populates the list with actions to start a new sesion or switch to existing ones. in other words, the same interface for picking approximate matches for commands or files or * is re-used as the interface for fast user switching. yay! =) i didn't think of this when designing the runner class, but once i came to the problem of having to provide a facility for fast user switching, which kdesktop used to do by showing a popup menu in the middle the screen, it was the immediate and obvious answer.

if i get to work on kde stuff tomorrow (it is saturday, but that doesn't mean much really ;) i'll start hooking this all into the krunner interface. so that one can actually see what's going on behind the scenes. then i can put away my mind/computer interface and start using my eyes again ;)

once the runner api is proven a bit more i'll write a tutorial for techbase so people can go nuts:i really don't care to write every possible runner myself (e.g. a calculator, contacts integration, etc), i just care to make it easy enough that other people will ;)

this may also become a place to try out the scripting strategies we'll be putting into plasma on a smaller scale. "smaller scale" usually means "easier to get right, and fix what you get wrong", so that could be a useful exercise to avoid bigger pain as the tricker needs of plasma are handled.

and finally: the kdebase re-org will happen monday afternoon GMT. there will be one or two items (such as libkonq) that don't end up tidied away but we should end up with a more orderly kdebase with clear purposes to each area. i'll blog about that in detail on monday post-move.