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.
July 30, 2010
So Mo and I finally got engaged.
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:
- I gave “plymouth quit” a “–retain-splash” option which told plymouth to keep the boot splash’s contents on screen even after plymouth exits
- 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
- 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.
- ajax made the ugly big “X” mouse cursor not show up by default
- I made gdm stuff the screen contents to a pixmap referenced by the pseudo-standard _XROOTPMAP_ID root window property
- 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.
November 17, 2009
November 25, 2008
January 9, 2008
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…
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.
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
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.