I am very proud of GNOME (and our new decisive GNOME Foundation board) for the initial progress we’ve made on the lack of involvement of women in our project. The discussion has opened a lot of peoples’ eyes to a problem that they didn’t recognise before, and we’ve already taken some steps to deal with it:

• GNOME’s Women’s Summer Outreach Program (WSOP): 6 mentored projects (3 more than planned, thanks to Google’s support) bringing Women into our community. The quantity and quality of the applications surprised many of us, and is great ammunition against the “women are biologically incapable/predisposed” loonies. For the regular Google Summer of Code, I had 1 application for a Glom project. I had 5 for WSOP, some of which were very experienced already, though not in open source.
• GNOME’s Code of Conduct (or “Ethics”, if you prefer) looks likely to become official, reinforcing our existing inclusive and tolerant community, and advertising it to the people looking for a chance. I just need to find a readable version of that inspirational first sentence. Suggestions are very welcome.
• What’s next?

Now I’d like to start seeing more women on Planet GNOME and GNOME’s Planet SOC (Update: Planet WSOP 2006). I’m encouraging my WSOP applicants to get involved even though their applications weren’t approved, and they do seem more interested in that than the money, so I have high hopes. I’m suggesting that they start blogs, or that they mention their experiences on their existing blogs, and that they try to be involved in the existing mailing lists (such as gnome-love) while they are also getting direct help from me, setting up their development environments and learning about the project. While not wanting to scare them away, I’d like to get them involved with GNOME’s community as soon as possible, because that’s what makes people stay, and what keeps them learning.

There’s also been a lot of Pangolossianism from men during the discussion, along the lines of women not being generally biologically capable, or not being generally interested, and . This is the same 19th century nonsense that said that the poor were poor because they should be poor. Like most prejudice and conservatism it’s generally justified by selective anecdotal examples and resists contrary evidence. This always displays a fantastically selfish lack of empathy or imagination when confronted with the actual numbers.

Since seeing those discussions I am more convinced than before that there’s some real problems to solve, and I’m glad that we are solving them. And when women can help each other then they don’t have to waste time persuading men about this anyway.

Update: I forgot to mention, I was particularly persuaded when someone mentioned that, while female involvement and achievment in the sciences and mathematics is low in most schools, all-female schools have higher achievement rates in these subjects than the men in those regular schools. Obviously there are other factors in these schools, but it shows what is possible, and what should be possible without creating special environments. Anyone have a link to an actual study? – presumably the statisticians have tried to take account of details such as selection bias.

GNOME’s performance-list mailing list is very high signal at the moment, though the archives seems to have lost emails for a few days.

These test results and suggested workaround/fixes are worth a gazillion viciously uninformed osnews or IRC discussions. Here’s a summary of what I’ve noticed recently though I can’t find the exact archive URLs for the stuff that I remember seeing, so this is full of errors that should be corrected in the comments so I can update it:

• Workarounds in GTK+ to use the older GDK instead of Cairo, to test whether cairo is responsible, and as workarounds if there are cairo problems to be fixed. At least one of these changes seems to have a noticeable effect, at least on non-FPU hardware.
• Text drawing optimizations: There might have been a slow down in text rendering (maybe in freettype?), and this might even be more of the cause of the GTK+ 2.6->2.8 slowdown than the use of Cairo.
• Cairo optimizations: I’m pretty sure that I’ve seen some talk of patches optimizing small but significant parts of Cairo, but I can’t find them now.
• GTK+ subsetting. Matthias has some patches for embedded environments that cut the GTK+ code size down by about 15%, by omitting unnecessary API, saving a couple of hundred K. (gtkmm has had this for a few weeks now, offering significant code size and runtime savings.)
• Nokia’s 770 Internet Tablet versus floating point calculations: The 770 doesn’t have an FPU (floating point unit), so any use of floats leads to a big slowdown, even if it’s just passing a float through the API. This is unlikely to be responsible for a big slowdown seen on the desktop, but when they fix this on the 770 then they can start looking more at other optimisations that will help the desktop too. Note that the OLPC does have an FPU.

As far as I can tell, the jury is still out on whether Cairo is the change that made GTK+ 2.8 slower than 2.6, and it’s still not entirely clear whether 2.8 is indeed slower than 2.6 on regular desktops. Note also that Cairo hasn’t had much optimization work until now so there should be lots of easy optimizations. But performance-list is figuring all this out.

You can thank OpenedHand, Carl Worth, Matthias Clasen, and the others (not me) for getting this done.

As usual, these all seem like small parts of the code that have a large impact and that can be relatively easily fixed. I continue to believe that this is almost always the only meaningful form of optimization. Optimization by design is rarely possible other than by just trying to avoid well known problems and trying to generally allow room for optimizations in future. Amost all projects whose primary aim is to be fast or small end up being unusable, unmaintainable, or incomplete, though exceptions to this rule should be possible.

