[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-25 3:40:31
Message-ID: a4162420804242040xb37d990v41955b2d67af961 () mail ! gmail ! com
[Download RAW message or body]
[Attachment #2 (multipart/alternative)]
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
[Attachment #5 (text/html)]
<br><br><div class="gmail_quote">2008/4/25 Aaron J. Seigo <<a \
href="mailto:aseigo@kde.org">aseigo@kde.org</a>>:<br><blockquote \
class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt \
0pt 0.8ex; padding-left: 1ex;"> <div class="Ih2E3d">On Thursday 24 April 2008, Jordi \
Polo wrote:<br> </div><div class="Ih2E3d">> IIUIC (*) \
QExplicitilySharedDataPointer makes the classes become basically<br> > alias.<br>
<br>
</div>right; a ref-counted, shared pointer.<br>
<div class="Ih2E3d"><br>
> So there are multiple names of the same data underneath.<br>
> QSharedDataPointer will try to share but if someone writes its own data,<br>
> 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 class="Ih2E3d"><br>
> will deprecate<br>
> SearchContext::addMatchesTo(SearchContext &other), isn'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><br><a \
href="http://bugs.kde.org/show_bug.cgi?id=159596">http://bugs.kde.org/show_bug.cgi?id=159596</a><br><br>imagine \
: ¨konqueror /mnt/nfs"<br>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.<br> <br><br>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)<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;"> <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><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> <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><div></div><div class="Wj3C7c">Aaron J. Seigo<br>
humru othro a kohnu se<br>
GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA EE75 D6B7 2EB1 A7F1 DB43<br>
<br>
KDE core developer sponsored by Trolltech<br>
</div></div><br>_______________________________________________<br>
Panel-devel mailing list<br>
<a href="mailto:Panel-devel@kde.org">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></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