KRunner config dialog

[Aaron J. Seigo]

On Wednesday 07 May 2008, Ryan P. Bitanga wrote:
> My patch will be a little bit delayed yet again due to conflicting
> changes in libplasma.

which classes are you working on, so we can avoid hitting the same ones? can 
you post a draft patch so we can sync up with ideas? i'm concerned that 
waiting on your patch will hold up mainline development, but not holding up 
mainline development will hold up waiting on your patch (both due to 
integration of moving targets).

so .. i'd suggest getting your patch up sooner rather than later.

> Similarly I also used id() for getting KPluginInfo->pluginName because
> I needed it for reloading configs of a specific runner.

right =)

> * Added a reparseConfiguration method to AbstractRunner to reload the
> config of a specific runner.

loadConfiguration()?

> * Got rid of runner phase. Use
> setPriority(AbstractRunner::HighestPriority) for first runners, etc.
> instead

+1

> * Got rid of the blacklist and revamped the load function. (Whitelists
> make more sense since the default behavior should be "plugin disabled
> by default" ie X-KDE-PluginInfo-EnabledByDefault=false)

i'm really on the fence on this one. white lists mean newly added runners 
aren't automatically picked up; that actually isn't what we want here. we 
should listen to EnabledByDefault, but the default should be enabled. 
krunner's usefulness is really based on this concept.

> I'll make a more detailed list as soon as I finish fixing everything.

are you working just locally, or do you have an svn branch or git repo 
somewhere?

> Just a little question, what did we gain by sharing searchcontext? The

avoiding lots of list manipulations and memory allocations. we also no longer 
have to check if the local context matches the global context; we get that 
for free now when we detach() (the fact that they are not the same is now 
implicit in that action).

> point of performMatch and local searchcontexts was to reduce the locks
> on the searchcontext. Currently, we still lock everytime we add a
> match 

in practice we still locked everything we added matches: when agregating to 
the global context. that locking was also compounded by comparing terms (more 
locking) and then add to one QList and destroying another.

we really do need to look into the locking details in QueryContext, but 
currently things feel a lot smoother in the UI and memory usage should also 
be down.

the downside here is that if you repeatedly call addMatch() versus 
addMatches() then we'll get more locks than before. however, all the runners 
currently use addMatches(). i'm of the opinion that calling addMatch when you 
have multiple matches is an abuse of the API. i've toyed with removing 
addMatch() altogether, but while that would encourage runner writers to do 
the Right Thing(tm) always (only calling addMatch* once), it would also 
result in a lot of unecessary QList<QueryMatch*>s being made. i think we need 
to trust the developer a bit in this case.

also, i've noticed that addMatches *probably* doesn't require checking the 
query string anymore. i need to test that theory, however. if it is true, 
that would get rid of another (read) lock.

note that performMatch is also used for rate limiting, of course, so it 
retains its usefulness.

> and DataPolicy is useless. 

yes, it isn't used at the moment.

-- 
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/20080507/c3c797bc/attachment.pgp