KCM Authorization (was: Re: Review Request: print-manager on kdereview)
christoph at maxiom.de
Mon Aug 27 21:37:59 BST 2012
On Monday 27 August 2012 22:15:18 Daniel Nicoletti wrote:
> 2012/8/27 Christoph Feck <christoph at maxiom.de>:
> > I am talking about whatever design mistake is responsible for bug
> > 242648, which isn't about CUPS at all. Sorry for side-tracking
> > this thread. I was just thinking that with your expertise on the
> > authorization-related stuff, we could plan better for the
> > future, so that we don't carry this bug over to frameworks.
> Ah ok, it's a completely different issue. Now from the backtrace
> you already know the issue is due to event loops, I didn't look
> further but the bugs I had with Apper is because SystemSettings
> call accept on the open module, then the accept opens an event
> loop (otherwise returning will close SystemSettings).
You already lost me here. What do you mean with "call accept on the
> So to fix this I maybe on KAuth or in SytemSettings a QPoiter
> needs to check if the event loop is valid. Maybe the KCM could
> pass an event that can be event->accept() to avoid blocking the
> call with an event loop.
Actually, I was always thinking the bug was because there was no
blocking. If I follow the bug descriptions correctly, it looks like
people can close System Settings, without the password dialog going
away, because it is a separate process that isn't informed by KAuth
framework while it waits for input. But maybe I am talking stuss ...
> This is going a bit out of the scope of the thread but if you want
> I can take a closer look to the issue.
No need to hurry, it's only 210 duplicates, which is far from crash #1
with 322 duplicates ;)
The only problem I see is with triaging. I stopped resolving as a
direct duplicate long ago, in order not to flood hundreds of reporters
for each additional duplicate, but I do not like this solution
(duplicates.cgi still counts them, though).
More information about the kde-core-devel