Tag Archives: gnome

Netbook in the coal mine

For a long time my primary workstation was a (now 3 year old) Dell Inspiron E1705, or “bricktop” as ajax liked to call it. However the hinge broke a while ago when I closed my car door while the bag was too close, and when the laptop started to fall apart I decided to get a new machine. Actually, I got two. The first thing I did was get a serious desktop computer, a Dell XPS 630. It’s quite a beast, especially since I got 8GB of RAM with it. I pretty typically have over 2GB of memory used purely for page cache, which is probably my entire working set of files. It’s hooked up to a nice 24″ Dell 1920×1200 monitor. This computer is named megatron.

Needless to say, the machine is fast and nice to use. However, it’s rather unrepresentative of the general personal computing space. So I wanted another machine that was mobile, and also closer to what “most” people use. So I picked up a MSI Wind U123, known as pocket. It has just 1GB of RAM, which is probably the realistic minimum we want to support going forward (ideally we’d be workable with 512MB, and we probably are if you’re just running one application or one or two websites, but…). The machine also has an Intel 945 video, which is also near the lowest end graphics card we’ll be supporting for GNOME Shell.

The difference between the two computers is rather extreme, but I use the netbook very often, and working on it has forced me to optimize some things in the shell. It serves a similar role for performance issues that canaries used to do in coal mines (hence the title of this post). Specifically, I’ve been working on search performance, with fairly good results. We had a few sillies in the old search system like creating lots and lots of ClutterActors we’d never display, not caching lowercased strings, etc. (the other goal by the way of my search work is to move us closer to the current search mockup, which should be cool).

But the biggest performance problem I’ve been running into so far is synchronous I/O. A lot of GNOME libraries like gnome-menus were designed for gnome-panel, which typically you don’t interact with often, and so it’s not a big deal if the process is blocked. However if the shell is blocked, because we’re acting as a compositor, we won’t repaint the desktop or process input, which is a serious user experience problem. An example of this was that we would synchronously stat (check for existence) of recent documents; this could easily take several hundred milliseconds if the data isn’t currently in the kernel cache.

I’ve been reworking our docs handling specifically to be smarter; we use async I/O now, and only stat ones we’re actually going to show in the UI. We could be smarter still, but this has helped a lot. GIO has really nice APIs for this kind of thing.

I mention this for two reasons; first, just because you might be interested in a status update on Shell work. The second is because I’m hoping to Real Soon Now land my extension system patch, so if you create an extension using it, for a good user experience, you’ll need to be very careful about I/O too =)

Pay no attention to the processes and X Windows behind the curtain…

A major change we’re trying in the GNOME 3 Shell is to be application-based instead of window-based. In this we’ll be in good company with newer releases of other operating systems, but it’s still a major change. What I want to explain in this blog entry is what that means from a user perspective. For the developer perspective, see this wiki page.

Let’s first look at one of the most venerable (and yet apparently still obligatory) applications, the Calculator. In GNOME 2, launching the calculator looks like this:

From GNOME Shell

Launching Calculator

When we click on that menu entry, the application is started (for more details about under the hood, see the linked wiki page above). The visual result is this:

From GNOME Shell

Calculator and the window list entry

There’s a window for the application, and a task list entry. Now in GNOME 2, if we go to the menu and choose Calculator again, we get this:

From GNOME Shell

Two calculators

Technical people will know that under the covers, there are two gcalctool processes, each of which is creating one window. What this example emphasizes is that in GNOME 2, the bottom panel has a list of windows (or tasks), not applications.

Moving on to GNOME Shell, the “window list” and “menus” part are merged into the overview. Let’s take a look at the application well when Calculator is not launched:

From GNOME Shell

GNOME Shell overview application well

Here I’ve added Calculator to my favorites, so it always shows up. It’s not running yet. When I click on it, the active application at the top immediately changes to show that (GNOME techies: this replaces startup notification), and then the widow appears:

From GNOME Shell

Running Calculator in GNOME Shell

So now that Calculator is running, let’s go back to the overview and see what changed there.

From GNOME Shell

Application well, with Calculator running

You can see that the Calculator gained a glowing status indication, like the other applications I had running already. When I click on that icon again, I am switched to the running calculator window:

From GNOME Shell

Looks exactly the same!

In other words, it looks exactly the same, it just shows you the window again. (Under the hood, the program is not re-executed, there won’t be multiple gcalctool processes, etc.)

