of runners, API changes, future and world domination

[Jordi Polo]

2008/4/12 Aaron J. Seigo <aseigo at kde.org>:

> On Friday 11 April 2008, Jordi Polo wrote:
> > Also, we need extended type information.  To put an example, I`ve
> modified
> > (locally) the bookmark runner to also read the bookmarks of krdc and
> > konsole. So extra information should be added in the match as for
> konsole
> > bookmarks we surely are interested in konsole --workdir bookmark  or
> browse
> > it with dolphin.
>
> patch?
>

 Unfortunately I am traveling this weekend and don`t have my computer here,
I`ll send it on monday.



>
> > Aaron suggested some kind of hintting and delaying of hinted runners
> IIRC.
> > That may be a solution that preserve current interfaz but I`d like you
> to
> > consider further changes and get some discussion on the topic now that
> you
> > are meeting.
>
> could you provide some API examples of wht you are thinking about?
>

What I`d suggest is:

1 - Runners will have a defineType along with the current match and exec
methods.

2- The current type enum of SearchContext will be extended, possibly with
types from the ontologies of Nepomuk (it seems  possible and very attractive
but have to be sure). The type also will need extended information. For
instance, we got a directory type. But it we need as extended information
where the type came from. The ranking of the matches may vary depending on
if the directory was found in the bookmarks of konsole or konqueror.

3.- In fact, the previous point can be encapsulated in a new class with type
and data information. SearchContext will have a list of these classes.
Similar to current SearchMatch.

4.- As the user inputs text, each runner`s defineType will be called. Some
runners will have not need to define further. If the runner define or use a
command, it will add it to the list (saying that the user input has the type
command). So any command not defined by active and installed runner will not
be available.  Each runner will add guesses and the extended information to
the list of types of SearchContext.

5.- Even when defineType will be called for each runner, I am wondering if
it would be a good idea let the runners specify what types they are
interested in so match will be only be called when that types are in the
list. That will be useful for the future RunnerManagerGUI I guess. Also
matches can be ordered by type. For instance commands come first, unknown
type runners` matches come last.

 Summary: new method for runners and extended type info. An intermediate
step to get the type and distribute the accurate information to the runners.


For instance, the bookmark runner will have empty match and exec. As now it
will search the user input in the bookmarks and find the corresponding URL.
But it will do it in the defineType method, adding the URL and "konqueror as
the program the info came from" as information to the list of types. The
location runners and others will know how to manage that kind of information
and will not bother parsing.

So in practice, there will be runners with empty defineType, runners with
empty match and exec and runners that define both.