Today I finally got round to activating ssh access on my hosting account which means I can set up gitweb to publish my git repositories. I’ll be pushing my changes to these repositories as I get things working. The gitweb interface is available at http://git.jsharpe.net/
Archive for May, 2008
Well today is the official start of coding for Google Summer of Code, but for me I won’t be able to start coding for another couple of days; I have an exam tomorrow and a programming assignment due Wednesday so I can’t really begin work till then.
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?
Firstly, hello to all that are reading on Planet Gnome as this will be my first post that has been syndicated there. And by way of introduction, I’m a 23 year old student in my final year at York University studying Computer Science and Maths. I’m working on bug 48004 to implement individual workspace wallpapers. (For those that are interested you can find my previous posts at http://gsocblog.jsharpe.net/.)
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:
- doesn’t return to current branch after switching to master for rebase
- doesn’t unstash working copy changes that have been stashed
- proper support for using svn branches i.e. assumes you want a git repo with only either trunk or a single branch in it