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?
James, you probably want those WorkspaceNames under some kind of Workspace key (so that they don’t clutter up /desktop/Gnome). I’d tend to go with the second option too.
As for fitting it into the GUI, it’s probably too much to ask the user about a default as well as each individual workspace (since if they never see it, they’ll wonder why they have to set it), so it might be best just to set it whenever the first/main workspace wallpaper is set.
I’m not certain that’s the best solution, but I think it’s probably better than loading the configuration (which will presumably tricky to begin with) up with more options…
Having just read the gconf page on gnome.org it seems the convention is to simply require the user to configure twice if they run on older environments, so it seems the best option in that case is to simply always write per workspace settings in the newer version and just make the user reconfigure if they use an older version of Gnome.
Ohhhh, stoked on this project. Was looking for this feature, then stumbled upon this. Good luck!
Rich,
Fellow 2008 GSoC’er!
Just wanted to let you know that something similar has been included in the most recent Compiz: http://lists.compiz-fusion.org/pipermail/community/2008-May/000172.html (see plugins-extra) I read somewhere that Gnome can’t/won’t let Compiz handle the backgrounds, but I don’t know much about it.