Le lundi 27 septembre 2010 à 14:55 -0400, William Jon McCann a écrit : > Hi Giovanni, > > On Mon, Sep 27, 2010 at 10:33 AM, Giovanni Campagna > <[email protected]> wrote: > > Current design [1] reads that all dialog not related to applications are > > "system dialogs" and thus should be handled modally by gnome-shell. > > > > While this works for some of them, in particular for > > shutdown/restart/logoff, for others, like bluetooth auth/pairing or > > PolicyKit, it is wrong from a design point of view, IHMO. > > > > Consider PolicyKit for example: authentication requests should be opened > > in the background and only be modal for the application that needs them, > > so that I can launch a privileged task while doing something else at the > > same time. > > What applications are you thinking of here? Why would it be useful to > have a blocking authentication request in the background? I don't see > the advantage there. Regarding PolicyKit authentication dialogs at least, I also believe it would be better to make them modal only for the application they correspond to. See how the Windows Vista's UAC authentication thing is perceived as disruptive by users (it locks the whole desktop with a dim effect). In Ubuntu we had gksu, which also locked the whole desktop, and the move to PolicyKit made authentication much smoother IMHO.
There's no need to prevent user from switching to another application when authenticating. Rather, it gives a false sense of security to users: since any application is able to run such a system-modal dialog, a malware could have the exact same look and people will tend to trust them. Now, the problem is that it's hard to associate a PolicyKit dialog to a window. Maybe the API should be changed to pass the parent window to the daemon and back to the authentication agent. Not sure there are other solutions. Just my two cents _______________________________________________ gnome-shell-list mailing list [email protected] http://mail.gnome.org/mailman/listinfo/gnome-shell-list
