[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-core-devel
Subject:    Re: PolicyKit integration in KDE take 1: systemsettings and kcmshell
From:       dantti85-dev () yahoo ! com ! br
Date:       2009-03-10 14:41:08
Message-ID: 958050.27483.qm () web32102 ! mail ! mud ! yahoo ! com
[Download RAW message or body]


OK, i don't know if you already had any experience with
PolicyKit but i'll try to clarify this:

Any PolicyKit action has a Result,
simplifying you might have:
Yes|No|Auth 
(there are more but the others aren't important for users)
So the #2 and #3 would work this way in the apply button

(|"object-locker"| Apply) if the Result is Auth (the object-locker is an icon)
(Apply) disabled if the Result is No
(Apply) - without the locker icon if it's Yes.

the #3 option you said will always evaluate to YES,
normally the user must check "remember my passord".

And all this is automagically handled by polkit-qt, we just
need to pass a QAbstractButton to ActionButton, and set the
yes|No|Auth icons :D

Please ask if this didn't clarify the subject.

Daniel.




----- Mensagem original ----
De: Sebastian Kügler <sebas@kde.org>
Para: kde-core-devel@kde.org
Enviadas: Terça-feira, 10 de Março de 2009 10:53:03
Assunto: Re: PolicyKit integration in KDE take 1: systemsettings and kcmshell

On Monday 09 March 2009 18:38:30 Dario Freddi wrote:
>  - How to implement this on the GUI side? I thought about two options: 1)
> just make the "Apply" button call PolicyKit if needed 2) Add an "Unlock"
> button that makes all the widgets in the module active (just as GNOME
> does). I personally favor for the first, if we can get some nice icons
> (think about the shield in Vista).

I think we'll need to look at three cases here:

1 no password needed
2 password needed
3 password needed, but cached

For #1, it's probably fine to do it fully transparant. For #2, there should be 
an indicator that a password is needed, so a user that doesn't know the 
password won't bother changing anything just to be told "you're not allowed 
to".

#3 is a bit tricky, since in this case we get there are some consistency 
considerations, i.e. why does it sometimes require a password? It might make 
sense to fold this into 2 still, but then we get "why does it say it needs a 
password, but doesn't ask for it?", and along with it "did it actually work 
without the password (while it indicated it needs authorization)?"

Just some thoughts on those UI bits ... looking forward to your work hitting 
my machine :-)
-- 
sebas

http://www.kde.org | http://vizZzion.org |  GPG Key ID: 9119 0EF9 


      Veja quais são os assuntos do momento no Yahoo! +Buscados
http://br.maisbuscados.yahoo.com

[prev in list] [next in list] [prev in thread] [next in thread]