[PATCH] RunnerManager

[Jordi Polo]

New patch
http://www.bahasara.org/raw-attachment/wiki/Papers/krunner_patch2
Around 2000 lines. Getting too big to understand I guess, should I break it
? Most of it is related though.


Changes from the previous patch are:

- SearchContext now have a shared list of matches. When a local SeachContext
copies the global one, it is sharing everything.  If you think calling reset
should call detach():
- The local can start with a new SearchContext in that case
- Reviewing the changes right now I think that maybe the copy constructor
should create d with other->d.parent. This will allow for only call detach
on reset if the object is a copy shared with the original. But no on the
original. Note that as we don't know when the runners died, we don't know if
there are local SearchContext refering to d, around ...

- SearchContext now manages completions as a new type of match
CompletionMatch. All the completions related methods are gone. The
Kcompletion object is created in interface instead.

- added acceptsType and setUnacceptableTypes (yes, maybe the worst names
ever) to AbstractRunner. Runners can now specify what types they are not
interested in so not even a job is created for them. To achieve this the
SearchContext::Type must be OR'able. The concept is tested with the
calculator runner.

- Added support for krdc and konsole in bookmark runner




On Fri, Apr 25, 2008 at 12:40 PM, Jordi Polo <mumismo at gmail.com> wrote:

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



-- 
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/20080428/87b07b21/attachment-0001.html