Everyone should read the Git Community Book, a very nice manual for Git. You can also contribute to it!

My friend Esteban, who has been taking some amazing photographs, informs that December 31st of this year will have a leap second. Watch out for the prized hh:mm:60 moment!

I am in the process of seeing why gtk-vnc (the VNC client implementation used by Vinagre, virt-viewer, et al) is much slower by default than TightVNC. It seems to be something around the preferred ordering of encodings which VNC supports, plus TightVNC's funny extensions. So, I have been modifying the ever-amazing Wireshark to support decoding TightVNC's extensions to the basic VNC protocol. This will make it easy to compare what TightVNC and gtk-vnc are doing.

I just ran into a bug in Nautilus caused by a FIXME from December 2000, from the Eazel days. The bug only gets triggered by my patch to allow desktop icons defined by the sysadmin; the original code doesn't seem to be subject to this. Dr. House, move over for here I come.

I am starting to think that Nautilus, like any big system with a lot of history, is not a beautiful piece of clockwork. It is not neurotic and exact; it is more like a living organism where data flows in semi-predictable directions and all your changes to the code have to be prepared for anything. You cannot know exactly what data you will get, or all the code paths that may lead to your code getting called.

This is not a bad thing by itself. You cannot have a large, mature system that functions with 100% predictably, like clockwork. You have to allow for things to happen even if you did not expect them.

The ever-excellent blog of the Permaculture Research Institute of Australia links to a fantastic documentary on an individual's human footprint: how much you consume and produce throughout your life.

A couple of days ago we were finally able to move our bedroom to the second story of our house. It's interesting how a change of environment modifies your habits. While our old bedroom was on the south-west corner of the house, so it only ever got direct sunlight in the afternoon, the new bedroom has windows facing the north-east and we get all the early morning sunlight. The result is that now we are waking up automatically between 6:30 and 7:00, instead of at 9:00 due to Luciana clamoring for attention.

One small bug in this setup is that the bedroom gets little direct sunlight in the afternoon, so it cools down and the roof can't radiate heat during the night. Fortunately, a little insulation in the windows and good bed-covers fix the problem — one of the advantages of living inside the tropics :)

Everyday file management at the user experience hackfest

During the user experience hackfest I was part of the team that brainstormed about how to make file management easier. My other team-mates were Sebastian Faubel, Máirín Duffy, Garret LeSage, and Matthew Paul Thomas.

It is useful to think of file management as two different-but-related problems: dealing with your everyday files ("what I am working on"), and dealing with your archived files ("what I did in the past"). For now I'll write about the first problem.

Dealing with your everyday files

My talk at GUADEC, Document-centric GNOME, explained a few of the problems that cause people to have a lot of trouble when dealing with their everyday files or other data.

People have a hard time finding the files they worked on recently ("my homework paper that I was typing last Monday"). When you start up your computer, you get a desktop with some scattered icons which are probably not the files you are interested in. If you work on a physical desk with physical items like paper notebooks and pens, your stuff remains where you left it: you can just go back to your desk and resume work immediately.

Programs do not provide any sort of help in actually finding the files you are interested in. Let's consider a very common workflow: download an image from a web site, make some modifications to it, and attach it to an e-mail. When you do "save image as" in your web browser, it will default to ~/Downloads or even ~/Desktop. When you do "file/open" in the GIMP, it will default to the last directory you used in the GIMP, even if it was from days ago (on my machine right now, the GIMP defaulted to look at files from ~/src/some-random-directory). Finally, Evolution's "insert attachment" defaults also to the last directory you used in Evolution (~/.ssh for me right now, since I mailed my public key to someone yesterday). The end result is that your workflow gets shattered to pieces, as programs try to be helpful within themselves, but they totally fail at being helpful within your workflow.

So, programs contribute to having files scattered around everywhere, and there is no easy way to look at everything together.

The journal

It is useful to think of your working set of data. This is the stuff that you have been working on recently: documents that you typed, photos that you edited, e-mails that you sent, web sites that you researched. People have a reasonably good memory of when they did things recently. "I started typing my homework last Monday, because I knew it was due on my Thursday class". "I mailed you that photo two weeks ago, right after my birthday party".

