2012/8/27 Christoph Feck <christ...@maxiom.de>: > On Sunday 26 August 2012 06:34:30 Daniel Nicoletti wrote: >> 2012/8/25 Christoph Feck <christ...@maxiom.de>: >> > On Saturday 25 August 2012 04:29:19 Daniel Nicoletti wrote: >> >> 2012/8/23 Christoph Feck <christ...@maxiom.de>: >> >> > On Wednesday 22 August 2012 21:39:11 Daniel Nicoletti wrote: >> >> Well CUPS has it's own API for authorization, which is why I >> >> avoided the polkit solution s-c-p-gnome now uses. It wasn't easy >> >> to make it work right since CUPS API blocks, but it works >> >> reliable now that I wrapped it on a thread. >> > >> > Okey, so what you do in printer-manager is completely unrelated >> > to kauth. >> > >> > What I am interested in is, how we can use your knowledge to >> > avoid the mistake in the kauth design for frameworks. >> >> Hmm what kind of mistake are you talking about? I like polkit, but >> I don't think it fits CUPS design, for printd (a possible CUPS >> replacement) it will make all sense. > > 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). 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. 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. Best, Daniel