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