I've had pretty good productivity lately. In fact, I currently have 8 outstanding patches against Wine that haven't been committed yet. Alexandre has been busy with rearranging the 16/32 bit code, amongst other things, and commits from external contributors have slowed down a lot. I find myself wondering, not for the first time, if Wine would not proceed quicker with more committers. OTOH the Q&A Alexandre provides is certainly a benefit, especially for people like me who aren't hugely experienced with Win32, nor writing thread safe, OOM-safe code in C.

I've been mostly hacking on winecfg - the Wine projects official configuration GUI. The eventual plan is to scrap the config file, and move it all into the registry. In fact, this is a goal for the 0.9 "easy to use" release of Wine. Win32 isn't the easiest toolkit to work with, and it becomes doubly harder when you don't have an IDE to write the gobs of template code it needs. As a result, progress is not as fast as I'd like. Still, the end result should be good.

I started looking at MSN Messenger last night. If worst comes to worst, and Gaim and Jabber are forced off the network (I doubt that'll happen), then we might have a backup plan in being able to run MSN Messenger itself. Another interesting possibility is a build of Gaim that is a WineLib app and uses the MSN ActiveX control directly. More likely however, is that the Gaim team come to an agreement with Microsoft, or the plugin becomes "contraband" software like the DeCSS and MP3 plugins - we'll just shove it into the freeworld repos.

autopackage

We're getting ready for the 0.3 release of autopackage. This is the first release to feature a GUI, and though it's still incomplete I'm pretty pleased with how polished it's feeling. We've put a lot of work into thinking through how users are going to interact with software installation on Linux in the future - the long term goal is that packages can be dragged out of the webpage, direct onto your panel and all the complex machinery of package management takes place behind the users back, entirely automatically.

We hope that if we do some day build such a system, it'll be generic, ie not tied to autopackage.

Some of the spit-n-polish work we put into the autopackage GTK front end will make its way back to GTK eventually. For instance, we have developed a few patches for EggStatusIcon. Whereas before it blinked harshly on and off, it now gently pulses. Small details make big differences. Expect more such transition-animation work in the near future.

We've also got code now that will automatically download the autopackage support code and GUI if they aren't present on the users system. This works surprisingly well, and is now the preferred way for people to install autopackage (unless they are a developer). Our download times are currently satisfactory - about 8 seconds on dialup for the core code, and about 15 seconds for the GTK gui, meaning a total of about 20-25 seconds delay for dialup users. For ADSL/cable users, it's probably nearly instant. Those times will go up as we add more code, which might start getting problematic - it could be worth learning about optimizing code for space, though I doubt there's much we can do that will make a big difference.

That code was written not by me, but by Hongli and Curtis. I haven't said this before, but I feel I should - they are consistantly smart, helpful, reliable contributors who produce work of the highest quality. They're the sort of contributor every project maintainer wants about a hundred of, and I'm very lucky to have two. Still - the task is pretty big, even for three of us working on it as our primary projects. Our last release was on the 12th July.