[PATCH] RunnerManager

[Aaron J. Seigo]

On Thursday 24 April 2008, Jordi Polo wrote:
> IIUIC (*) QExplicitilySharedDataPointer makes the classes become basically
> alias. 

right; a ref-counted, shared pointer.

> So there are multiple names of the same data underneath. 
> QSharedDataPointer will try to share but if someone writes its own data,
> that means it is unique and distintive and it will protect that.

right.. it copies on any non-const access.

> will deprecate
> SearchContext::addMatchesTo(SearchContext &other), isn't it? 

hm.. yes, this might just work... since as soon as the term changes, we can 
call detach() on the dptr and cause it to create a copy. the really nice 
thing here is that it gives us a zero-copy system.

of course, this brings us right back to the original problem of how to deal 
with the completer. one approach would be to change from having the 
KCompletion object in SearchContext and just keep a list of possible 
completions...

*actually* ...... looking at it right now none of the runners actually uses 
the completion list at all. they just spew out matches. so we could probably 
out and out *remove* the completion object form SearchContext. yes, i like 
that even better. we can always add that functionality back if someone comes 
up with a good reason to use it in their runner; but it looks like i added 
this feature too soon and without a solid use case for it.

i still like going with the QExplicitlySharedDataPointer though because it 
gives us that zero copy effect!

-- 
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/20080424/622f0765/attachment.pgp