October 25, 2010
So in an effort to help make GNOME 3 turn out as good as possible, I’m helping figure out the story for system modal dialogs in the presence of the shell.
Anyway, I don’t really want to make this blog post about GNOME 3 as a development platform, but more about system modal dialogs. These dialogs are the things that should be dealt with “right away”. These are things that require the full attention of the user. As such, they should
- should appear front and center on screen
- should be clearly coming “from the OS” versus from an application
- should “take the stage” until dismissed
The idea is these are things that really can’t wait, be side lined, etc. In general, only the os “core” should ever need to present a system modal dialog.
Most dialogs should not be system modal, since most dialogs come from applications. Also, system modal dialogs have a very high “cost” to the user since by their very nature, they’re modal. That is to say, they preempt the user from whatever auxiliary tasks the user was doing and prevents those tasks from being available again until after the dialog is dealt with. In this regard, system modal dialogs should never be unexpected. They should always be the direct consequence of something the user was doing. For many use cases the message tray is a better option than system modal dialogs.
One example where system modal dialogs are very relevant is password dialogs. We really need password dialogs to have a consistent look that matches the look for the shell. This is important so that we can “train” the user into learning what a password dialog should look like, so they think twice before inputting their password into a dialog that’s not provided by the OS. This paves the way for a trusted path future. Of course, it’s only a step in the right direction. Actually getting trusted path is a hard problem that’s going to have to get solved at some point in the future. WHen that feature is seriously looked at, the final solution may involve one or more of: secure attention keys, wayland, factory mode login screens, integration with the users cell phone, or other possibilities
Another example of a dialog that should be system modal is the logout dialog.
Now, I just want to give a few details about where I’m going on the implementation side of things. Since we know that system modal dialogs need to “look like” the shell, they probably need to run in the shell process. (there’s no plan to make GTK+ have a “Look like the shell” mode etc). On the other hand, these dialogs are very tightly bound to the service that wants it. For instance, gnome-session is the only thing that should ever be able to summon the logout dialog for the shell. Everything else should talk to gnome-session.
Given how closely bound a dialog is to the particular service needing the dialog, ideally, its implementation should be easily adaptable to changes the service needs as the services needs them. While the look and feel both need to align with the shell, the contents of the dialog need are details almost entirely specific to the service requesting the dialog. The interface between the dialog and the service should be private and without any sort of backward compatibility constraints, etc. This means it would be best if we could ship the implementation for the dialog with the service. But how do we ship the implementation with the service and run that implementation in the shell?
There are some unresolved details on how these “private” extensions should differ from the more public, user installable extensions the extension system was originally designed for (like should the extension interface be different, should the private extensions show up in the extension list in the UI, etc).
This blog post is already getting a bit long, so I’m going to cut it off here. I’ll do another post at some point with some results from the above considerations.