[PATCH] RunnerManager
Aaron J. Seigo
aseigo at kde.org
Mon Apr 21 17:35:43 CEST 2008
On Monday 21 April 2008, Jordi Polo wrote:
> If it is OK to submit it, I'll continue the development in SVN.
indeed; this patch is massive and invasive. maintaining such things outside of
a revision controled repo is very hard =/
having to read through a 50k patch with no prior explanations of what it is
doing isn't very nice either ..
so.. let's get this cleaned up and ready to go in. also, remember that you can
always start a branches in branches/ anytime you feel it's worthwhile.
> - The configuration. I want RunnerManager to configure itself. Potentially
> other programs not only krunner can use it. That means reading its own
> configuration file. I am not sure if the right approach is create a
> runnermanagerrc. So far There is a bunch of commented code in the
> constructor. Wait for advise.
runnermanagerc won't work since that means the same configuration for all
applications, unless each instance of RunnerManager gets its own
KConfigGroup. which we probably want anyways, since different RunnerManagers
may exist in the same app (concrete example: kickoff vs launcher applet)
> - So, user priority list and blacklist is not working (nor whitelist : the
> only regression I am aware about). That depends on the configuration point
> above. The code to implement it is there though.
yes, this is a detail at this point =)
> - I guess I have to write more comments, specially the interface of
> RunnerManager should improve.
yes, i'll provide a more detailed API review of this class in a separate
email.
> - Sometimes I hit some dbus out of memory errors -> investigate. I may
> resurrect the queueMatch idea.
dbus out of memory? hm. that's.. odd. where is dbus being used at all? ah, in
one of the runners you have installed, perhaps? in any case, when you
say "resurrect the queueMatch idea" can you explain what you replaced it
with, etc? i shouldn't have to reverse engineer your work when we're all here
on the same list ;)
other general comments:
* the copyrights in the file are wrong. you can't copy other people's code
from existing files and not carry the copyright over. so there are a few
copyrights missing there, probably Ryan's and mine for starters.
* i see that the call to processEvents is commented out. that's good because
you should NEVER call that unless there are very, very good reasons to.
processEvents is evil, evil, evil and reserved only as an Escape Route From
Some Other Level Of Hell ;)
* in the copy ctor for Context, the completer object is no longer copied over.
at the very least the completions registered should be copied over.
* using launchQuery as both async and sync should be avoided IMHO. make two
different methods: one that spawns threads and one that doesn't. call the
latter one execQuery.
* returning an integer from a method as seen in launchQuery is nasty. return a
boolean or use a proper enumeration if an error code is needed. right now i
only see 0 and 1, so a bool would be appropriate. this is C++ after all.
* RunnerManager::getRunner is O(N). if it gets called often and N grows large
(which we probably hope it does ;), this could be an issue. it's probably
premature to optimize this (by using a name->Runner mapping/hash instead of a
simple list) but it's probably worthwhile to at least put a comment there
noting this problem. at some point we should go count how often this gets
called to find out if isuch an optimization is worthwhile in the Real
World(tm).
* in the RunnerManager ctor there is this:
+ d->runners += load();
load() should simply clear d->runners and set d->runners itself. this will
open the door to changes in configuration down the road as well (just call
load() again ..)
* please be careful with the coding style. there are a lot of instances where
whitespace is missing, e.g.:
+ bool emptyMatches=matches.isEmpty();
which should be
+ bool emptyMatches = matches.isEmpty();
--
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/20080421/1ec8feda/attachment.pgp
More information about the Panel-devel
mailing list