A few years ago I started to maintain a big text file in which I keep a journal of what I do during the day. October 23 2008: filed bug #12345 about blah blah; mailed someone@foo.com about this and that; started ~/Documents/SomeProject/important-file.odt. I can search through that text file really easily to find when I did something, to remind me of bugs I was dealing with, to find important files which I don't want to lose. Sometimes I put in annotations there ("paid the electrical bill on the bank's web site, with transaction number 1234"), or very specific things that I need to do over the next few days (somewhat like an ad-hoc to-do list).

Similarly, different people in many professions keep journals or log books of their work. It is very useful to be able to look at your journal later, to remind yourself of related things that you were doing around any particular time.

OLPC announced the XO Journal some time ago. It shows you a timeline with all the work you do on your laptop: it is a computer-generated version of the journal I keep in a hand-written text file.

On the hackfest we took the mock-ups that I showed during GUADEC and improved them to make them more useful.

The journal shows a timeline of the files you have worked on, e-mails that you have written, web sites that you have visited, IM conversations that you have had. We can implement this gradually, starting with the RecentFiles infrastructure we already have, and then writing little providers for the other data sources.

The journal lets you put hand-written annotations at convenient spots, like "phoned my mom about her vampire costume" or "paid the bills with transaction number 123".

You can "pin" items in the journal, or mark them with a star, so that they will also be displayed in a fixed place for "starred items". This way you can anchor important things so that you don't have to hunt for them in the timeline.

You can create documents directly from the journal. Consider this case from the physical world: you get an idea, grab your paper notebook, open it to the first available page, and write something about your idea. Or you do a small sketch. Then you close your notebook. If what you scribbled is not very important, you'll just leave it in the notebook and forget about it. But if it turns out to be good stuff that you want to keep around, you'll tear out that sheet of paper and put it in a "good place": a stack of papers for a particular project, or a folder or binder if you are really organized. The point is that you can start creating stuff without having to think in advance of a place to put it. You can just keep your stuff in the journal until you think of a good place for it (and when you move it to a folder, you can still access the files from the journal, of course).

Finally, the journal needs to be really easy to access. Since it is your "holding tray" of things that you are working on, you want to be able to access the journal without moving away all of your windows or hunting for it in your cluttered desktop. The mock-up proposes using a tab on the edge of the screen. The tab is normally hidden so that it does not obstruct your work. If you move the mouse to the edge of the screen, the tab appears and you can click on it to slide out the journal window. This scheme may change based on the ideas from the window management team. Fortunately, the position of the journal is easy to change: give me a parent window and I'll move the world.

Implementation

I started implementing the journal as a Nautilus extension (see my previous post about this for screenshots and source code).

However, Seif Lotfy has a much more complete implementation of the journal in the form of the Mayanna Timeline. Mayanna is the maintained version of Gimmie, and a lot of good work has been going into it.

Seif and I have been talking about how to proceed. It seems that we'll reuse his data providers for the timeline or journal, and rewrite the layout/view code to make it really fast and lean. In particular, I'm pretty interested in looking at the layout code from the Nemo file manager.

Stay tuned

I'll write about the second problem with file management over the next few days: how to deal with your archived files. Sebastian, Máirín, and Garrett have excellent ideas in this space.

Start of the Nautilus Journal

On the GUI Hackfest we talked about a lot of ideas for file management, including the Journal that I described during GUADEC. The journal view is now a work-in-progress; here is a quick screenshot:

