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.
_______________________________________________ gtkmm-list mailing list [email protected] http://mail.gnome.org/mailman/listinfo/gtkmm-list
