[PATCH] RunnerManager

[Aaron J. Seigo]

On Tuesday 22 April 2008, Ryan P. Bitanga wrote:
> I don't see why a user would expect results to come in a defined order
> all the time. The way launchers work is that the matches are
> incrementally added.

two points:

* we're usually talking in terms of 100s of milliseconds. to a user, this is 
next to irrelevant.

* this problem is why we have *sorting* of matches. that's why there is a 
relevancy rating. etc... 

stop thinking about it in terms of order of arrival and start thinking in 
terms of sorting the collection of matches as they arrive in whatever order.

not only does this make solving this particular problem easier, it also lets 
us completely decouple the way runners work internally, the collection 
mechanism (aka the manager class) and the visualization (e.g. krunner). 
anything that tries to dictate an end-to-end predictability will innevitably 
couple the steps together more tightly.

let's not paint ourselves into a corner here.

> Of course quicker runners will provide matches 
> first. I don't see this as a problem. In fact, the speed of the runner
> may vary from query to query and the only way to have results appear
> in a defined order all the time would be to process them sequentially.

.. which we don't want.

 there's no way to accurately predict which runner has priority since that 
depends on the meaning of the query to the runner, so the ordering will 
inherently change from run to run.

> On second thought we could add dependencies. Shouldn't be that
> difficult. It isn't as tricky as you might think it is.

i don't think dependencies are necessary.

> important? Again it could be possible to sort the results instead.
> You'd need a custom operator<.

... which already exists in krunner/interface.cpp. it just needs to be moved 
to Plasma::SearchMatch to be easily reusable.

-- 
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: 194 bytes
Desc: This is a digitally signed message part.
Url : http://mail.kde.org/pipermail/panel-devel/attachments/20080422/d580be4a/attachment.pgp