GNOME Summit went really well, and I had a great time. One thing that I was really heartened to see is that we’ve agreed on a GLib/dbus plan, and this will enable a number of cool things. First, dbus-glib is just not very good, and we’ve needed a better story. I hadn’t realized before just how much nicer GVariant can make doing DBus calls. But beyond that, having DBus underneath the GTK+ stack will better unlock things like GApplication which will in turn let us do nifty things like exporting GtkAction over the bus. If that’s still a bit abstract, look at say Stuart Langridge’s post on Linglish.

…it turns out someone on the Interwebs already did it. Curse you interwebs for how easily you crush one’s brief pretensions to originality. Anyways, in GNOME Shell we finally got bug 589652 in which means we’re ready for translations! We don’t have a lot of strings, but it’d be good to get the ones we have translated for 2.28. Ready, set, go! I’ve given French a leg up with a translation for Activites as a test case.

Along the way it took a bit of gjs hacking to make it easier to create native modules; if you found yourself embedding Spidermonkey but yearning for PyArg_ParseTuple, gjs_parse_args is your friend.

Speaking of programmer stuff, the built-in console mentioned in my previous post gained a parent-list inspector and property inspector which bring it very slightly closer to Firebug-like real, ultimate power. True story, I originally called it lookingGlass.js completely forgetting about Sun’s project ironically also about 3D-based desktops. Anyways, since that doesn’t seem to be actively developed anymore, and it’s a really great name, I think I’ll just…if you don’t mind….(yoink!) claim that name.

There have been a lot of other user-visible changes recently, in visual terms I really like the result of both Sander’s excellent work in bug 584609 in combination with the progress recently on moving visually to the mockup Jon referenced here. Another promising change is our start on the application menu area.

Which gets me to the subject of the next blog post; one the major changes in GNOME 3 from both a user experience point of view and application developer view is that we’re application based, not task based. Work continues in this area – in the next post I’ll talk about how this affects the experience.

It’s hot and humid in Boston, and I’ve been finding it a bit hard to sleep sometimes. I keep telling myself I’m going to get an air conditioner, but, well, laziness and money. Anyways tonight around 3am I just gave up, and from then till now-ish I was working on this cool little hack for Gnome Shell.

So here’s the problem. I have almost no visual skills personally, and in a freeform environment like Clutter or HTML I have a really tough time making things I code look good without basically being handed the pixels directly by a visual designer. But one thing I have noticed though is we have some people in the GNOME community with awesome visual skills. So I wanted to lower the barrier to entry a bit for them.

My inspiration was Firebug (which again if you have to do HTML and haven’t tried, do so immediately); I wanted to make something where you could interactively edit and debug the visual layout. So the result of the hacking landed in bug 590515. But since you’re unlikely to do a git pull and git bz apply, I used Owen’s cool builtin facility for making .ogg recordings of the shell.

Note however that at least parts of the shell aren’t redrawing correctly in the beginning, and I gave up debugging that for now. The top chrome will appear in the middle of the video.

Ok, you don’t have the video tag, try the direct link.

Being able to hack something like this up in a short span of time is really neat I think, and definitely is one of the high points of having one’s app scripted with JavaScript. You can go in and play around, even monkey patch things.

To actually make this useful for artists there’s a lot more to do; a Firebug style properties display/layout debugger probably wouldn’t be too hard, and would help you get past the problem of even knowing what properties there are. But besides this tool, in the big picture we really need to switch to CSS, but that’s coming.

One question you may have is why when I moused over the window area, we didn’t see different boxes for the windows? Well, that comes down to the fact that there’s a transparent input-only box over the windows. A nice future enhancement for this tool would be to be able to skip layers; then you could type in a bit of code and animate/color etc. your windows.

Another thing that would be neat from a code perspective to make this more useful for hackers is to allow JavaScript subclassing GObject; the problem is most of the shell there’s no good way to get the JavaScript framework from a given actor. If only I had a time machine to go back to when Brendan was typing in code for prototypes, and hand him an extends keyword. But, speaking of dreaming…it’s 8am now.

There’s more going on in the shell land, among other things we’re taskbar-less now. Yay for less visual chrome, though we have to work through the details. More on this later.

So among the major burning problems we have in Free Software, one of the biggest is trailing whitespace in source files. If you too have a project where people really care about this, you may be interested in my quickly hacked up git-un-diff-whitespace script. It removes trailing whitespace *only* in areas modified by “git diff” (i.e. it won’t pollute your diffs with lots of spurious whitespace changes). I briefly tried to find something like this elsewhere on the interwebs but failed. Oh, and if someone fixes it to handle new files I’d be happy.

One of the things I wanted to talk about more was what I think does matter about the desktop, which is the total experience and how it relates to branding. People with extensive computer experience have a significantly better understanding of the individual components in a system (though they can and often are wrong of course about details), but the problem is that this leads to a different experience than someone without that understanding.

A specific example I’m thinking of here is the Java updater on Windows. I overheard one Java developer expressing surprise that someone they knew without much computer experience thought Java was a pop up. Now you may laugh, but really, they’re not wrong. The pop up is their total experience. People with the computer knowledge know they need it to play some online game, or they don’t. They know it’s from a different company, and added on by the hardware vendor, or that the pop up is a tiny piece of a much larger system. It ends up being a very different brand.

