KCM Authorization (was: Re: Review Request: print-manager on kdereview)

[Christoph Feck]

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 
module"?

> 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).

> Best,
> Daniel