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

List:       kde-panel-devel
Subject:    Sharing SearchContext
From:       "Jordi Polo" <mumismo () gmail ! com>
Date:       2008-04-28 1:23:06
Message-ID: a4162420804271823w4ee0b516o12b14b893e9f575c () mail ! gmail ! com
[Download RAW message or body]

[Attachment #2 (multipart/alternative)]


Right now we have the concept of global context and the concept of local
context.
runners copy the global context in a local context, work with it and when
finished, use a SearchContext::addMatchesTo(SeachContext ) to add the
matches to the global shared context.
This means copies here and there, to avoid that, we can share data.
If we try to have shared data, we do not need to detach from the shared
object when:
-reading
-Adding matches
-Adding completions

We need to detach when:
- modifying the term. Which modifies the type and mime. And surely will
render matches and completions obsolete. So, instead of making a context
from other context it will be better just to initialize an unrelated
context. Modified term means a new context so we don't support detaching in
that case.

- deleting/clearing matches or completions. One context will not delete
other context matches. So what we want is to clear one given context
matches. Or what is the same: create a new context with already given term,
type and mime. Create a copy constructor that copies that info and
initialized a private clear matches /completions lists.


So basically,  detach can be avoided. We can always context1.addMatches(
context2.matches()) if it is needed to add matches from any new context to
an older one. (addMatchesTo will be deleted also).
So SearchContext will use internally a  QExplicitilySharedDataPointer and I
think there is no need to write a copy constructor but if it does I guess it
will be like:

SearchContext::SearchContext(const SearchContext &other, QObject *parent)
     : QObject(parent),
       d(new Private(Shared))
{
    other.d->lockForRead();
    //d=other.d;
    other.d->unlock
}

-- 
Jordi Polo Carres
NLP laboratory - NAIST
http://www.bahasara.org

[Attachment #5 (text/html)]

<br>Right now we have the concept of global context and the concept of local context. \
<br>runners copy the global context in a local context, work with it and when \
finished, use a SearchContext::addMatchesTo(SeachContext ) to add the matches to the \
global shared context. <br> This means copies here and there, to avoid that, we can \
share data. <br>If we try to have shared data, we do not need to detach from the \
shared object when:<br>-reading<br clear="all">-Adding matches<br>-Adding \
completions<br> <br>We need to detach when:<br>
- modifying the term. Which modifies the type and mime. And surely will
render matches and completions obsolete. So, instead of making a
context from other context it will be better just to initialize an
unrelated context. Modified term means a new context so we don&#39;t
support detaching in that case.<br><br>
- deleting/clearing matches or completions. One context will not delete
other context matches. So what we want is to clear one given context
matches. Or what is the same: create a new context with already given
term, type and mime. Create a copy constructor that copies that info
and initialized a private clear matches /completions lists. <br>
<br><br>So basically,&nbsp; detach can be avoided. We can always
context1.addMatches( context2.matches()) if it is needed to add matches
from any new context to an older one. (addMatchesTo will be deleted
also).<br>So SearchContext will use internally a&nbsp; QExplicitilySharedDataPointer \
and I think there is no need to write a copy constructor but if it does I guess it \
will be like:<br><br>SearchContext::SearchContext(const SearchContext &amp;other, \
QObject *parent)<br> &nbsp;&nbsp;&nbsp;&nbsp; : QObject(parent), \
<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; d(new \
Private(Shared))<br>{<br>&nbsp;&nbsp;&nbsp; \
other.d-&gt;lockForRead();<br>&nbsp;&nbsp;&nbsp; //d=other.d;<br>&nbsp;&nbsp;&nbsp; \
other.d-&gt;unlock<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]