[Panel-devel] Proposal for changes to KRunner

[Aaron J. Seigo]

On Sunday 18 November 2007, Ryan Bitanga wrote:
> Anyway, here it goes:
> Since SearchAction is the main matched item class, it really
> represents a noun and not an action.

this is a bit of a literal, and perhaps not entirely accurate, interpretation 
of the class name. it's SearchAction because it represents an action to be 
taken if the user selects that match. it really has nothing to do with 
noun/verb, and indeed some of SearchActions returned by runners are certainly 
action sounding "phrases".

> 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.

have you done any benchmarking on how fast/slow QAction creation is? of 
course, fetchActions would have to create the actions so we're left with 
creating two objects (including the QAction) instead of just one. so this 
would, if fetchActions is used, actually be slower and more memory intensive 
than simply creating QActions in the first place.

> Within fetchActions(), the runner can determine which actions to
> provide to krunner based on mimetype, etc., allowing runners to be
> more flexible.

i'm not sure i understand exactly what you're trying to achieve here, but if 
i'm getting it right: you're looking for a second-pass run, where runners can 
process the matches of other runners? filter runners or action-augmenting 
runners?

> 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.

this is a great idea, however also one that is already possible with a 
UserActions (or whatever) runner. the only thing missing is having a second 
pass run on SearchActions that are returned.

where -that- gets tricky is that SearchActions then have to have enough 
information in them to make it feasible to reliably process them by other 
runners. as it is right now, but most SearchActions only have meaning to the 
runner they come from.

so making SearchAction more expressive would probably be a good first step.

> 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.

the benefit of subclassing qaction is being able to use it in a number 
flexible ways, including direct invocation via triggered() and by putting it 
into widgets that accept QActions (which is all of them).

it also gives us an API that any Qt developer would be familiar with.

what exactly is the benefit of not using QAction?

> 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

exact and possible have almost nothing to do with the default match. if a 
runner determines that "konsole" is an "exact match" for "kon" then it can 
say so.

i have been considering moving the default action selection out of krunner 
itself and into SearchContext

> 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).

runners already have no clue what the default match is =)

> 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.

this could, of course, be done with the current design.

-- 
Aaron J. Seigo
humru othro a kohnu se
GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA  EE75 D6B7 2EB1 A7F1 DB43

KDE core developer sponsored by Trolltech
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://mail.kde.org/pipermail/panel-devel/attachments/20071118/3f0eb349/attachment.pgp