25. April 2009
So, from the little hacker in me I am a bit annoyed about forking strategies some projects have. I have been (co-)maintaing gdl for about 4 years know, brought it into GNOME, fixed lots of deprecated stuff and got rid of all the non-docking stuff in the library and lots of other people helped there.
Now what happend:
- inkscape* has a fork of gdl that is probably quite old. They made some additions that are probably useful
- Niepce forked the inkscape fork
- MonoDevelop made yet another fork of gdl, ported in to C# and dropped it again later
Nobody ever popup up in bugzilla, the mailing list or on IRC to ask if they could put some patch upstream that they needed. I am quite sure the upstream version fixes lots of problems still present in other versions and I am also sure the other versions contain some useful additions to gdl and that it would be no big deal to merge them. But as long as nobody from the projects steps up and says “Hey, here is our patch, can you have a look at it” it’s unlikely that upstream will ever be able to fill their needs. On the other hands they will never profit from upstream bug-fixes in any way.
* I think an inkscape dev once asked for a non-gnome version of gdl which was added later (and is now obsolete as there are only gtk+/glib dependencies left). But there was no further conversation.
So, please STOP this!
Act like Joel Holdsworth from the Lumiera Project. He poped up on the mailing list and said he would need gdl but would need some small additions. Afterwards he put in lots of patches, documentation updates and bug-fixes to make life easier for everybody.
That being said, both inkscape and Niepce are in C++ so it would make lots of sense for them to share a common gdlmm binding. Inkscape uses some non-standard binding method for gdl with lots of hand-written code.
Some people might say that gdl should be merge into gtk+. This may be done someday but gdl is not in a stage where it makes sense to consider it. It does a good job but it is far from perfect and it is even the question from a UI perspective if the averange application really needs to have such a heavy docking library in a general-purpose toolkit.