Ok you say, but Calculator is a pretty boring application and you don’t use it anyways. How am I making your life better? Well, there are two major things.

One of them is that many programs fail in some obvious and other times less than obvious ways if you click the menu entry twice in GNOME 2 (technically, by default this will start two processes). They’ll overwrite each other’s data, etc. For very few instances does it make sense to have multiple if the app is not explicitly designed for it, and this will avoid you accidentally launching two. Personally I get annoyed when I accidentally launch two xchat-gnome instances and appear on IRC twice.

The second improvement here will come when we get a bit better application integration; the mockup we’d like to implement for say Firefox and multiple windows looks like this:

From GNOME Shell

This needs application-specific work though.

As a brief unrelated aside, I think recent Chromium builds with the tabs-in-window borders (technically, client side decorations) looks cool fullscreen in GNOME Shell with the application menu:

From GNOME Shell

Chromium in GNOME Shell

Next post I’ll talk about how GNOME Shell will save you time and get you back into your applications faster.

Creative Commons License
This work is licensed under a Creative Commons Attribution 3.0 United States License.

Whence world domination?

I’ve had this blog entry going around in the back of my head for some time now…it’s seen a number of false starts and revisions, finally I’ve decided to cut it down to just the essence:

Andy (re)started an important discussion. How do we increase use of GNOME and Free Software in general on the desktop? What’s our target audience? What kinds of things can we do? Why haven’t we taken over the world yet?

Basically, Microsoft Windows is like a big Katamari ball. It has an enormous amount of momentum in the form of first and third party applications, drivers, hardware vendors, etc. Put another way, it’s a Network effect. Even Apple, who have a huge influx of cash from their consumer electronics business and been returning some of that as improvements to their OS, have only seen their market share increase by tenths of percentage points (insert standard statistics disclaimer and standard Wikipedia disclaimer).

How about us? First, let’s note that overall, the Free Software movement is doing better than it ever has. For example, Sun is quickly transitioning to becoming a primary Free Software company (I liked this blog entry). I’m sure if you told Richard Stallman back when he started GNU that he would end up completely winning versus all of the proprietary Unix systems of the day, he would have been amazed.

Even Microsoft is now employ people who work on projects like IronRuby (as Sun employs major JRuby hackers, and did you know Apple has their own Ruby bastard child? (I’m doing my own Ruby implementation too)). So in general almost every large technology company now ends up contributing back in some way to Free Software, typically infrastructure (development tools, shared libraries). I liked this quote from the New York Stock Exchange:

“Red Hat is like water; it’s pervasive within our architecture. … Without it, most of our computers wouldn’t be running,” — NYSE

So we understand that Free Software is doing well. Let’s go back to the desktop specifically. Despite some negativity, the Free desktop is widely regarded by a number of important software development organizations (both Free and proprietary) as a target platform. For example, Mozilla and Adobe. We have quite a lot of Free desktop applications. There are a lot of professional developers, students, etc. using the Free desktop on an individual basis, and a growing number of managed (usually thin) deployments like this Europcar one.

In particular from that story it sounds like Europcar basically needed a desktop to run Telnet to some proprietary backend booking system. Yes, it doesn’t make sense to spend large license fees to Microsoft to run telnet. More generally for a growing number of corporations their needs are increasingly met by the web browser (the 21st century telnet). So we can expect deployments like this to increase. Every time I see the default Windows XP screensaver on a point of sale system I just shake my head. It’s a testament both to how enormous the Windows Katamari ball is (it rolled in the ISVs developing the point-of-sale apps), and to how no one ever changes the defaults.

But what about consumers? Let me just say this straightforwardly: I don’t think the free desktop is likely to see significant gains in unmanaged consumer computing in the next few years. Fundamentally, it has to be extremely compelling to get people to download it and replace their current operating system, and while we do have our advantages, most people just want to check their email and then go out and do something that doesn’t involve looking at a computer screen. Could we do better in the consumer area? Yes, I think so; I have some specific business-related ideas in that area that I won’t mention now, but in the end we’re likely only talking about a percentage point or possibly two for the near future.

For consumers though, Free Software does have decent success in the form of Firefox. What’s Mozilla’s trick to get so many downloads? What we can learn is that Free Software is certainly a necessary condition, but not (in general) sufficient. The other key is the user experience. People can very much appreciate things that make computers suck less. Firefox 2 added tabs, Firefox 3 added the awesomebar. There is of course also the fact that installing Firefox is far less risky than replacing your operating system, and while we can do some things to ameliorate that it’s difficult.