Yesterday I released gtkmm 2.9.8, with GNOME 2.15/16 API freeze approaching on July 16th. Mostly everything is done, apart from a problem with the custom print preview, some of the TextBuffer serialization API, and an improvement to the recent files example. So, C++ people, do look at the new API, because now is the chance to fix it. Later it’ll be stable ABI and you’ll have to live with it.

There’s lots of new API in GTK+ 2.10, and users of gtkmm should be incredibly grateful to some new contributors who did most of the hard work:

• Marko Anastasov, who has single-handedly wrapped all of the new printing API, written examples, and even written a printing chapter about it in the gtkmm book, all according to my pedantic standards. He has very quickly figured out how gtkmm works, and how it should look.
• Armin Burgmeier also did most of the recent files API, with help from Marko.
• Jonathan Jongsma (who should be on Panet GNOME) covered lots of the bits and pieces that were left over, while also steering cairomm to API stability, improving our documentation, restyling our website, and generally looking a lot like a future gtkmm maintainer.

There’s a lot of employment opportunities out there for GNOME developers at the moment to do embedded stuff. That’s a nice reward for all your contributions, and a chance to spend your time on something you love. I personally know of the following:

• Helsinki, Finland, with Nokia, on Maemo.
• Several jobs in the midwest U.S. (can’t say where yet), using gtkmm/GTK+ on embedded devices. Ask me.
• Sunnyvale, California, with Palmsource, (possibly semi-secret, but Google found a public email and a craigslist posting.)

And I am tempted to try to hire someone cheap in Germany. I have a little more work than I can handle by myself, but I’m not sure that I have enough to cover two incomes. And German taxes make employment quite expensive for small businesses, not leaving much left over for the employee.

Last year at GUADEC I promised to help the SUN people make their (lengthily vague) API/ABI stability documentation requirements meet up with GNOME’s API/ABI stability practices, so everyone can learn about the good stuff that we do, and so we can recommend some minor improvements. We almost got there.

But the draft document is still not quite ready. The main issue is the library versioning section. I’ve listed some of my confusion there. As far as I know, GTK+ just doesn’t use it because it’s more trouble than it’s worth. When I’ve tried to follow the instructions for using it in the past, I’ve caused ABI problems when I just wanted to say “here’s some new ABI that doesn’t break the old ABI.”. So I’d like either a knowledgeable explanation of why it should be ignored, or clear examples of how to use it. Feel free to fill up the comments with clues.

The next GUADEC is upon us, and a year seems too long to get this done.

GUADEC

Tomorrow I fly to Vilanova, near Barcelona, to attend the GNOME conference. Afterwards, I’ll stay in Barcelona over the weekend for some touristing.

I’m looking forward to GUADEC as a kind of holiday where I can spend the time just doing things that I find interesting. I’ve had the guilty pleasure of not helping at all with the organisation, though I’ve been on the mailing lists, so I’m more than usually grateful to Quim Gil and his team for their fantastic work, and for the stress that they will probably endure/enjoy for the week.

I know that they don’t speak Spanish in Catalonia, but there will be people from other parts of Spain. I would really love to practice some of the simple Spanish that I’ve learnt. I’m now up to lesson 17 of part 2 of Pimsleur’s Spanish, and I need to see if I’ve really learnt anything.

Contributing to Glom

At GUADEC, I’ll try to recruit contributors for Glom. So far, I’ve not had success getting people involved, though I knew there’d be a delay while it even got into the distributions for testing by users. At least life is easy now with Ubuntu Dapper at least – you can even build Glom without using jhbuild.

To make contribution easier, I’ll do some more reorganisation of the source code, and some simple developer documentation. In the meantime, I marked the easier Glom tasks, and added some more clues about how to implement them. Some of these tasks are appropriate for people just getting started with C++ or gtkmm. Interested people should find me at GUADEC.

If you have a laptop with you, I’ll take the time to help you setup Glom and setup your development environment, and I’ll show you how to make patches. If you don’t have your laptop, I’ll show you stuff on mine. I’ll introduce you the code and show you how to get started on one of the simple tasks, based on your current experience. I’ll try to do this online too, but a week in the GNOME Village is a real opportunity to do this properly in person. I’ll do this in English or German.

I also added 3 more examples in CVS, and put some screenshots of the examples online. Two of them (Music Collection and Project Manager) are really simple, but Film Production Manager is quite large and involved and is based on a real situation.

Could someone put this poster up in Munich’s Technical University, please?

Because open source wants to be the solution, not the problem.