Some conclusions, more on codegen and GObject

Some conclusions about the design-patterns-in-gobject-at-fosdem post

Some people responded very positive about doing the presentation, saying they are very interested. So chances are very high (it’s more or less certain) that I’ll do the presentation.

It looks like I’m not the only one who’s been trying to use design patterns in combination with GObject: one person told me he’s planning to document the places in the gtk+ library code where specific design patterns where used (ie. gtktreemodel, gdkdisplaymanager). Another person corrected some little glitch in one of the headers of my code and replaced the private data handling of the proxy sample with the standard GObject way of doing that. And another person tells me he’s interested in helping with the XSLT templates for generating GObject classes and interfaces using codegen.

That last one is the main reason for this conclusion-blog. Perhaps are others also interested in helping with that? So I’ll put some pointers:

Note that Codegen is LGPL and that I’m highly interested in any type of contribution or add-on. I already gave one person a commit-account on the subversion repository. Note that codegen itself is heavily based on the strategy design pattern. This makes extending it, yet not having to touch the core of it, trivial. At this moment I’m not focused on codegen. However, things like “which free software project I’m focusing a.t.m.”, change frequently. So it’s perfectly possible that suddenly a huge commit happens, that adds supports for some insanely cool feature :-p.