Hello. I would like to report some feedback on using gtkmm during some time (maybe 4 or 5 months). These are just some suggestions I think would improve the API.
The API is ok, but I think, that when Gtk+3.0 comes, it should be reshaped a little. My proposals would be the following: 1.- One of the things I think gets a lot in the way of the programmer in gtkmm is the difference between objects that use Glib::RefPtr and objects that don't. I think this is an implementation detail and it should not make any difference to use one type of object or another. I think it should just be wrapped properly to hide the difference. 2.- Maybe it would be good, instead of using Gtk::manage, to be able to use in the wrappers a system like the one Qt uses to free memory. That is, provide a parent which will manage the memory of its children. That would be done providing as first argument of the constructor the parent of the widget. It would be easy. In every object, provide a container to push pointers to objects that must be deleted (in GObject base class). So the idiom would become, for example: Gtk::VBox box; Gtk::Button * button = new Gtk::Button(&box, "hello"); //automatic deletion when it goes out of scope. Much cleaner than now (in my opinion). 3.- This one is a very difficult one. But I would like to be able to expose my widgets as gobjects, for integration in glade, entirely from an intuitive c++ api. I know c++ does not have reflection, but maybe there is a way to do it. I say this because it's very frustrating to make components that can be seen, from example, from glade. It should be as easy and convenient as possible, since this is a requirement that users usually need (like me). So the feature in general is a better and more intuitive API for gobject from c++. 4.- C++0x: Move semantics for all widgets. 5.- Another difficult one: it would be VERY convenient to have some way to make signal autoconnection. I mean, signals at runtime. I know, they're not typesafe, but the only true for me is that it's very convenient to have this feature, since from editors you can do things like QtDesigner signal and slot mechanism can do. This enables very effective RAD programming. Maybe we could thing a way to extend the current signal system to add runtime signals when needed. This is the most frustrating part of gtkmm for me, since when I use python, C# or whatever for gtk+, I can autoconnect signals, which is very convenient for working with widgets. 6.- Minor one: Gtk::Main should not be an object, like in all the other wrappers. It should be Gtk::Main::init and Gtk::Main::run, with static functions. I think it does not make sense in other way. I haven't read too much about gobject introspection, but it could help in the signals and gobject parts, maybe? I'll be able to help some day if it's necessary, but now I'm quite busy. Thanks for your time. _______________________________________________ gtkmm-list mailing list gtkmm-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtkmm-list
