I’ve put most of the patches (except the gnome-control-center one) into bugzilla:

gnome-desktop: http://bugzilla.gnome.org/show_bug.cgi?id=543596

http://bugzilla.gnome.org/show_bug.cgi?id=544241

gnome-settings-daemon: http://bugzilla.gnome.org/show_bug.cgi?id=544178

eel: http://bugzilla.gnome.org/show_bug.cgi?id=544223

nautilus: http://bugzilla.gnome.org/show_bug.cgi?id=544242

gnome-control-center patch is available here: http://git.jsharpe.net/ but is still a work in progress.

I’d appreciate feedback on the patches.

I think that the deciding factor for which DVCS to use is the quality of the tools that enable interoperability between all the other possible tools. Obviously there is tailor which automates migration of patchsets between different DVCS’s, but I want more native support within the tool I’m using; i.e if I’m using git I want to use “git’s terminology” to “pull and push” from the remote repository. I’ve found  git-bzr for interoperating between git and bzr, and similarily there is bzr-git for the other way around, although I’ve not yet had time to see how either of the tools work.

Basically I think that the decision of which DVCS to choose should be based upon which DVCS is the easiest to import into all the others(or at least just the most popular ones!). This makes all the other points regarding speed etc really quite moot so long as these tools work well (In particular I’d like to observe how well they maintain merge histories between the DVCS systems – maybe when I get time in the next few weeks I’ll do some experimenting).

First hurdle was git-svn doesn’t understand about bare repositories – it always looks for a .git directory. Fortunately this is easily solved since git-svn does support the $GIT_DIR environment variable. So I simply set this to . and run the git-svn commands from within the repository directory. So I initialise the repository with the appropriate git-svn init command and then call fetch to retrieve the svn history.

The next problem is that the refs fetched using git-svn are placed in refs/remotes which isn’t cloned when you do a regular git clone. So we need to plugin to the hooks to update the refs after we update the repository; an example script of how to this is provided below (Taken from dscho.git):
#!/bin/sh

git for-each-ref –format=”%(refname)” refs/remotes |
sed “s/refs\/remotes\///” |
while read ref
do
git update-ref refs/heads/svn/$ref refs/remotes/$ref
done

git for-each-ref –format=”%(refname)” refs/heads/svn |
sed “s/refs\/heads\/svn\///” |
while read ref
do
if ! git-rev-parse refs/remotes/$ref > /dev/null 2>&1
then
git update-ref -d refs/heads/svn/$ref refs/heads/svn/$ref
fi
done
I call the script from the post-update script (which you should make executable by running chmod +x hooks/post-update). This script suffices but doesn’t quite do what I’d like; I’d like the tags to be placed in refs/tags/svn rather than refs/heads/svn, but the script linked will do for me for now.
My cloned repositories are available at http://git.jsharpe.net/, unfortunately I can’t offer the git protocol since my host doesn’t allow it. As I get time I’ll convert more of the Gnome repositories; I’ve only converted the ones I know I’m going to be working on for the moment.

In the meantime though I’ve been getting Gnome SVN compiled, using the git-svn support in jhbuild, which has meant I’ve committed a few improvements to the git-svn support to speed up the process; namely I’ve improved the svn:externals support by parsing the unhandled.log that git generates. I’d still like to improve the support further, adding support for git-svn repos with a full complement of branches being one(although doing this properly will require additional information about how the repository is laid out), but it’s usable in its current form for now. I’m also currently using icecream to speed up my compiles, currently running on my desktop and laptop, but I’d like to setup a minimal VMWare image containing just the icecream client and minimal dev environment so that I can run this on the other machines that are at my parents, when I return there after finishing uni. Does anyone know of any existing images that are available or will I have to roll my own? A quick glance at the VMWare virtual appliances shows no results for this kind of appliance so it looks like I’ll have to roll my own.

