Some feedback about using gtkmm in real projects.

[Germán Diago <germandiago gmail com>]

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.