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

[Giovanni Campagna <scampa giovanni gmail com>]

Il giorno lun, 27/09/2010 alle 14.55 -0400, William Jon McCann ha
scritto:
> 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.

Primarily, software-updates (asks if you update untrusted pkgs). Then
also installing hardware like printers needs authentication, or
autoconnecting to system networks.
But I see the desire of marking a dialog special when it asks for
password, and making it difficult for malware to spoof it. A good
compromise would be to notify "SomeApp requires authentication" and then
show the modal auth dialog when the related window is focused, and if
the requesting app is already focused (say it is a control center panel)
no notify is generated. This approach is similar to uac in windows 7,
which works quite well in my opinion.

> 
> > It is even more evident for bluetooth: in a public place I may be
> > contacted for many (malicious) paring requests, and I wouldn't like to
> > be even more annoyed by a modal dialog I cannot dismiss.
> 
> Interesting, I've never experienced that.  But anyway I don't think
> this is an example of something that we ever expected to be modal.  On
> the contrary, we have been moving things that aren't directly
> initiated by the user into the periphery.  A "request" from a third
> party isn't that different from a request from an application for
> attention from the user.  We want to empower the user to be in control
> of these types of potential distractions.  These situations are
> significantly different from ones where the user instructs the system
> to perform a task and more information is needed.  The bluetooth
> pairing request is probably better handed by the Message Tray.

Fully by the message tray? You mean, having the whole pin/password entry
as a specialized notification?
That looks good, and actually is a good way for doing modeless dialogs.
I did not originally think of it because it is often associated with
inactive notifications, but virtually anything that fits the design can
be placed there.
I think I will try implementing it like that. :)

Giovanni