KRunner config dialog

[Ryan P. Bitanga]

2008/5/7 Jordi Polo <mumismo at gmail.com>:
>
> ?
> Where? AbstractRunner already has the name() method and if you added the
> reparseConfiguration method I don't know why you need that outside
> AbstractRunner.

I added my own id() method :) You need it outside AbstractRunner bec
the config dialog is a KCModule. You can't access the runner itself.

>
> That will mean that when installing a new runner any program using runners
> should be configured to use it...
Which is the preferred behavior for plugins. You wouldn't want a KWin
effect enabled by default. The same is true for plugins for other
applications.

> IMHO, blacklisting is better. If a new program that uses runners is
> installed it will use every runner of the system unless specifically stated
> otherwise by the user.

The way this works is KPluginSelector stores entries in the config
file. It's easier to have a whitelist generated by going through these
entries and selecting those set to true because most will say false.
See above.

It's better to have an option that says load all but otherwise default
to only enabling those selected by the user.

>
> > Just a little question, what did we gain by sharing searchcontext? The
> > point of performMatch and local searchcontexts was to reduce the locks
> > on the searchcontext. Currently, we still lock everytime we add a
> > match and DataPolicy is useless.
>
> We also locked previously when calling addMatchesTo(), the main benefict is
> that local SearchContext share the data instead of copying it. So we have
> effectively _one_ shared list instead of a global list where multiple local
> list copied their data.
>

My point was this was the original setup before I added performMatch
to reduce the locks as Aaron suggested last year. Back then, we added
matches directly to a global searchcontext.

Cheers,
Ryan