There is no behavior right now (you can't click or anything); the journal just scrolls. In the end this will not live in a normal framed window, but rather in a tab on the side of the screen or some other place that is easy to access.

You can play with this in the Gitorious repository for Nautilus; look in the document-centric branch.

Mortadelo 0.3 is released

I've just released Mortadelo 0.3, the graphical, systemwide version of strace. You can use Mortadelo to examine the system calls from all your processes.

Source tarball: mortadelo-0.3.tar.gz

Git repository: git clone git://gitorious.org/mortadelo/mainline.git mortadelo

openSUSE 11.0 one-click install:

The Git user's survey 2008 is up! Be sure to participate to make Git better. I found question 27 very interesting, with a bunch of commands that I never knew about but that could be very useful to me.

Everyone who has a laptop: GNOME is now wired to support the hotkey which laptops have to toggle the internal/external display output (Fn-F7 on Thinkpads, for instance). X exposes this as the XF86Display keysym. However, not all laptops expose that key in the same fashion. For some of them to work, one needs to add entries to HAL's description files, or do some ACPI magic.

We are building a list of laptops to see how they expose the "toggle displays" and "rotate the screen" hotkeys (for tablets). If you have a laptop, please add it to the list so that we can add support for it. Thanks!

Usability of planets

We have another flamewar about inappropriate posts on Planet GNOME.

Why does this keep happening? Let's take a user-centered view. Say you are a reader of a planet aggregator. Your question is, how do I get rid of the posts by Annoying Person?

Now, let's compare two planets: Planet GNOME and Planet SUSE.

Planet GNOME	Planet SUSE

In Planet GNOME, you must scroll to the bottom of the (very long) page, click on the "Feeds" line to expand it, and then you will find checkboxes for each of the feeds. You can then find Annoying Person there and uncheck him.

Step 1: wait for PGO to load. Step 2: scroll to the bottom. Step 3: find the "Feeds" line. Step 4: click on "Feeds". Step 5: find Annoying Person. Step 6: uncheck his checkbox.

That's six steps just to get rid of stupid posts.

In Planet SUSE, each post has an "X" icon. If you click it, the icon turns into a checkmark, and all of that person's entries will be hidden the next time you load the planet.

Step 1: Find the "X" icon next to Annoying Person's post. Step 2: Click the icon.

It is clear that Planet SUSE is much more usable than Planet GNOME in terms of "how do I hide the posts by Annoying Person". You don't have to know that to hide someone, you must scroll to the bottom of the page, find a magic little expander, etc. You just click on the "go away" icon which is right there by the annoying post, and you are done.

Today's harvest, green beans

This is about 240 grams of green beans that we grew out of eight plants, on more or less 40x40 cm of soil. The plants should yield about three times that amount, once the younger beans and flowers mature.

I don't know if that kind of yield is low or high, but it definitely feels good to get something edible out of a little patch in the sidewalk. No fertilizers or anything, just soil from our little compost heap. This is the sidewalk in question; the beans are the ones with the large leaves. There is also epazote (anti-flatulent aromatic herb for cooking beans), garlic, mint, a couple of watermelon seedlings, rosemary, petunias, roses, rue, and a couple of plants whose names we don't know.

Our gardening book is How to grow more vegetables, by John Jeavons (acutally, a slightly newer edition than the one presented there).

Predefined desktop items for Nautilus

Back in the Summer of Code 2007, Sayamindu Dasgupta worked on adding support for predefined desktop items to Nautilus. This is so that system administrators can set up desktop links that will appear on users' desktops. A university could set up an icon to take people to the university's intranet, for example.

Basically, I'm reviving Sayamindu's patch and bringing it up to date for the current Nautilus. The idea is that you set up a GConf key, /apps/nautilus/desktop/predefined_items_dir, and point it to a directory which holds .desktop files. This kind of indirection through a GConf key is what makes the scheme work nicely for deployments with Sabayon: sysadmins can have predefined items for various groups of users, and select among those by simply changing a mandatory GConf key for each user. This wouldn't be so easy if there were a hardcoded directory like /var/nautilus/global-desktop-items.

Sysadmins should be able to define mandatory items, which users cannot change or delete, and also "normal" items, which users can tweak or remove. Mandatory ones would be ones like "Company Intranet" or "Link to Helpdesk". Distros could use normal items for their marketing materials; the perenially hacky "Welcome to FooLinux" icons that currently are hard to do properly.

The problem I'm having is how to make non-mandatory items work. You want this behavior:

1. The sysadmin defines a non-mandatory item.
2. The user sees the item in his desktop. He doesn't want it anymore, so he deletes it. Where do we mark this deletion?
3. The user decides that he wants the item back after all. How does he restore it?
4. The sysadmin updates the non-mandatory item and he wants it to show up again in people's desktops. How can this override what the user had done?

I'm leaning toward having two extra boolean values in .desktop files: an X-GNOME-Mandatory and X-GNOME-Deleted. If the "mandatory" value is false, then the user may change or delete the item. For changes, the item is copied from the predefined_items_dir to the user's ~/Desktop and that version is modified. For deletions, the item is copied there as well, but then the "deleted" flag gets turned on.

If the user wants an item back, he turns on "show hidden files" and those files get shown again. (Or we could hack the Trash to restore the item by turning off the "deleted" flag...)

If the sysadmin updates an item in the predefined_items_dir, this item will override items of the same name in users' desktops, based on the item's timestamp.

Does this make sense? Am I overlooking something?

People who use git-mirror.gnome.org may have noticed that SVN tags don't get fetched automatically when they get their daily fix of updates with "git fetch" or "git pull" (that is, you run "git tag" and it doesn't list new tags that appeared since you did your original clone). Within your repository, take a look at .git/config:

[remote "origin"]
	url = git://git-mirror.gnome.org/git/gtk+
	fetch = +refs/heads/*:refs/remotes/origin/*
	fetch = +refs/tags/*:refs/tags/*      ### <---- Add this line!

The first "fetch" line is already in your .git/config and it means, "every time I fetch from the origin, get all the branch heads in the origin's refs/heads and stuff them in the refs/remotes/origin namespace" (i.e. update all the branch heads).

The second "fetch" line is what you need to add. It means, "every time I fetch from the origin, also get all the tags and stuff them in my own namespace".

After that, just do "git fetch origin" and all the tags will be downloaded to your repository.

Mike Wolf has been working madly on rpm2git to make it easier to use. He has made some very cool changes:

Rpm2git no longer requires you to have an environment suitable for rpmbuild (e.g. specfiles in /usr/src/packages/SPECS, patches in /usr/src/packages/SOURCES). If you have a single directory with a specfile and patches, you can simply run rpm2git on that.

You don't need to have all the BuildRequires from the specfile, either.

Perhaps most importantly, you don't need to mess with your $PATH anymore nor install helper scripts. Rpm2git now works out of the box after "make install".

All of these changes are now merged in the rpm2git repository.

Sometimes Oralia boils water in the kettle, and adds a stick of cinnamon to make an infusion. The other day I heard the kettle boiling and I thought, "time for some green tea!". I didn't notice that the water was actually cinnamon, and made my tea as usual.

Well, hot damn, green tea made with cinnamon water turned out to be *good stuff*. I think I could grow an addiction to this.

Labels for RANDR monitors

When you configure multiple monitors, it is useful to know which physical monitor corresponds to each element in the configuration GUI. Both KDE and MacOS display cute labels on each monitor.

I implemented pretty much the same thing for GNOME, with the addition of color-coding. Hello, sexy:

This is in the following Git repositories (look at the monitor-labeling branches in all of them, and also tray-icon-rotation for gnome-settings-daemon):

• gnome-desktop
• gnome-settings-daemon
• gnome-control-center

This is just awaiting approval from the the release team to be committed to SVN :)

Why I want to have the children of git rebase --interactive

Sometimes you are hacking madly and committing often. Your commit log looks like this:

* Add some fields for a popup menu
* Create the popup menu
* Refactor the base object to accomodate the menu's commands
* Implement the signal handlers for the menu's commands

Then you type make and of course your code doesn't compile. So you do one-liner commits, one for each build error:

* Add missing include gtkmenu.h
* Fix typo in popup_menu variable name
* Forgot to declare a menu_item variable
* Add missing argument for gtk_menu_popup function

But you don't want you submit all of those patches upstream! You only want to send perfect patches which are either additions or refactorings to the upstream code. You don't want the maintainer to know that you are a fallible human being who forgets include files and variable declarations; instead, you want him to believe that you are a coding god who sends a perfect series of patches every time.

git rebase --interactive allows you to pretend you are better than you really are. This is a good thing.

We have 8 commits in total (4 "good" ones that don't compile, and 4 "embarrassing" ones that are little fixes). So, run git rebase --interactive HEAD~8. This means, "let me fix any fuckups since 8 commits ago".

Git will drop you in an editor where you edit this:

pick ab365cf Add some fields for a popup menu
pick 2478bac Create the popup menu
pick 9180ffe Refactor the base object to accomodate the menu's commands
pick a6c2467 Implement the signal handlers for the menu's commands
pick 289cf1a Add missing include gtkmenu.h
pick 378ac2b Fix typo in popup_menu variable name
pick 821ac6f Forgot to declare a menu_item variable
pick 24acf67 Add missing argument for gtk_menu_popup function

# Commands:
#  p, pick = use commit
#  e, edit = use commit, but stop for amending
#  s, squash = use commit, but meld into previous commit

Now let's reorder the lines there, and replace some pick commands by squash. I've put in some comments about what each moved line does.

pick ab365cf Add some fields for a popup menu
squash 289cf1a Add missing include gtkmenu.h
# Oops, forgot to "#include <gtk/gtkmenu.h>" to have a field declared "GtkMenu *popup_menu"
	      
pick 2478bac Create the popup menu
squash 821ac6f Forgot to declare a menu_item variable
# Oops, while creating the menu items I forgot to declare my menu_item variable

squash 24acf67 Add missing argument for gtk_menu_popup function
# Oops, while creating the menu I also missed an argument to this function (how couldn't anyone?)

pick 9180ffe Refactor the base object to accomodate the menu's commands

pick a6c2467 Implement the signal handlers for the menu's commands
squash 378ac2b Fix typo in popup_menu variable name
# ... and I also mistyped popup_menu in a signal handler

When you are done, save that temporary file and exit your editor. Git will rewrite your commit history so that you have a clean log, with no commits like "fix this little thing". When you send that patch series to the maintainer, he'll have an easier time reading your code, and he'll be amazed at your meticulousness.

The important thing here is to do one commit per compilation error. Then it's very easy to reorder your commits, where you squash each fix with the corresponding "real" commit.

Two-stone handicap for me on a 9x9 go board, and the birthdayful HPJ still manages to kick my ass by twenty-something points.

They must have put something in the cake, as I had two big slices while HPJ had a single tiny one.

How to use rpm2git

Here is a second screencast on rpm2git (Ogg Theora, 69 MB). This one tells you how to use rpm2git to take the patches from a SRPM and put them in a Git branch.

During GUADEC in Stuttgart and in Dublin, Evangelia Berdou was interviewing people about how they contribute in GNOME. She used this information for her dissertation, Managing the Bazaar: Commercialization and peripheral participation in mature, community-led Free/Open source software projects. Over 100 people from the GNOME Foundation contributed to her study!

There is very valuable information in this work: how many core-platform hackers, core-desktop hackers, secondary-desktop hackers, translators, and peripheral contributors do we have? Which of them are employed to work only on GNOME, on GNOME and other free software, or are not paid for their contributions? How do people move from being peripheral contributors to core ones?

For people thinking about which sub-group of GNOME needs better tools (translators!) and support from GNOME at large, this is exactly what they need to read.

Two things that made my day today.

First, Andrew Jorgensen packaged Meld for openSUSE 11.0, based on Pavol Rusnak's version, which makes git-mergetool awesome.

Two, Ivan Zlatev packaged git-merge-changelog (README), which makes merging ChangeLog entries surprisingly painless. You can even cherry-pick from other branches, where the ChangeLog's diff would not apply cleanly to the destination branch, and git-merge-changelog Just Works(tm) without any manual intervention. This *is* magic.

rpm2git screencast

Here is a little screencast about the problem that rpm2git tries to solve (Ogg Theora, 12.5 MB):

You can also watch the rpm2git screencast in opensuse.blip.tv.

(Screencast recorded with recordMyDesktop. Man, my voice sucks. I swear it sounded better inside my head.)

I'm no security expert, but the Firefox guys keep saying that the new "this SSL certificate is funny" scheme in Firefox 3 is actually a good thing, but that is just bullshit.

Certificates are broken as designed because every web browser (including Firefox 3) has a button that says "let me access the site anyway", and that's what everyone, including yours truly, does all the time. People just do not know, nor care, how to ensure that a certificate is valid. "What's a certificate, anyway? The site says it is secure!"

If anything, the new scheme for funny certificates in Firefox 3 is worse than it was before, because the warnings are more frequent. So, you get really well-conditioned to hitting the button that says, "begone, stupid warning, and let me access the fucking web site already".

People like were thinking of a document-centric desktop before my GUADEC talk. W00t. It's nice to see people tuned in to the same channel.

(There is a lot of material in that blog post. Digest it slowly, bit by bit. I don't agree with the parts about needing to dump the fundamentals of our platform, but that's perhaps better seen from an implementator's perspective.)

Nemo is a file manager for GNOME which displays your files based on time, not on folder hierarchies. It also handles categories for files, like tags in F-spot. I had not seen it before GUADEC, and it's a pretty cool concept — much more developed than the simplistic timeline-of-days that I showed in GUADEC. Maybe we can embed the Mono VM into Nautilus and reuse Nemo's super-sexy widgets for time-based displays.

rpm2git — an easy way to publish distro patches

Various GNU/Linux distros have developed different, ad-hoc ways of publishing the patches they put on top of "pristine" released tarballs from upstream projects like GNOME. openSUSE lets you download full SRPMS from an FTP site, or in a slower but more elegant way through the openSUSE Build Service. Fedora has a CVS repository where they put specfiles and patches. Back in the Ximian days, we had a pretty cute web page, patches.ximian.com, where you could ask for the patches for a specific module, for one or more distros.

Since every distro publishes its patches in a different way, the following happens.

First, upstream developers have a hard time actually looking for those patches to review them and see if they are fit for inclusion in the mainline releases. Where does $distro publish its stuff? How do I know what its latest version is? How do I know what bugs they were trying to fix? Upstream developers should not have to learn the idiosyncrasies of each distro just to get code from them.

Second, distros themselves end up doing a lot of duplicated work. I just found out that both Fedora and openSUSE have patches in their gtk package to do the same things: one for GtkEntry to change the "*" into a "●" when the entry is being used for password entry; another one to let 64-bit builds install the 32-bit and 64-bit libraries in the correct places. If there had been an easy way to share those patches, maybe they wouldn't have duplicated the same work.

I am pleased to give you rpm2git. This is a little tool that you can use as follows:

First, you get a Git clone of an upstream repository, for example, something out of git-mirror.gnome.org.

Second, you get a SRPM and unpack it. You look at the version of that package (say, Nautilus 2.22.2).

Third, you find the Git tag for that version (svn/NAUTILUS_2_22_2).

Fourth, you call rpm2git with that tag name, your specfile, and a destination branch name.

Rpm2git will create a branch starting at the tag you specified, and it will apply the patches from the SRPM as individual commits. The commit messages come from the patch comments.

The idea is that you can later just publish this Git repository, and upstream developers or other distros will be able fetch your branches into their own base repositories. Then, they can cherry-pick patches at their convenience.

You can get rpm2git like this:

git clone git://gitorious.org/rpm2git/mainline.git rpm2git

Over the next few days I hope to start publishing Git repositories of the GNOME packages we ship in openSUSE, with branches for the patches we use.

Note that rpm2git is not the same as VCS-PKG, a really interesting project to go directly from source code under revision control to compiled distro packages.

Here is a fantastic presentation of how the Office 2007 user interface was redesigned (full blog post). Miguel already talked about this presentation when he went to the MIX08 conference.

Obligatory snarky comments: the presentation's slides look like ass. Garish backgrounds. Three different fonts on a slide. Bullets. Anyway, that's the visual material. The actual content of the presentation is very interesting.

Microsoft was in this situation: with Office they had a tremendously powerful piece of software with which people no longer felt comfortable. It's too complex. I don't know all the features anymore. I'm sure it has the feature I want, but I cannot find it. This fucking paper clip never gives me good advice and just gets in my way.

The thing is, designing or improving user interfaces is Real Work(tm). You have to watch people work and see where they get stuck. You have to make prototypes and see how people react to them. Microsoft did that for Office 2007.

On a much smaller scale, this is why I think that the plan for document-centric GNOME has a good chance of being successful. We can show Apple and Microsoft that free software has the balls to change the toplevel way in which people interact with their files. We can definitely turn our desktop into a more comfortable environment than what those proprietary environments gave us twenty years ago.

Speaking of comfortable environments, this is a street cafe one or two blocks away from the grand bazaar in Istanbul. I had the pleasure of having apple tea and coffee with HPJ and JPR on one of those tables, getting relaxed and ready before terrorizing the grand bazaar with our extreme haggling skills.

Let's see how many patterns of good urbanism there are in that place:

• Pedestrian street whose width does not exceed the height of the surrounding buildings, so you feel cozy.
• Public outdoor room which makes you feel sheltered and is nicely decorated.
• Filtered light from the trees, so you can enjoy a cool shade on a sunny day.
• Street cafe to talk and relax and see people go by.
• Four-story limit so that buildings don't overpower people.
• Positive outdoor space so that you have a sense of place.

I would love it if our Human Interface Guidelines were closer in spirit to A Pattern Language (book) than to Apple's HIG.

One of the most pleasurable things about GUADEC is the chance to find out that hackers share common interests outside of programming.

Andy Wingo was telling me about Richard Gabriel's book, Patterns of Software. Christopher Alexander wrote the preface — he's the main guy who defined those architectural and urbanism patterns from above.

JPR, HPJ, and myself were talking about peak oil. Will free software even be relevant if we can't keep the Internet running?

It turns out that our baby and Chris Blizzard's as well have the same kind of baby chair and swing.

It's fun to talk about camera-nerding with Hub.

Today I'm 0x20 years old. Yay.

I'm writing a little utility that generates Git repositories from some unpleasantly-formatted data. The test suite for this was really simple to write: you can simply ask git, "give me the SHA-1 hash that you have for the content" at the end of the test run (i.e. "git-cat-file -p HEAD" and parse out the "tree" hash from there). If the obtained hash matches your expected hash, then you know the test succeeded. This is much easier than comparing all of the expected/obtained content by hand.

Document-centric GNOME

Here is my presentation from GUADEC: Document-centric GNOME (ODP).

The code for document-centric Nautilus consists of the journal view and the Nautilus extension interface for journal providers. This code is not finished yet (nothing gets displayed to the screen; it's all engine code), but you can take a look here:

git clone git://gitorious.org/nautilus/mainline.git nautilus-document-centric

The master branch contains the document-centric code, which is built on top of nautilus-2.22.2. You can also visit the Gitorious repository for document-centric Nautilus and create your forks there.

John Anderson has posted a great little tutorial on Nautilus tips and tricks. Life-savers for me: the list of keyboard shortcuts and enabling the "advanced permissions" view.

Hot damn, someone is porting DTrace to Linux (source code). Maybe Mortadelo will be useful in the future again.

Ah, Istanbul.

The Blue Mosque introduced me to painted domes and arches. Now I know how to paint and decorate our vaults on the inside, which are just plain whitewashed right now.

Mario Ðanić has another interesting post about distributed version control systems. He proposes that each developer (or at least, every maintainer) could use the DVCS of their choice, but then we could have a common web/collaboration interface to all the DVCSs.

My current favorite way of developing against a stable release:

$ cat ~/bin/make-nautilus
#!/bin/sh
module_name=nautilus
diff_name=~/suse/11.0/src/SOURCES/nautilus-document-centric.diff
anchor_name=OPENSUSE_11_0_PATCHES
branch_name=document-centric
cd ~/src/$module_name
git diff $anchor_name..$branch_name > $diff_name
cd ~/suse/11.0/src/SPECS
if rpmbuild -ba $module_name.spec
then
    cd ../RPMS/i586
    gnomesu -c "rpm -Uvh --force *$module_name*"
    notify-send -t 0 "$module_name is installed now"
else
    notify-send -t 0 "$module_name doesn't build!"
fi

John says:

The main reason [why git-mirror.gnome.org doesn't make git.gnome.org any easier] is of course the polluted logs (filled with git-svn rev id metadata). I would resist any module having a Git repo with such ickyness in its history.

This is a non-issue. Ruby on Rails used to be hosted on Subversion, and then it switched to Git. To do the conversion, they simply used git-svn. You can do "git clone git://github.com/rails/rails.git", then "git log" and search for "git-svn" in the output in order to find the git-svn metadata.

You'll see this:

... git-based development goes here ...

commit 67022671bfa28d5675a30925a8d1e271c576f4d2
Author: David Heinemeier Hansson 
Date:   Thu Apr 10 22:09:13 2008 -0500

    Testing commits

commit ed99dda174da439a0947cdabea3babf027c672ac
Author: Rick Olson 
Date:   Thu Apr 10 18:06:05 2008 +0000

    Change validates_uniqueness_of :case_sensitive option default back to true (from [9160]).  Love your database columns, do
n't LOWER them.  [rick]
    
    git-svn-id: http://svn-commit.rubyonrails.org/rails/trunk@9248 5ecf4fe2-1ee6-0310-87b1-e25e094e27de

... svn-based development went here ...
	    

So, in the commit logs, you have everything since $beginning_of_time until $switchover_date with the git-svn-id strings, and everything after that without any such garbage, as would be normal for "plain" git repositories.

Having that metadata in the log actually provides valuable information.

If you have to do code archaeology (which Eric Sink calls "traceability"), then the commit log will tell you when the svn->git switchover occured. Before that point, you know that any branches are dead-ends and merges are funny (svn didn't handle them).

You'll know that before the switchover point, information about code attribution will not be 100% clear, as you couldn't specify --author in an svn commit (so you'll perhaps have to look at the actual ChangeLog and hope that the committer was kind enough to say "original patch by $author").

When you do a conversion between revision control systems, you keep the old system around in read-only mode for if anything goes wrong. It's nice to know that if we ever need to check something in the original SVN repository, we'll have the SVN revision numbers from the git-svn metadata.

Finally, the git-svn strings in commit logs will disappear really quickly from your everyday view. They just appear further and furter back in time, and you seldom look at those commits, anyway.

Mario Ðanić has been investigating about adapting Gitorious for KDE. He says he would be happy to talk to people who would like to adapt Gitorious for GNOME's needs as well. Among other things, Mario is working on the Summer of Code to write a GNOME client for the openSUSE build service.

Git-mirror.gnome.org is AWESOME and John Carr deserves large amounts of beer for it. The git-mirror has already saved my ass twice this week ("Where is this patch in trunk? Was it backported to the stable branch?"). Now that we actually have full Git repositories of GNOME, we could easily move to using Git for everything.

Søren, Bryce, James, and myself had a pretty productive time hacking on support for RANDR 1.2 in gnome-desktop, gnome-settings-daemon, and gnome-control-center, all in Git repositories.

Gitorious is like a free version of Github: you can create public Git repositories in a central server, push to them, and monitor who clones your repositories. Later those people can inform you, "I have some cool stuff in my repo; you should fetch those changes from it". Or you can say the same to them, and Gitorious/Github will notify the people in question. This is far, far more productive than monitoring an svn-commits-list or similar.

Gitorious is hosted in a Gitorious installation itself, so you can of course "git clone" is source code. It would be reasonably easy to use this in GNOME's infrastructure, and it would automatically let module maintainers communicate better with contributors (and allow contributors to play with experimental branches without disrupting the maintainer's work).

... Which reminds me, if you are tired of wasting your time with Subversion, be sure to attend the BoF on distributed version control systems at GUADEC, where Behdad and yours truly will delight you with our widely-acclaimed acrobatic act.

This year I am mentoring two students for the Summer of Code:

Andrei Soare is working on measuring memory fragmentation in the GNOME libraries. The idea is to find the main culprits for fragmentation, and see what we need to do to fix them (use more stack allocations? provide substring APIs that can take a buffer and a length, instead of g_strdup()ing temporary crap everywhere? use flat buffers with pointers into them for static structs rather than structs full of pointers to individually-allocated sub-buffers?). Andrei's code is available as a Git repository. So far, he has a modified version of of Stefan Kost's bprof, suitable for use with Stuart Parmenter's memview. Andrei has found a few bugs where we do things like using g_free() on a malloc()ed buffer, or vice-versa. I hope he starts blogging his first fragmentation plots soon.

Stanislav Slušný is working on profiling the calendar in evolution-data-server, in particular the engine for live queries. The query engine is very simple; it just iterates through all the items in a calendar and returns the items that match the query. We think that most queries are of the form, "give me all the items in $date_range", so the query engine could use a smart data structure like an interval tree to avoid scanning all the items. So far, Stanislav has added a logging mechanism to evolution-data-server so that we can see which queries get performed (by Evolution itself, the panel's clock applet, and various things across the desktop), and how long the queries remain active. This is available in a Git repository. Stanislav showed me a couple of pretty sexy plots of query lifetimes; let's hope he blogs about them soon.

And now for a gratuitous baby picture.

Multiscreen hackfest for openSUSE

Here is a belated announcement for the multiscreen hackfest we are having at openSUSE this week and the next.

Do you have multiple monitors connected to the same machine? A laptop and a projector or an external display? Do you get a lot of pain from trying to get it all to work?

If so, be sure to participate in the multiscreen hackfest!

Some work we are doing:

• Integrate Søren Sandmann's, Bryce Harrington's, and James Westby's work for gnome-desktop, gnome-settings-daemon, and gnome-control-center so that the Display capplet will let you configure your multiple monitors easily.

• Pay attention to all the bugs in X drivers that we run into while testing the configuration tools. Document any quirks that need to be set in xorg.conf by hand.

• Fix all the bugs in applications when used in multiscreen mode ("I clicked on a button but the dialog appeared in the wrong monitor").