I had an email discussion recently with Anne Østergaard about the major lack of female involvement in GNOME, and free software in general. I’m so proud of our community and how it lets talented people get involved, without all the obstacles that they find in the offline world. But it’s obvious that women are not yet taking advantage of this opportunity. I feel ashamed of that.

I tend to blame schools, universities, parents, and society for not encouraging young women to be enthusiastic about engineering and software. In view of of our openness, plus our general left/liberal leaning I feel sure that we are part of the solution rather than part of the problem. Even if we can’t influence kids when they are young enough to start forming these opinions, surely we should be seeing the few women who are determined enough to get involved despite all the problems. But why isn’t that happening yet?

I don’t know how to personally help fix this problem. I don’t find new open source developers directly. They usually find us. Do we need to change something about how they see us or find us? Are there organisations that are trying to fix this problem that we should make contact with?

I don’t believe that this is about emphasizing different activities. It would be wrong to say “Here are some less demanding tasks for the girls”. And as long as the atmosphere is not actively sexist, I don’t think it’s a problem that we spend our time discussing technical stuff. I don’t think there’s anything particularly male about technology, or how we approach it. (We do need to get more non-technical people involved, but not for this reason.)

But clearly there’s something wrong in my theories, or I am overlooking something, because we should be doing better.

Update: Jeff pointed me at this Flosspols report. It’s fairly readable and has some interesting conclusions and recommendations, despite the unfortunately small sample size, but I think Callum does a better job of saying much the same thing.

One contradiction that troubles me is that we a) obviously need to do something proactive, but b) we apparently discourage some women simply by giving them too much help, making them feel uncomfortably singled out. But on balance, I don’t think we can make things much worse than the current 1%, and we can’t be more unjust than what we have now, so some kind of affirmative action must be worth a try. Maybe some kind of group project, like a women-only Summer Of Code in which the students are allowed to work together? If someone had a plan then us F/OSS veterans could try to make it happen.

Or should we advise women to try to conceal their gender online?

I posted this to gtkmm list today. I’ll repeat it here because smart people read planet GNOME.

I have recently done some work to optimize gtkmm for code size, for use on embedded devices, such as Nokia’s 770 internet table. I was concerned that, for instance:

• the _stripped_ code size of gtkmm 2.6’s libgtkmm .so is 2.5M on i686,
• which is comparable to the size of libgtk-x11’s .so (version 2.8 is 2.9M).

It didn’t seem right that the wrapper is as big as the thing it wraps, because our method implementations are so small.

I have discovered that a large part of this code size is explained simply by the size of our API, and we have a lot of extra convenience API compared to GTK+. Simply exporting a symbol adds to the code size. I shaved a few 100K off the .so size just by using the static keyword on private functions, to stop them being exported. The 2.5M number above is including these easy optimizations.

Optional API

I also added some glibmm configure options to remove rarely-used API. Remember, nothing will change on regular linux distros, because they won’t use these options:

• –enable-api-properties=no
  You can use get/set_property<>(“propertyname”) instead.
• –enable-api-vfuncs=no
  These are rarely needed. You can use the C function pointer instead.
• –enable-api-exceptions=no
  Methods that throw an exception have an extra std::auto_ptr& output parameter when this option is used. This allows use of the “-fno-exceptions” CXXFLAGS, which does not have much affect, but being able to use “-fno-exceptions” means that “-g -Os” (Optimize for code size) can start to be significant. Together they reduce code size by about 15%.
• –enable-deprecated-api=no
  Do not build deprecated API, such as Gtk::FileSelector. This option has been in tarballs for a few months already. This must be specified to gtkmm as well as glibmm.

These options will soon be in releases of glibmm 2.6, 2.8, and 2.10. Necessary changes will be in gtkmm 2.6, 2.8, and 2.9/2.10. Until Cairo is fully optimized, people are using GTK+/gtkmm 2.6 on embedded platforms, but some are using glib/glibmm 2.10.

Together, with the mentioned CXXFLAGS, these reduce total code size for all of the gtkmm 2.6 .so files by around 800K, or 23%.

Virtual methods

However, there is another huge gain to be made by removing default signal handlers, such as Gtk::Button::on_clicked(). The problem is that they are virtual methods, so we have to pay for them even if we don’t use them. We must pay for them in – code size: That’s a lot of symbols in libgtkmm, and the symbols must be listed in applications that use libgtkmm. – load time: the symbols must be resolved by applications that use libgtkmm.

Gtk::Widget has about 60 signals, so that’s at least 60 virtual methods for each widget. As far as I can tell, this increases the code size of each derived class, even if a derived-of-derived class, maybe due to multiple inheritance.

I have not yet committed this configure option to cvs, because this is the most disruptive option. Overriding virtual methods, instead of connecting signals, is quite convenient, but I don’t think it’s worth the cost on an embedded platform just for convenience. I might commit it later. The patch is here: http://bugzilla.gnome.org/show_bug.cgi?id=341380

It removes an extra approx. 500K from the libgtkmm code size.

I also have a simple patch to remove libatkmm, which is not yet very useful on embedded devices.

Failed attempts

