I am personally against going back to Glade -- I don't care about a library dependency in this case, it's just that in my experience (I once made the mistake of using it heavily in a project at work) it makes maintainence a lot harder in the long run, and doesn't solve the problem of code clarity.

It might be instructive to look at which projects use Glade, or have used it in the past -- my informal observation is that many adopt it early on and then abandon it as the product matures and Glade starts causing problems for maintainence. (this is what happened with Sodipodi)

Rapid prototyping IS nice in experimenting with things, but big problems with Glade specifically seem to be:

* using custom widgets is awkward (even if just subclasses of standard widgets)

* generating large parts of dialogs/toolbars/whatever dynamically can be painful if you're doing more than just tacking things into a container widget (I expect to start doing this a fair amount in the future, particularly as we accomodate extensions)

* sometimes Glade more or less forces you into specifying layouts/dimensions in terms of pixels, which interacts badly with different widget font settings, etc...

Now, it may be that newer versions of Glade have solved these problems -- I've not used it much since the GTK 1.2 era, but really raw GTK/Gtkmm layout is pretty straightforward, provided:

1. You use packing layouts where reasonable (GtkBox and subclasses). We already pretty much do this.

2. The widget creation/layout code isn't a pages-long big man-eating blob of code that uses and reuses the same variables several times. Unfortunately, this is exactly what we currently have.

We could gain a LOT of clarity and maintainability by dividing the widget creation/layout into helper functions, each responsible for smaller sections of the overall dialog/window/widget.

-mental