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