Ray Strode

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.

Firstly, I have to say that working with the shell is really rather refreshing. It’s very neat to start with a “naked” dialog and write some CSS and see it morph into the mockups. It’s a totally different development experience but it feels really natural. Also, doings things in javascript is interesting, too. Being able to test changes without recompiling, etc, is a nice change of pace, and javascript as a language has some nice constructs (like for (key in hashTable) { … }) that make some programming tasks look tidier than what I’m used to. GObject introspection makes it really easy to talk to various libraries, too. There’s some stylistic things I don’t like about javascript (like camelCase), and there’s occasionally some googling to figure out the “javascript way”, but overall it’s a very pleasant platform to develop for.

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?

The shell already has a very powerful mechanism for extending itself. This extension system allows us to automatically load a custom javascript file and associated css stylesheet at startup. By leveraging this feature, gnome-session (for example) can ship its logout dialog right in its own source tree, change it whenever necessary without having to coordinate with the shell, and still achieve the “core os” look that’s important.

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

Now, even though we’ve decided the javascript should ship in the individual service source trees, there’s still the question of how the dialog and the service will communicate. Luckily, the javascript code has a great dbus binding called gjs-dbus that makes it pretty simple to export an interface on the session bus that each relevant service can talk to.

Another question is how much “heavy lifting” should be in the javascript code. I mean should the javascript dialogs just be dumb proxies of questions and answers between the user and service? Or alternatively, e.g., when the user clicks, shutdown should the javascript code implementing a shutdown dialog actually call out to ConsoleKit and initiate the shutdown in response to the user? I don’t think there’s any really right answer here. Certainly, given the support for gobject introspection and the convenient dbus bindings, a lot of low level things could be done straight from the dialog. There’s also something to be said for keeping the shell “lean” so there aren’t a lot of moving parts (with bugs) destabilizing something so fundamental to a functioning system. I think different services will have different amounts of “implementation” versus “presentation” in their extensions.

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.