Opportunity to improve gtkmm bindings.

[Germán Diago <germandiago gmail com>]

Hello. I'm a little frustrated about the degree of compatibility
between glade and gtkmm. It's too difficult to use custom widgets,
for example. Don't get me wrong, bindings are ok, but they could be improved
a lot.

After looking at the code, I saw some of the things I think should be fixed.

Since gnome-3.0 is coming in september 2010, I think it's a great
opportunity to
fix some of the problems (no requirements for abi compatibility)

For me, the main problem is that gtkmm bindings don't interact well
with C gobject
bindings.

What I think should be fixed is:

- Registration of GObjects should happend BEFORE main is entered
(calling g_type_init() should
be done before entering main, then).
- Same for registration of signals and properties.
This fixes some problems (in my opinion) with initialization order.

Signals should be registered in gobject too.

Ideally, slots should be connectable at runtime, although I know this
one is quite difficult.

My proposal (it's what I'm trying to do now just with properties for
the moment) is the following.

Use macros (yes, there's no other realistic way) to register metadata.
These macros create the equivalent of a
GObjectClass for every class registered. Macros can be put outside of
the class (simplified code) :

class MyClass : Glib::Object {
  Property<int> myprop;
};

//Macro with Class name and parent class.
GLIB_BEGIN_REGISTER_CLASS(MyClass, Glib::Object)
    GLIB_BEGIN_PROPERTIES()
           GLIB_REGISTER_PROPERTY(myprop, int) //You will be able to
register nick, blurb and some more things when available
   GLIB_END_PROPERTIES()
   //Same for signals
GLIB_END_REGISTER_CLASS()


I know some people (including me) don't like macros. But it's the only
realistic way to register type information
in C++. And this is done to be able to make use of all the features
available in the C bindings.


Glib::Object is simply a c++ object which doesn't wrap a C Gobject. It
contains a map of properties, which
can be set and get through C gobject code or, of course, from c++.
When exposed to C, you have a structure like this:

struct ObjectWrapper {
    GObject object;
    Glib::Object * obj;
};

This way (I tried it) the class can be created and managed from C with
the appropiate g_object_set and g_object_get implementations,
making new widgets with some macros suitable to edit in glade and with
gobject C apis in general.

For class registering there is a singleton who class g_type_init() and
registers every class. You can control not to call g_type_init() twice
if
some other library is loaded with registered classes.

Another thing I don't like is Gtk::TreeModelColumnRecord. It works
great in c++ and from the point of view of type safety, but it doesn't
integrate well with C gobject. This means that when I make a treeview
with columns, etc in glade, it's useless for c++ bindings.
I haven't thought about how to solve this yet. But I think that this
is important to get it right so that glade can be used to its full
utility.

For the first try I'll try to integrate a c++ widget in glade, and
when it works, I'll post the code (first version will just register
properties).

What do you think of the ideas? Comments are welcome.