You're so obsolete!

The other day, I was debugging Colorado, a toy project of mine written in C# with Gtk#. Oh, boy, Gtk, the underlying graphic toolkit framework. Most of the times I'm more writing code that I struggle to make it compile than anything else.

For instance, I still don't know what an AccelGroup is intended for (apart from the obvious meaning), or what it is used for in order to program keyboard accelerators (like Ctrl+O). Anyway, you have to create one because you need an AccelGroup for your accelerators, no matter what (yeah, I know what the documentation says, but AFAIK, you cannot get the AccelGroup for your app).

It's like Gtk has a lot of power, but instead of creating a two-level API (one for the most common case, and another for low-level access), it only has those low-level calls.

To make a long story short, I got about 246 warnings compiling my application. The Gtk.Action class was now obsolete. Instead, you should use GAction in the new Gio lib. No, well, GAction is in the GLib in Gtk#. Does it work? Not sure.

I've written before about the frustration for developers (well, like me), to declare code obsolete like there is no tomorrow.

A programming language, a framework, a simple lib, all of them are pieces of software that must be careful designed for their future. However, it's like some times it seems its future is designed on the spot for the comfort, creativity, or just whims of its programmers.

Once any piece of software is created, well, it is not written on stone, but it gains followers (developers), that you should care about. Changing the API to satisfy your desires goes in the opposite direction.

Do you think you should change the API? Okay, create a spreadsheet to calculate the upgrade in points, put the advantages in different rows, the disadvantages as well, and start with -100 points.

And please, if you decide you really, really, must do it, not only mark the class as obsolete. Create a clear, documented, migration path (if possible, not in a blog post, Goo cough gle).

Another possibility is that you detect the need of change, and instead of a new API, you change the existing one, like the guys at Java did with java.nio, reimplementing java.io with the former. Nobody bothered, all apps benefitted.