I’ve also been looking at the general code structure for the background drawing code and generally getting a feel for what needs to be done in this regard. In particular, I need to design a structure for the GConf keys that works with backwards compatibility: the background configuration is currently stored in the /desktop/gnome/background GConf key. The two current solutions I’m thinking of are adding a subdirectory for each workspace configuration /desktop/gnome/background/Workspace1 or storing it as /desktop/gnome/Workspace1/background. I’m currently leaning towards the second solution as it means that the scheme can be extended to support per workspace properties for other keys such as /desktop/gnome/interface for setting per workspace themes/fonts. The idea would then be that if a workspace specific key doesn’t exist in /desktop/gnome/*WorkspaceName* then it would fall back to the key in /desktop/gnome/. This provides the backwards compatibility aspect with older gnome installations. The challenge with this however comes when writing the configuration gui – when do you update the default background key?

I’ve spent the last couple of weeks finishing up my masters project, and gave my presentation on that last Friday. Its good to get it all out of the way, although my supervisor has suggested submitting my project to the S+SSPR conference which means I need to edit my paper by the end of the month. I also have a computer graphics assignment to complete and three exams to revise for before the official start of GSOC on 26th May, so quite a bit to do before then. I suspect I’ll be juggling my time between uni and GSOC up till the 10th June which is the date of my last exam at uni.

In the mean time I’ve been looking through the code that I’m going to be working on; the desktop wallpaper code seems to be spread across numerous modules: gnome-desktop, gnome-control-center, libeel, libwnck and libgnomeui. Initially I’ll be working on getting the backend part working for which the following criteria need to be fulfilled:

• Support wallpaper per workspace (and possibly extending this to be a workspace profile/state see bug 113640)
• Update the GnomeBG api to support multiple workspaces – hopefully this will help stabilise the api and remove the need to explicitly define use of the api.
• Support desktop wallpaper rotation. (The code to do this is largely there since there is already support for animated backgrounds which rotate over a given period of time)
• Support wallpapers per desktop – this will involve adding support for Xrandr and Xinerama (although I’m tempted to argue that we should just support Xrandr since Xinerama is no longer in development)

I’ve also been hacking a little at jhbuild; I’ve setup jhbuild to use git-svn in place of svn but it’s handling of externals is painful! I’ve put in a hack that checks the current svn revision of the git-svn tree before and after the rebase, and conditionally updates the externals only if the svn revision version has changed. Now this works fine if the svn:external is for a given revision number in the external repository, but if its not then we still need to do an update because the external may have changed whilst the current repository hasn’t. This kind of breaks the notion of a revision number in svn as it means that a revision in the repository is dependent upon the state of an external repository i.e. it will change over time! Not a good thing for repeatability in the future. I’m thinking about storing some metadata within the git-svn checkout dir relating to the location of externals(if any) as a way of avoiding walking the whole svn directory structure which is particularly slow! The alternative is to implement the externals as git submodules, as noted in a fixme within the code. There’s also a number of other features missing from the git-svn code too that I may roll patches for:

1. doesn’t return to current branch after switching to master for rebase
2. doesn’t unstash working copy changes that have been stashed
3. proper support for using svn branches i.e. assumes you want a git repo with only either trunk or a single branch in it

I’ve also had my SVN account approved and am just waiting for the accounts team to do the final check and set it up, although I probably won’t use it all that much as I’ll be doing my development in my local git repository as i described earlier.

I got stuck compiling pixman with the same error as found here. Unfortunately the fix provided in this case didn’t work for me. I tried both using jhbuild build -a and adding the appropriate PKG_CONFIG_PATH lines to my .jhbuildrc file without success.

Turns out the error was due to one of the tests in pixman was trying to link against gtk which had yet to be built by jhbuild and so was trying to pull in the system version of gtk which linked against the system version of glib, which was listed first on the command line and hence took priority, resulting in the error.

Now I’m not the only one to have this problem: http://bugzilla.gnome.org/show_bug.cgi?id=344358. The reason for the problem is when the system already has the dev packages installed for the system’s installation of Gnome, in my case this is because I am running Gentoo. The solution given on #gnome-love on irc.gnome.org was to remove all *.la files from my system. This isn’t really an acceptable solution for a distribution that is compiled from source – I need the libtool library files to update my system!

Making sure a build system compiles on a fresh checkout for a new user is a problem that I came across when maintaining the build system for a fluid dynamics software suite I worked on at BAE Systems. It’s all too easy to write a build system that relies on source already being installed, and miss the small things that a new user will be stumped by, even if it is only a 1 minute fix to you. I wouldn’t be surprised if I start hacking at jhbuild in the near future as these things do niggle me, especially if I can think of a way to fix them!

Despite all this I’ve managed to, through a mixture of running jhbuild with the -a flag, manually running configure, and modifying my .jhbuildrc file to set environment variables and build options, to get most of the latest dev version of gnome compiled now (at least the parts that I need to work on). Next step is to point the jhbuild moduleset to my git repositories (I’ll post a url once I begin development), although to avoid future pain I may resort to setting up a VMware image with Fedora or Ubuntu on it to use as a sandbox environment for testing.

Using git to access svn repository
Some of you may be interested in how to use git to access a svn repository. (A more comprehensive guide is available here) This is how I used it to clone the gnome repositories:

First run:
git svn clone http://svn.gnome.org/svn/jhbuild -T trunk -t tags -b branches
This tells git to clone the jhbuild svn repository with trunk directory named trunk, tags directory tags and branches directory branches. (A pretty standard repository layout however if the repository is laid out in a non-standard fashion there are ways of making git svn play nice here too – ask if you’d like to know).
This will churn away for a long time checking out every single revision from revision 1 to obtain the complete history( the -r flag can be used to reduce the number of revisions that are checked out to a smaller number).
Once this is completed we will then have all the branches and tags from the svn repository available as remote branches.

Space Savings using git over svn
I’m still amazed at how well git compresses repositories. After cloning the nautilus repository the .git directory was 2.0G. Running the command:

git gc –prune –aggressive
compresses this down to 381M.

Working with a git svn repository
Keeping up to date is simple. You simply run the command
git svn fetch
from within your working copy. This will download all updates on all the branches and tags from svn that happened since you last updated. (Incidently if during the initial clone step your connection dies or you need to stop it then to resume the clone you just have to run the above command to resume downloading the history).

Day to day development then should occur on a branch which is then rebased against the master when svn updates are pulled down. Changes can then be pushed back to svn using git svn dcommit.

The project consists of two main parts: the backend, which involves dealing with GConf and all the management of the background pixmap, and the user interface; adding the flexibility of choosing a background for each desktop introduces new usability challenges to the interface; its desirable for new users to be able to quickly pick up the interface for changing the background for all desktops, for existing users to not be confused by the new interface but at the same time be able to fully utilise the full functionality available easily.

Its possible that I finish this work early. In which case I have plans to add new functionality to the background system. Some ideas I have already are:

• Background rotation every N mins
• New colour gradients
• Watermarks e.g. a corporate logo can be blended onto the background chosen

I’m open to other ideas too, so if you have any then get in contact with me.