Don’t get me wrong; I think we will see more adoption of the free desktop among consumers (as a percentage), but again, the Katamari ball isn’t going to stop overnight. A lot of people seem to think either we won’t see any increasing adoption (again, as a percentage), or that there will be an inflection point at which adoption takes off, and I don’t think either of those are likely soon.

So the other main audience is technical computing; sysadmins, developers, scientists, etc. What we absolutely must do is stay on the ball for this audience. These people are in some ways a proxy for the larger audience; even particle physics researchers want their sound to Just Work. For example, this bug from a Mozilla developer. That’s a generic GNOME bug; on the vendor level we are still struggling with a good upgrade process. This blog from a Fedora developer, and this blog from a Mozilla developer using Ubuntu. As I’ve said before, apt-get or yum or whatever are fundamentally just fancy implementations of wget; upgrades (without random manual intervention in a terminal) are a harder problem than that.

Anyways this is a long entry now and at the beginning I said I’d keep it short =) So the bottom line? We’re doing OK. But truly spreading the Free desktop requires solving many hard problems that do exist. We can’t spend time screwing with the code. Think about how to make the experience better; it could be for developers and sysadmins if you like, or better for nontechnical users.

One last thing; while writing this entry I stumbled on Federico’s 2006 summary of feedback from thin client deployments that I hadn’t seen before. There’s a lot of things there that are eminently solvable. Let’s just do it.

Initial Public Offering

So now seems like a good time to recreate a personal blog. I lost mine when my personal (physical) server died and was too lazy to start one up again.

If LiveJournal is good enough for jwz, it’s good enough for me. (This is what I said originally, but it completely ate the first version of this blog post right after I typed all of it out because I tried to click on a help item then use the browser back button, which I am still angry about while I am trying to retype this, but anyways)

I thought Havoc’s post on the GNOME Online Desktop (and he deserves some sort of medal for the name) was very good. It has started some sub-discussions, one of which is about Gimmie and Big Board direction.

The first thing I want to say to Alex in particular – I have always had a great deal of respect for you and the cool software projects you have created. Gimmie is a great project.

As for the details, I want to avoid all the he-said/she-said stuff and just say that basically, in my opinion it would not have made sense to prototype the Big Board direction starting from Gimmie’s codebase. At least up until now and for the near future.

Gimmie’s scope for the most part has been to improve the panel, and in my opinion does this very well. Does it also replace your panel? Yes, but the Big Board scope is quite different and larger – it is part of a prototype for an online desktop.

For example, the Big Board codebase also includes Havoc’s experimental code to sync GConf with an internet server.

Also in the interest of prototyping, we decided to reuse a large amount of infrastructure that we have developed for the Mugshot server. This has made it a lot easier for components such as the photo slideshow “stock” (the term for Big Board widgets, obviously!) – there is zero configuration involved with it. It goes out and gets your Mugshot contacts, retrieves their flickr/youtube etc. thumbnails, then slideshows them. If we’d wanted to do this in the Gimmie context, we would have had to add infrastructure to the code for “external accounts” (mugshot term for data like flickr username), and also code to talk to the Flickr API, poll YouTube feeds, etc. And that would leave open the question of how you find out the flickr usernames for your contacts.

Another example is Havoc spent a few hours figuring out how to talk to the Google APIs and get a list of your online Google docs displayed in the sidebar. And most of that time as I understand it was battling Google’s crazy everything-is-an-atom-feed API. If we’d wanted to do this starting from Gimmie, we would have had to figure out the harder question of how it iteracts with Gimmie’s code for local documents, what operations made sense, etc., in addition to writing the code to talk to Google.

In code terms, if we had tried to do this as Gimmie patch, a lot of it would have been of the form:

function():
if mugshot_mode():
do_mugshot_thing()
else:
do_gimmie_thing()

which probably isn’t very useful for Gimmie’s current userbase right now.

Longer term, it does make a lot of sense to figure out how to reuse/integrate/merge with/write-plugins-for existing components such as Gimmie/gnome-panel/nautilus/GConf etc. But I hope this post explains why the Big Board is not a “Gimmie clone” anymore than Gimmie is a “panel clone”, and why we’ve been prototyping in a new codebase.

Originally I had written more extensively here but I’m going to post this now before it gets eaten again.