Review Request: print-manager on kdereview

[Daniel Nicoletti]

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.

> If I understand mentioned bug correctly, it is not possible to fix the
> crash with the current design of kauth/polkit interaction, because the
> polkit frameworks expects the password dialog to run in its own
> processes.

It's not exactly a crash, the way s-c-p-kde is working today requires it to
run printer-applet as root (which is what some distros do), or have CUPS
not to ask password for local admin tasks (Ubuntu case), and in Debian
at the time I started print-manager it simply doesn't work. The reason
being that it couldn't show a CUPS password dialog and all cups
communication was in the GUI thread so it would block.. In other words
it wouldn't have an easy fix.

> If GNOME still uses polkit, how did they solve the out-of-process
> password dialogs?

s-c-p-gnome now uses polkit but I don't know exactly how does that work
and since CUPS has a method to handle password I think this makes
the problem much more complex.

>> kde workspace would be a good place to stay.
>
> Hm, kdeadmin is not moved to git yet, but I guess it still would be
> possible to create a "KDE Admin" project group.
Right, I'm really not sure about the location, since it's a hardware
component I'd say kde workspace under kcontrol dir seems a good
place but whatever helps packagers or anything is fine to me :)

Best,

-- 
Daniel Nicoletti

KDE Developer - http://dantti.wordpress.com