[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-panel-devel
Subject:    Re: [PATCH] RunnerManager
From:       "Jordi Polo" <mumismo () gmail ! com>
Date:       2008-04-28 14:24:43
Message-ID: a4162420804280724k7163c844jbd5a9f921381fcd9 () mail ! gmail ! com
[Download RAW message or body]

[Attachment #2 (multipart/alternative)]


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@gmail.com> wrote:

>
>
> 2008/4/25 Aaron J. Seigo <aseigo@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@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

[Attachment #5 (text/html)]

<br><br>New patch<br><a \
href="http://www.bahasara.org/raw-attachment/wiki/Papers/krunner_patch2">http://www.bahasara.org/raw-attachment/wiki/Papers/krunner_patch2</a><br>Around \
2000 lines. Getting too big to understand I guess, should I break it ? Most of it is \
related though. <br> <br><br>Changes from the previous patch are:<br><br>- \
SearchContext now have a shared list of matches. When a local SeachContext copies the \
global one, it is sharing everything.&nbsp; If you think calling reset should call \
                detach():<br>
- The local can start with a new SearchContext in that case<br>- Reviewing the \
changes right now I think that maybe the copy constructor should create d with \
other-&gt;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&#39;t know \
when the runners died, we don&#39;t know if there are local SearchContext refering to \
d, around ...<br> <br>- 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. <br><br>- 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&#39;able. The concept is tested with the \
calculator runner. <br> <br>- Added support for krdc and konsole in bookmark runner \
<br><br><br><br><br><div class="gmail_quote">On Fri, Apr 25, 2008 at 12:40 PM, Jordi \
Polo &lt;<a href="mailto:mumismo@gmail.com">mumismo@gmail.com</a>&gt; wrote:<br> \
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); \
margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><br><br><div \
class="gmail_quote">2008/4/25 Aaron J. Seigo &lt;<a href="mailto:aseigo@kde.org" \
target="_blank">aseigo@kde.org</a>&gt;:<div class="Ih2E3d"> <br><blockquote \
class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt \
0pt 0.8ex; padding-left: 1ex;"> <div>On Thursday 24 April 2008, Jordi Polo wrote:<br>
</div><div>&gt; IIUIC (*) QExplicitilySharedDataPointer makes the classes become \
basically<br> &gt; alias.<br>
<br>
</div>right; a ref-counted, shared pointer.<br>
<div><br>
&gt; So there are multiple names of the same data underneath.<br>
&gt; QSharedDataPointer will try to share but if someone writes its own data,<br>
&gt; that means it is unique and distintive and it will protect that.<br>
<br>
</div>right.. it copies on any non-const access.<br>
<div><br>
&gt; will deprecate<br>
&gt; SearchContext::addMatchesTo(SearchContext &amp;other), isn&#39;t it?<br>
<br>
</div>hm.. yes, this might just work... since as soon as the term changes, we can<br>
call detach() on the dptr and cause it to create a copy. the really nice<br>
thing here is that it gives us a zero-copy system.<br>
<br>
of course, this brings us right back to the original problem of how to deal<br>
with the completer. one approach would be to change from having the<br>
KCompletion object in SearchContext and just keep a list of possible<br>
completions...<br>
<br>
*actually* ...... looking at it right now none of the runners actually uses<br>
the completion list at all. they just spew out matches. so we could probably<br>
out and out *remove* the completion object form SearchContext. yes, i like<br>
that even better. we can always add that functionality back if someone comes<br>
up with a good reason to use it in their runner; but it looks like i added<br>
this feature too soon and without a solid use case for it.<br>
</blockquote></div><div><br><a href="http://bugs.kde.org/show_bug.cgi?id=159596" \
target="_blank">http://bugs.kde.org/show_bug.cgi?id=159596</a><br><br>imagine :&nbsp; \
¨konqueror /mnt/nfs&quot;<br>I guess the most general approach is the&nbsp; 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.<br>

&nbsp;<br><br>BTW, there is a mail in the mailing list called &quot;more on \
information types&quot;, I&#39;d like an answer to that (so at least can finish the \
kbookmarks runner patch)<br><br></div><div class="Ih2E3d"><blockquote \
class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt \
0pt 0.8ex; padding-left: 1ex;">

<br>
i still like going with the QExplicitlySharedDataPointer though because it<br>
gives us that zero copy effect!<br>
<font color="#888888"></font></blockquote></div><div><br>Ok, done. <br>I get a crash \
in setHistory of the search term lineedit. May be related to the completer somehow. \
Needs to investigate. <br>&nbsp;<br><br></div><blockquote class="gmail_quote" \
style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; \
padding-left: 1ex;">

<font color="#888888"><br>
--<br>
</font><div class="Ih2E3d"><div><div></div><div>Aaron J. Seigo<br>
humru othro a kohnu se<br>
GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA &nbsp;EE75 D6B7 2EB1 A7F1 DB43<br>
<br>
KDE core developer sponsored by Trolltech<br>
</div></div><br></div><div \
class="Ih2E3d">_______________________________________________<br> Panel-devel \
mailing list<br> <a href="mailto:Panel-devel@kde.org" \
target="_blank">Panel-devel@kde.org</a><br> <a \
href="https://mail.kde.org/mailman/listinfo/panel-devel" \
target="_blank">https://mail.kde.org/mailman/listinfo/panel-devel</a><br> \
<br></div></blockquote></div><div><div></div><div class="Wj3C7c"><br><br \
clear="all"><br>-- <br>Jordi Polo Carres<br>NLP laboratory - NAIST<br><a \
href="http://www.bahasara.org" target="_blank">http://www.bahasara.org</a><br>

</div></div></blockquote></div><br><br clear="all"><br>-- <br>Jordi Polo \
Carres<br>NLP laboratory - NAIST<br><a \
href="http://www.bahasara.org">http://www.bahasara.org</a><br>



_______________________________________________
Panel-devel mailing list
Panel-devel@kde.org
https://mail.kde.org/mailman/listinfo/panel-devel


[prev in list] [next in list] [prev in thread] [next in thread] 

Configure | About | News | Add a list | Sponsored by KoreLogic