Speaking of hardware vendors and brands, this brings me to Windows itself. I’ve kept around a Windows install on my PC for various reasons, among them that I like to keep up to date on what’s happening in Windows land and be able to carry on an intelligent discussion about operating systems in general (not that you can tell from some coffee-fueled rambling blog posts), and also because I’ll probably have to work on porting GObject Introspection to Windows (pure pain) at some point. So here’s the problem with the Windows brand, and I think Microsoft is catching on to this – you’re carpet bombed with it in your interaction with the system, and it’s associated with very good things, very bad things, and everything between. Some things that are Microsoft’s fault, and some things that aren’t.

I was browsing the menu one day and came upon a Windows Dancer menu item. Microsoft made this, associated it with the Windows brand, and shipped it. It boggles my mind. Did you know that 29% of Windows kernel crashes are caused by NVidia? Except here’s the problem – it just says “Windows crashed”. So the user is going to associate that crash with the Windows brand, even though it it’s really not Microsoft’s fault. By far my favorite though is the Dell Dock. Definitely a lesson there in letting hardware vendors do arbitrary things to one’s OS.

The point here is that the design and experience of Microsoft’s core system (or any operating system) in a vacuum are far less relevant than the total experience of someone who just gets a computer. And this I think is actually a strength of the free software operating system, for a few reasons. Following the “rough consensus and working code” approach inherently avoids the worst things. If someone proposed a Message from your mouse vendor pop up in GNOME, we’d just laugh. Second, because we’re fundamentally cooperative, there’s less tension about replacing higher level things that people try to add on top. If memory serves correctly, for years Windows didn’t ship with an unzip utility in the core OS, presumably because of concerns about undercutting Winzip. We’ll never have that problem.

A bit more on this later, and how it relates to a feature I’d like to work on for the shell.

So Henri Bergius discussed John Gruber‘s claim that the free desktops are in an uncanny valley. Let’s leave aside the obvious bits that 1) desktops are absolutely nothing like robots trying to be people, and 2) clearly the fundamental basis of the uncanny valley is the “Pathogen avoidance/mate selection”, since in the tenth of a second it takes for your reaction to form, you obviously don’t have any time to ponder “Western constructions of human identity”. Given that people don’t get pathogens from their computer (unless you’re using a public internet terminal) nor attempt to mate with them (no comment), the uncanny valley isn’t very useful as an analogy.

That said, it’s amazing to me that John managed to go on for so long about operating systems in general (not just desktops) without mentioning the most important point about them. Actually, really the point, which dwarfs all others. That is:

To run the applications you want

Now, don’t get me wrong. There’s a lot of details about desktop operating systems that are important; more on this in a minute. Obviously, a web browser is essential, but that’s a commodity. Now, I don’t want to get into a debate about exactly what percentage of people can be fully served by solely a web browser, but let me just note that for a lot of people, especially ones with overseas families, Skype is still a killer app. And you can’t write Skype in the default web security model (which is the relevant bit here, not a missing-the-point debate about AJAX versus platform widgets).

Continuing on the subject of the uncanny valley, clarkbw told me a while ago there’s been HCI research to the effect that people are not generally too troubled by visual differences. Consider for example the evolution of the Start menu; it looks really different between each of Windows 2000, XP, and Vista, but generally people don’t have a problem with that. However what they do have trouble with is something that looks similar, but does something completely different. A good example here is how in the default GNOME panel configuration, we ship the “make all your windows go away” button in the bottom left. Kind of a bad idea, one that will go away with the shell design.

But in general, I don’t think the problem has anything to do with an “uncanny valley”. If we’re talking about the consumer space, basically people just use the operating system that came with their computer, until it’s time to replace the computer. Overcoming this is I think largely a business problem, not a desktop interface problem.

So on the subject of looking like Windows in the context of GNOME, my take is that it is important to look good and be functional, and having a distinct visual identity is important – but – keep in mind:

Given that data, considering that our target market is, like Windows, general purpose computing, it makes a significant amount of sense to consider issues that occur during transition and what the expected target audience needs.

What did I mean by “general purpose computing”? Well, it’s a big world. Think of scientists and engineers using Scilab, or all of those fixed-function registers that currently run Windows. OLPC-type projects. Content creators who need to edit video. System administrators and developers (count me as a skeptic of editor as a service).

What about targeted “netbook” operating systems? There is definitely a large number of people who only need a lightweight computer. I think the core desktop should adapt automatically to those kinds of conditions; for example, you should be able to drop bits of GNOME you’re not using (say Evolution), and the panel should adjust Ubuntu Netbook Remix style. There’s definitely a place for Moblin type specialized interfaces, and as long as they’re generally compatible with the general purpose OS. Concretely, if say Skype has to rewrite or do significant work to adapt their app, there’s a problem. But regardless, if Moblin achieves its goal of being shipped by hardware vendors on netbook hardware regardless, it’ll be a huge step forward.

Now, different people have different visions of where the GNOME Shell should go, and that’s healthy and fine. To an extent these different visions can be accomodated by different means. Ideally of course, we fix the problem in the default design. But failing that, it might work as a Firefox-style extension mechanism that we want to add, a separate project that builds upon shared infrastructure, or automatic interface adjustments like the netbook screen size one I mentioned above.

But you can count me as believing that it makes sense to be sure that the apps you use today continue to work, while achieving the goals of making GNOME look nicer and more interactive than two grey bars, and fixing the obvious problems like poor access to your recent files, no application search, etc. Some of this we’ve done already, but there’s a lot more to do. If you’re interested and able, it’s pretty easy to dive in to the project!

We reject: kings, presidents and voting.
We believe in: rough consensus and running code.

From David D Clark.