Review Request: print-manager on kdereview

[Christoph Feck]

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.

> > 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,