Re: Modeless dialogs in the shell (design and implementation)

[Milan Bouchet-Valat <nalimilan club fr>]

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
> <scampa giovanni gmail com> 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