[Panel-devel] Proposal for changes to KRunner

[Ryan Bitanga]

Hey everyone,

I have a few ideas to further future-proof krunner. It's been saved on
my disk for some time, but instead of letting it suffer from bitrot, I
figured I might as well just send an e-mail and get some feedback.

Anyway, here it goes:
Since SearchAction is the main matched item class, it really
represents a noun and not an action. So we could rename SearchAction
to SearchMatch, not inherit from QAction, then add a QList<QAction*>
fetchActions(SearchMatch*) method to AbstractRunner. This would allow
delayed creation of QActions and theoretically faster creation times
for SearchMatch objects. We could rename ::SearchMatch in
interface.cpp to something else to differentiate it from
Plasma::SearchMatch.

Within fetchActions(), the runner can determine which actions to
provide to krunner based on mimetype, etc., allowing runners to be
more flexible. This would also allow us to permit user-created actions
and have KRunner scan a directory and then add user-created actions to
the pool of possible actions for that runner via an addAction(const
QString& icon, const QString& name, const QString& exec, const
QString& mimetype = QString::null) method. This would mimic behavior
for creating konqueror service menus. We could write a dialog box for
the creation of user-created actions to make it easier for users.

If we allow KRunner to more Quicksilver-like, actions could have a
"direct object". For example, given a match for the folder
"/home/kde-devel/kde/krunner.diff", the action "E-mail file to..."
would have a direct object of type "Contact". So we can have generic
set of direct objects such as files and contacts which can be
implemented as runners themselves. Then each action that has a direct
object can choose from the already available "direct object" runners
or have their own specialized version. So going back to the "E-mail
file to..." example, KRunner can redirect the search box to finding
matches for the direct object. So the text above the search box could
change from "Enter the name of an application, location or search term
below." to "Enter the name or e-mail address."

We don't actually _have_ to subclass QAction because I don't think we
need signals or slots since the burden of determining what to do is
left with the runner. KRunner worked fine after I removed the
inheritance from QAction for SearchAction anyway.

With regards to the exact, possible, and informational matches scheme,
I think having a clear distinction between exact and possible matches
makes learning user preferences difficult for KRunner. I think
relevance should be the only criterion for choosing a default match. I
also think users should be able to specify a default match which would
be set globally (so only KRunner is concerned with default matches and
AbstractRunners have no clue what the default match is).

We could get around this by changing operator<() to consider match
type as well. Default matches (set by a "Set as Default" action), for
example, can have a fixed relevance at 10, while exact matches can
have a multiplying factor of 2, and possible matches have a
multiplying factor of 1.

So given a query for "Kon", with matches:
- "Konsole" (default match) with a relevance of 0.43,
- "Konqueror" with a relevance of 1.5 (assuming additional weight is
given by service runner due to the high number of launches),
- "Open kon" (exact match) with relevance of 1.0,
comparing the three matches should result in
- "Konqueror" (equivalent relevance of 1.5),
- "Open kon" (equivalent relevance of 2), and
- "Konsole"
in ascending order.

After several more launches of konqueror, the service runner could
adjust the relevance of Konqueror and Konqueror could outrank the
other match, but still rank below the default match.

Any comments? :)

I started writing code for this a while back, but I had to stop for a
while because of school. If anyone thinks the ideas are fine I guess I
could start hacking on it again.

Cheers,
Ryan