• I have not noticed any significant reduction in code size by using the -fno-inline CXXFLAGS. I had thought that there might be a lot of RefPtr or sigc:: inlining, but I guess that the implementations of these functions are not significantly larger than a function call itself.
• I have tried ripping libsigc++ apart to reduce the number of templates and template parameters that are used, with almost no effect. Based on this, and my other code-size investigations, I no longer believe the commonly-mentioned theory that libgtkmm is large because of too many template instantiations. I’d gladly be proven wrong.
• I can strip a few more 100K from the code size by turning the /private/*.h callbacks into functions instead of class methods, and marking them as static, but I would then need to make various protected parts of the classes public.
• I tried hacking libtool to allow me to use regex to exclude anything with “Anonymous” in the name, to exclude anonymous namespaces, but it made no difference to code size, though the symbols no longer showed up in the nm output. Obviously there’s more to it than that.
• I tried various values with -falign-functions, but could not achieve anything other than making the code size larger.
• -fvisibility-inlines-hidden increases the size of libgtkmm by about 20%.

Summary

I believe that the remaining code size is just a fact of life of using C ++, and of having such a large (capable) API. In particular, we must list all those symbol names, and C++ symbol names are larger than C symbol names, due to the (wanted) namespaces and mangling. I can imagine that the linker/ELF could some kind of compression, but that would slow down load times.

But it is rather difficult to analyze code size: https://www.murrayc.com/blog/permalink/2006/02/15/c-code-size/ so I hope that some of you have some more ideas.

These options (and the patch) do at least mean that developers would not have to pay for things they don’t use. That is the C++ philosophy.

I don’t understand exactly what it’s meant to achieve, or how it’s controlled, but MacSlow’s videos of his LowFat file-management thing, using gtkmm and OpenGL are certainly smooth. He says he plans to use cairo(mm) for it in the future. Give it a minute or so to get to the good stuff.

Does anyone know how I can use Eclipse to edit an existing checkout, for instance to use it with my jhbuild checkouts? The best I can do so far is use Eclipse’s File/Import…/”Checkout Projects From CVS…” feature, but that puts a new copy of the code in ~/workspaces/. Eclipse’s File/Import…/”Filesystem” also seems to copy the code into ~/workspaces/ instead of just letting me edit the code.

Anjuta and KDevelop can do this, but I’d really like to use something more sane. I’m a bit afraid of Eclipse’s apparent complexity and odd new jargon, but I’d like to give it a chance, if I can get started.

I got back from Wiesbaden yesterday after helping to man the GNOME stand for the first day of LinuxTag. This year it’s in Wiesbaden instead of Karlsruhe. It seems to be significantly smaller, and felt deserted on that first day, but I’m sure it will pick up later, like it always did in Karlsruhe. There’s nothing as good as LinuxTag in Germany.

We only had a few of the items from the GNOME Events Box due to an(other) organizational snafu, and the Foot poster didn’t arrive yet, but we still made the most of our half a booth, using Thomas Keup’s projector to throw some eye-catching GNOME logos on the wall and enticing people with Novell’s XGL videos and GPE‘s selection of embedded devices. Our friends at Ubuntu have a large stand opposite us, so I suspect that this will become an epicentere of enthusiasm when the crowd gets here.

Joerg “Josh” Kress is again taking most of the weight for the booth’s organisation. I am often amazed by his patience and dependability. He’s great at calmly introducing people to a new world, showing them how to learn more, and how to get involved with the community that makes it happen. His new book, “Linux Lernen mit Ubuntu” does this in more detail. You should all go out and buy it, so he can take you on a tour of desktop Linux. If you take your copy to LinuxTag then he’ll even autograph it for you.

Here is a photo if someone would like to make him a hackergotchi head for Planet Ubuntu:

Spiel

We probably only spoke to about 15 people, compared to the usual hundreds, but it was nice to be more relaxed and to give people more time. Most people were completely new to Linux, which is similar to the last few events I’ve attended. The XGL videos are a nice opportunity to talk about how we like to take the time to make stuff really work, and to use technology where it’s useful and tasteful by default, resisting the temptation to throw in a lot of techie gimmicks that are fun at first, but would quickly become annoying. We need to get this idea of lifestyle design across in our marketing when this stuff goes mainstream. But I told them that they can try the work in progress in SUSE/Novell Linux and, with some tweaking, in the other distros in the meantime.

GNOME’s User Profiles Editor (Sabayon) is also a great demonstration for system administrators and existing users. It does so much, without forcing a whole new UI on people, because the developers were interested in the users’ goals rather than just mimicking existing tools.

I’m getting a little tired of my regular mini spiels, though they remain effective:

• Show how much better [Save] is than [Yes] in a “Do you want to save changes?” dialog, with a “Really Discard Changes?” dialog as the punchline. This emphasizes our attention to detail, and to the user experience, so they don’t need to pay attention.
• Showing our simple preferences and comparing them to the useless obscure options in Windows/Office applications.

Someone should write up something fun on the marketing pages.

In the last few days I’ve tried installing both Fedora Core 5 and Ubuntu Dapper Beta on my Acer Travelmate 4101WLMi (i915 graphics version). There’s a huge difference compared to earlier versions, such as Ubuntu Breezy. I didn’t need any extra boot options, and I get working networking and audio, though FC5 doesn’t ship the firmware, and it’s difficult to find the correct version of it and install it.

The Ubuntu Dapper Beta now uses the LiveCD installer. They seem to be moving to that, instead of the regular Debian installer. It’s a bit confusing still, and the partitioning bit is particularly flaky for me, but just having the ability for people to take screenshots of the installer (because you have the rest of the desktop to use too) must help them to improve it.

I notice that the Dapper Beta CD doesn’t use Network Manager anymore, so you now have to manually configure the wireless connection, but it did at least show my wireless network name without me having to type it in. I loved how network manager just did the right thing without me lifting a finger, but I guess it has some problems still.

I still don’t have widescreen resolution. Setting a mode to 1280×800 with 915resolution just gives me a scrolling desktop. Setting all the modes to 1280×800 gives me an Xorg crash with a “no screens found” message. This is becoming a bit annoying.