Gtk+ 3.0 and gtkmm-3.0

["Germán Diago" <germandiago gmail com>]

I saw this article in the web:

http://federkiel.wordpress.com/2008/03/12/gtk-30-getting-serious/

When I saw it I wondered if it would be a good moment (when gtk+3.0)
to refactor a little the gtkmm API.
This is just a post which expresses an opinion. I would like to know yours.

First of all, gtkmm is great for working with gtk+ from c++, but from my 
point of view, it has some defficiencies.

Here is my wishlist and suggestions. Opinions are welcome.

The first one is just stetic, however, I think it could be managed with C++ easily.
There are some objects in gtk+ that ask for global resources, whose constructor
is protected, and a pointer to the object must be created in order to create the object.

1.- I think that creation of objects should be uniform and the Glib::RefPtr::create() idiom should
be hidden inside the implementation. All objects should be created in a uniform way (like in pygtk, for example)
2.- I think that we should use std::shared_ptr when available (not for now).
3.- It's VERY difficult to introspect signals, slots and in gtkmm, because they use libsigc++. And they can only
be bound at compile time. Don't get me wrong. libsigc++ is great, but it's very difficult to make
an editor in which you can bind signals and slots with drag and drop. I think signals should be rethought
so that they cover that so frequent use case. This would let people (like me) to write an IDE with these features.

I know that introspection for gobject is being implemented. Maybe with this one we can get signals and slots introspection.
But I also would like to be able that, when I implement a signal or slot in C++, this is automatically added (or the best
way that C++ can do this) to the gobject introspection. Because if we don't do this, we don't have
all the features expected from the toolkit when we choose to use C++.

Thanks for reading me.