Review Request: print-manager on kdereview

[Daniel Nicoletti]

2012/8/27 Christoph Feck <christoph at maxiom.de>:
> On Sunday 26 August 2012 06:34:30 Daniel Nicoletti wrote:
>> 2012/8/25 Christoph Feck <christoph at maxiom.de>:
>> > On Saturday 25 August 2012 04:29:19 Daniel Nicoletti wrote:
>> >> 2012/8/23 Christoph Feck <christoph at 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