[Panel-devel] rfc on runner ordering

[Robert Knight]

> one approach would be to record the type of runner

What about runners that can return different types of result, the main
example being the search runner?  That might return mail, pictures,
misc. documents, contacts and probably more depending on the search
tool.

Depending on the kind of result it might have a different priority.

Regards,
Robert.

On 09/10/2007, Aaron J. Seigo <aseigo at kde.org> wrote:
> hi all ...
>
> i'm moving krunner/runners/ to plasma/runners, have moved the .desktop file to
> libs/plasma/servicetypes and changed the ServiceType from KRuner/Runner to
> Plasma/Runner. these changes are a follow-[up|through] with the move of the
> runner superclass to libplasma.
>
> i also added the webshortcuts runner after some modification so now we can
> launch urls and webshortcuts. hooray =)
>
> the final issue i approached tonight in krunner was how to order the runners
> at runtime. specifically, we want the search runner to always go last as it
> is (in theory anyways =) by defintion it returns the *least* specific set of
> results for any given string.
>
> so i implemented a really simple system: one can now set in the .desktop file
> whether it should go first, last or (by default) normal.
>
> this gets us to where the search is now sorted last ... however, i'm really
> not sure if it is what we want long term.
>
> one approach would be to record the type of runner (informational, executable,
> uri matcher, generic search .... ????) and order based on that. IOW, with
> this approach the runners would get ordered by what kind of results they
> return. i'm not sure that's valid, however, since it would be both hard to
> catch all possible types of runner (so future proofing would be difficult)
> and i'm not convinced there's a good enough corellation between the type of
> results a runner returns and what order its matches should appear in.
>
> another approach would be to use a numeric entry to sort on... so the search
> could have 1000000 or some other larger number so go last. the thing about
> *that* is then it's fairly non-deterministic if you start pulling in all
> sorts of third party entries.
>
> we could also sort all results at runtime and not rely on simply the order
> that the runners are loaded at all ... but i'm not sure what the criterion
> would be in that case. we do already do this for informational versus
> actionable and exact match vs best match ... but that's not particularly
> helpful for sorting across runners ...
>
> ultimately we could allow the user to select the ordering as well once we have
> the new configuration dialog in place (probably using kpluginselector for
> this?)
>
> so ... thoughts?
>
> --
> 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
>
> _______________________________________________
> Panel-devel mailing list
> Panel-devel at kde.org
> https://mail.kde.org/mailman/listinfo/panel-devel
>
>
>