Ray Strode

So this is kind of interesting:

http://badges.fedoraproject.org/

Fedora is rolling out a system where contributors get badges for doing various things (like doing package builds, or tagging keywords to software, or editing the wiki).

So I just wanted to give a quick git tip, since I see people give them occasionally and I find those posts useful for me.

It’s often important to try find a commit where something was introduced originally. This is good for figuring out what commit to squash to fix up to, or for doing code archaeology to figure out context beside why a certain piece of code exists. I see a lot of people use git log –grep or git log -S. Those commands are nice and there is nothing wrong with them. I don’t usually like using them, though. I prefer:

git log -p

This will show you every commit message and patch in reverse chronological order paged through less. less has powerful search features built in. So you can for instance type:

/^\+.*my_function


to search for the last instance of when my_function was added in the code. If you hit "n" it will jump to the next to last instance, and so on. If you decide you want to seek backward over an entry you already went past you can do "?" and then "n" repeatedly. "/" to seek forward again.

Why do I like this better?

• Because it’s interactive and more flexible. You can switch search terms mid-stream (tell me when bar() was called, but only before foo() was implemented in history)
• Because it lets you see the surrounding commits. Seeing a commit in isolation is useful, but being able to see the commits that went in along side it is often invaluable for gleaning context into the motivation behind the commit.

Okay one more quickie: Another option that’s useful to throw before the "-p" in "git log -p" is "-U30". This amps up the amount of diff context surrounding the changes introduced in a patch, often making those changes imminently more clear. It’s no fun to see a patch that modifies the middle part of a function, and not being able to see what the function does.

So that’s my git tip.

So Allan posted a pretty good summary of all the cool goings ons in shell land right now.

I thought I’d just follow up with a quick video showing two of the work-in-progress features, the login screen and the on screen keyboard.

As promised in my last post I’m going to do a follow up post with more details about where GDM is going in 3.2, but for now just the quick video: (click here)

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.

So Mo and I finally got engaged.

(an oldish photo of us together)


(Mo’s engagment ring!)

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.

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

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