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

List:       kde-panel-devel
Subject:    Re: Issues with setupMatchSession/matchSessionComplete in
From:       "Aaron J. Seigo" <aseigo () kde ! org>
Date:       2009-07-30 1:28:28
Message-ID: 200907291928.29322.aseigo () kde ! org
[Download RAW message or body]

[Attachment #2 (multipart/signed)]


On Wednesday 29 July 2009, Ryan P. Bitanga wrote:
> On Thu, Jul 30, 2009 at 2:04 AM, Aaron J. Seigo<aseigo@kde.org> wrote:
> > On Wednesday 29 July 2009, Ryan P. Bitanga wrote:
> >> On Thu, Jul 30, 2009 at 12:43 AM, Aaron J. Seigo<aseigo@kde.org> wrote:
> >> > On Wednesday 29 July 2009, Ryan P. Bitanga wrote:
> >>
> >> so I think the best place to do this would be in
> >> the destructor of FindMatchesJob. We'd check if the queue is empty,
> >> and if it is then we can emit the teardown signal.
> >
> > there'd be some corner cases there, such as if there are no
> > FindMatchesJobs when teardown is requested ... how about in
> > RunnerManagerPrivate::jobDone()? see attached patch...
>
> I like the fact that this keeps everything in RunnerManager instead of
> having the logic separated between files. Doesn't this suffer from the
> same problem though? If there are no jobs to begin with, the slot
> won't be called.

that's why there's a call to checkTearDown() in 
RunnerManager::matchSessionComplete(). if there are no jobs running, 
checkTearDown() will run immediately. otherwise, it will wait until the jobs 
are all done.

> >> Agreed, but the use case that came to mind while I was writing this
> >> e-mail is that of the window runner. It caches the data once a query
> >> is launched but the data may become invalid while the dialog is open
> >> (e.g. an application is launched/closed while the dialog is open). But
> >> this is an issue addressable in the runner implementation.
> >
> > yes; in this case the setup/teardown lets the runner know that it should
> > start watching for those changes as well. if the data can't be trusted
> > between runs (meaning that there is no way to detect changes and the data
> > may change) then the runner will have to re-load the data in match no
> > matter what we do :)
>
> Just for clarity I think we should put that in the apidocs. :)

sure :)

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

["signature.asc" (application/pgp-signature)]

_______________________________________________
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel


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