System Modal Dialogs

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.

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.

9 Responses to “System Modal Dialogs”

  1. Travis Paul Says:

    I’ve really been enjoying accessing the GTK and Clutter Libraries through Javascript as well.

    Has Gnome made a decision as to which Javascript Engine the are going to be using in Gnome 3? I know there is Seed (Chromium/V8) and Gjs (SpiderMonkey/Mozilla) did they pick one or are they including both?

  2. Stef Walter Says:

    I’m really interested in working with you on the gnome-keyring password dialog integration with the shell.

    I’m stefw on irc or

  3. halfline Says:

    I think the near term plan is “both” but I’m not 100% sure. That’s less than optimal, and at some point it makes a lot of sense to standardize on one. I just doubt that’s going to happen before GA. I’m not really the right person to ask, though, I just have some vague notion of this getting discussed a few months back on desktop-devel-list. It might be worth bring it up again there.

  4. oOarthurOo Says:

    I thought the shell was going to be removable for people who wanted the more traditional look and feel of 2.x … supposedly you can still run a gnome-panel, nautilus metacity type setup. Is that wrong? If not, how will your model things work in the absence of -g-s?

  5. Michael Kanis Says:

    Why should the logout dialog be modal? Could you please explain this, if you claim it? I don’t see an explanation for password dialogs, either, but I guess it has something to do with focus stealing. As you say, modal dialogs should be used rarely, so, please, before making dialogs modal, elaborate, if this is really necessary!

    • halfline Says:

      • One feature of the current log out dialog (which is also present in the new logout dialog design) is a timer to automatically log out 60 seconds after the logout dialog is presented. This is to safeguard against the user hitting logout and walking away. So because of this feature, the logout dialog is something that needs immediate attention.
      • If the user is trying to logout then they are probably doing that because they are “done” with the system, so I think there’s little advantage for it to be modeless.

      Do you have a use case in mind that wouldn’t work if the logout dialog was modal?

  6. John Says:

    I noticed in the CSS that “Cantarell” is used for most items, but “Cantarella” is defined for the StButton.

    I’m not sure if this is an error or if there are two variants of the font. You’ve probably already seen that, but thought I’d mention it.

    But this brings up a couple of questions: If the font family (and other attributes) is hard-coded in the CSS, and the CSS is going to be shipped with gnome-session, then how is theming going to work? Likewise, how will the design be kept consistent throughout the shell and across updates if CSS and JS are scattered across packages?

  7. Fizzy Says:

    I agree that there’s no need for the logout dialog to be modal. The countdown timer is something that GNOME directly copied from OS X, but the logout dialog in OS X is modeless… and Apple tend to know what they’re doing with this sort of thing. I’ve certainly occasionally found it useful to be able to do a bit of final “tidying up” before the logout actually happens.

Leave a Reply