Modeless dialogs in the shell (design and implementation)

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

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.



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]