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

[William Jon McCann <william jon mccann gmail com>]

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.

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

> Nonetheless, these are system dialogs and should be generated by the
> core desktop component. Also, for bluetooth, if bug 626759 is merged as
> it stands currently, there won't be an external session daemon that can
> possibly show modeless dialogs. Same could be for network, in an
> hypothetical GNOME 3.2 with NM 0.9 / 0.10, no gnome-panel and no GConf
> network settings. It is therefore clear that we need modeless dialogs
> generated by the shell process.
>
> Two possibilities I thought of: Gtk.Dialog or St.Dialog.
> The first one means using standard Gtk dialogs, which are decorated with
> the Metacity theme, can be stacked, focused, resized, etc. The problem
> with these, though, is that gnome-shell is actually mutter, a window
> manager, which cannot just create windows and expect them to have
> reparented/resized/mapped like any other client. In fact, creating a
> Gtk.Dialog hangs the shell, completely.
> The other option would be better from a themeability and integration
> point of view, as black St dialogs could be immediately told apart from
> commond Gtk ones, but currently there is no way to restack/resize/move a
> ClutterActor like it was a toplevel X11 window, making these essentialy
> modal and thus less usable.
>
> I'm not sure of what could be the right way forward, so I am asking you
> designers and developers what you think.
>
> Giovanni
>
> [1] http://live.gnome.org/GnomeShell/Design/Whiteboards/SystemDialogs

Jon