[PATCH] RunnerManager

[Jordi Polo]

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

> 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.
>

http://bugs.kde.org/show_bug.cgi?id=159596

imagine :  ¨konqueror /mnt/nfs"
I guess the most general approach is the  runner in charge of launching
konqueror is also in charge of autocompleting its arguments... Kdelibs has a
kfilecompleter or something similar, right? So the completer not being used
is more current runners fault than unneded preemptive design.


BTW, there is a mail in the mailing list called "more on information types",
I'd like an answer to that (so at least can finish the kbookmarks runner
patch)


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

Ok, done.
I get a crash in setHistory of the search term lineedit. May be related to
the completer somehow. Needs to investigate.



> --
> 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
>
> _______________________________________________
> Panel-devel mailing list
> Panel-devel at kde.org
> https://mail.kde.org/mailman/listinfo/panel-devel
>
>


-- 
Jordi Polo Carres
NLP laboratory - NAIST
http://www.bahasara.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.kde.org/pipermail/panel-devel/attachments/20080425/b3749bfd/attachment-0001.html