From kde-panel-devel Thu Jul 30 15:30:49 2009 From: "Ryan P. Bitanga" Date: Thu, 30 Jul 2009 15:30:49 +0000 To: kde-panel-devel Subject: Re: Issues with setupMatchSession/matchSessionComplete in Message-Id: X-MARC-Message: https://marc.info/?l=kde-panel-devel&m=124896791907977 On Thu, Jul 30, 2009 at 11:29 PM, Ryan P. Bitanga wrote: > On Thu, Jul 30, 2009 at 9:28 AM, Aaron J. Seigo wrote: >> On Wednesday 29 July 2009, Ryan P. Bitanga wrote: >>> On Thu, Jul 30, 2009 at 2:04 AM, Aaron J. Seigo wrote: >>> > On Wednesday 29 July 2009, Ryan P. Bitanga wrote: >>> >> On Thu, Jul 30, 2009 at 12:43 AM, Aaron J. Seigo 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. >> > Oh right... :) In that case apart from not removing the checkTeardown call in reset I think the patch is good to go. I mean removing the checkTeardown call in reset. - Ryan _______________________________________________ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel