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.


July 30, 2010

So Mo and I finally got engaged.

us together
(an oldish photo of us together)

Her ring

(Mo’s engagment ring!)

Plymouth ⟶ X transition

November 28, 2009

So one of the big polish bits in the boot process is the transition from plymouth to X. In Fedora, we worked to make it as seemless as possible when we first started on the Better Startup stuff a few releases ago.

If you haven’t seen it, when boot up finishes, plymouth settles down the boot splash to a transitionable animation frame, then the mouse pointer shows up, and GDM’s background cross fades in while the login window maps and expands to show frequently logged in users. In the best case, this transition all happens without any flicker, resolution changes, black intermediate screens, or console text showing up.

The way we accomplished this was:

  1. I gave “plymouth quit” a “–retain-splash” option which told plymouth to keep the boot splash’s contents on screen even after plymouth exits
  2. krh and ajax added a -nr option to the X server to make X not clear the screen to black (or a weave) at start up
  3. krh, airlied, and darktama (Ben Skeggs) added the driver backend support for -nr to intel, ati, and nouveau drivers respectiviely. Also, Bill Nottingham made -nr work with the fbdev X driver.
  4. ajax made the ugly big “X” mouse cursor not show up by default
  5. I made gdm stuff the screen contents to a pixmap referenced by the pseudo-standard _XROOTPMAP_ID root window property
  6. I also made gnome-settings-daemon cross fade from the _XROOTPMAP_ID pixmap when it loads its background. This step meant we also get a nice transition from gdm to the user’s session, because it also causes a crossfade to happen from gdm’s background to the user’s background during login.

Another big piece to the puzzle was kernel modesetting. This is what makes sure the right mode is set at boot up from the start. Jesse Barnes and krh did most of the work for that in the Intel driver (based on top of the memory manager work anholt, keithp, and other Intel crew did), while airlied did it for the ati driver, and darktama did it for nouveau.

This all works pretty well these days, but one big wrinkle in the whole process is the hand off from plymouth to gdm. Plymouth exits, leaving the system in KD_GRAPHICS mode and hopes that X starts and picks up the peices. This is not a very robust design, because if X doesn’t start, the system will be stuck in KD_GRAPHICS mode and the user won’t be able to switch VTs or really do anything at all, but reboot.

Furthermore, when plymouth exits, the kernel sets the scan out buffer to the frame buffer of the console. This is because the previous scan out buffer was owned by plymouth and goes away when plymouth exits. That means in order to keep things seemless we need to copy the last frame of the animation from plymouth’s framebuffer to the console frame buffer. This extra copy is unfortunate, because it means the kernel console has to be configured the same way as plymouth, but in multihead set ups it’s not. The kernel console “clones” the ttys across all heads, forcing every head to be the same resolution. But plymouth (and X) want every head to run in native resolution. This means in multihead setups we can’t do the copy because the pixel layouts aren’t the same, so we end up filling with black instead.

I’ve wanted to improve this situation for a while, but haven’t really been able to prioritize it above other various bits of work that need to be done. Since I’m on Thanksgiving break I can, in good conscience, ignore my priority list and just work on what I want, so I decided to work on this problem a bit :-)

I just merged the “no-fbcon” branch to plymouth master. It adds a new way to “deactivate” plymouth such that it’s still on screen and idly running, but X can start and take over anyway. This combined with some gdm changes to tell plymouth to go away in the appropriate way after X is started or fails to start means we solve the robustness issues and avoid the extra fbcon copy.

It actually only took a few hours to do. I probably should have made time for it before break.

Fedora 12

November 17, 2009

So Fedora 12 is finally out. Give it a try.

It shaped up to be a pretty good release I think.

Fedora 10

November 25, 2008

So, just a quick note to say Fedora 10 is out.

If you haven’t tried Fedora in a while, and you’re curious give the live image a try on a USB stick.

Linux is not about choice

January 9, 2008

So I came across a really interesting mailing list post by ajax today. He’s totally right and it’s refreshing to see…

an unexpected turn of events

December 21, 2007

So, I am totally surprised to see that Matthew Szulik is stepping down as Red Hat’s CEO.  I wonder what comes next…

Congrats Dave

September 30, 2007

So I just wanted to publically say congratulations to my friend, Dave Malcolm (of Conglomerate, Evolution, and Dogtail fame), since he’s going to be marrying a great woman soon.

Congrats Dave!

Experimental LiveCD

August 18, 2007

So the desktop team here at Red Hat has decided we want a little more freedom in trying new ideas for Fedora. We can’t put radical changes into the main Fedora spin, because those types of changes often require make choices for the user that may alienate someone who currently uses Fedora.

Since Fedora 7, users of Fedora have had the ability to do custom spins pretty easily. Using that same infrastructure we (the desktop team) are going to do our own spin that tries various things, like disabling the root account, and not asking the user what partitioning scheme they want. Presumably, some of these ideas won’t work out, but it’s nice to have a play area where we can experiment and find the things the really work.

The key here is that we’re try to narrow the scope of the spin. It will specifically be ill-suited for a lot of users who happily use Fedora. Those users can keep using the mainline spin, though.

Aside from that we started a Desktop “Special Interest Group” (SIG) so that people outside of Red Hat can get more involved. We now hold weekly meetings on IRC.

Anyway, discussion about what should happen on the LiveCD happens on fedora-desktop-list

subway entertainment

August 2, 2007

So there is a really cheap/yummy falafel place in Central Square I sometimes like to go to. Today I walked out of there with Falafel roll up and made my way down into the T to get home to Davis Square. The train went want stop to Harvard when a guy comes on and starts screaming:

guy: Attention everybody, attention everybody I’m about to dance
guy puts down boom box
guy: now I have three rules first. 1) If I do something you like, clap 2) If I do something you don’t like, clap 3) when I’m done, show your appreciation with donations or love. Hint: ladies, I’m single.
guy taps boom box to get it started
guy then does a series of back flips, double flips, hand springs and break dancing

It was pretty damn cool to see.