Gobject and c++ types.

[Germán Diago]

Hello. I'm trying to implement a system that works in a perfect way
with the GObject C library, so that things are easier to integrate
c++ classes in tools that use the metadata from GObject, like glade.

Maybe when I finish this, I could send it here to be able to integrate it
with glibmm and improve the object model.

My system must allow to register (yes, with macros, no other way) properties,
gobjects and signals, etc. So for now, what I can do is the following:

class MyClass : public glib::object {

};...


GLIB_REGISTER_CLASS(MyClass, glib::object);


int main(int argc, char * argv[])
{
    MyClass * c = (MyClass *)g_type_new(g_type_from_name("MyClass", NULL));
    c->method();
}


My problem is that now I want to install properties and use them. In
order for properties
to work well in C programs (like glade), they should be able to be set
from GObject:

g_object_set(G_OBJECT(c), "Prop", value);

My problem is that G_OBJECT macro fails with the following:

GLib-GObject-CRITICAL **: g_object_set: assertion `G_IS_OBJECT (object)' failed

But if I query this:

g_type_is_a(g_type_from_name("MyClass"), G_TYPE_OBJECT)

it returns 1. So I want to know why this fails in order to solve the
problem. I'm stuck here for now.

I use InstanceInit from GTypeInfo to call the c++ constructor, and
class_init from GTypeInfo to install properties.
But the casting fails and I don't know why. Thanks in advance.
_______________________________________________
gtkmm-list mailing list
gtkmm-list@...
http://mail.gnome.org/mailman/listinfo/gtkmm-list

[Murray Cumming]

On Thu, 2009-11-05 at 14:02 +0100, Germán Diago wrote:

> Hello. I'm trying to implement a system that works in a perfect way
> with the GObject C library, so that things are easier to integrate
> c++ classes in tools that use the metadata from GObject, like glade.
>
> Maybe when I finish this, I could send it here to be able to integrate it
> with glibmm and improve the object model.
>
> My system must allow to register (yes, with macros, no other way) properties,
> gobjects and signals, etc. So for now, what I can do is the following:
>
> class MyClass : public glib::object {
>
> };...
>
>
> GLIB_REGISTER_CLASS(MyClass, glib::object);

class MyClass : Glib::Object
{
};

MyClass::MyClass
: Glib::ObjectBase("myclassname")
{
}

will also register a derived GType.


--
murrayc@...
www.murrayc.com
www.openismus.com

_______________________________________________
gtkmm-list mailing list
gtkmm-list@...
http://mail.gnome.org/mailman/listinfo/gtkmm-list

[Murray Cumming]

On Thu, 2009-11-05 at 15:31 +0100, Germán Diago wrote:

> >> GLIB_REGISTER_CLASS(MyClass, glib::object);
> >
> > class MyClass : Glib::Object
> > {
> > };
> >
> > MyClass::MyClass
> > : Glib::ObjectBase("myclassname")
> > {
> > }
> >
> > will also register a derived GType.
>
> But can you register signals?

No.

>  And properties?

Yes, just by adding a member propertyproxy, I think.

> I think properties can
> be registered but not signals.
> What I want to try is a way to expose c++ signals into GObject type
> system, so that they can be
> seen in glade.

OK. Good luck. That's difficult.

> Anyway, the problem is that until you don't create an instance of
> MyClass, you don't have
> the GType available. Correct me if I'm wrong.


--
murrayc@...
www.murrayc.com
www.openismus.com

_______________________________________________
gtkmm-list mailing list
gtkmm-list@...
http://mail.gnome.org/mailman/listinfo/gtkmm-list

[milosz derezynski]

---------- Forwarded message ----------
From: Milosz Derezynski <internalerror@...>
Date: 2009/11/6
Subject: Re: Gobject and c++ types.
To: Murray Cumming <murrayc@...>


Just reading this and thinking about it, it occured to me that there is a rather uncumbersome way, similar to propertyproxy, by which we can have automatically C and C++ signals

First, we'd need a Glib:Signal (aka Glib::Object::Property), templated, so you e.g. do:

typedef Glib::Signal<void, std::string, int> MySignal1 ; 

then...

class MyNeatClass

{

/* ...yaddayadda ... */

    MySignal1 m_mysignal_1 ;

} ;

ow there are the next 2 important steps.

First, in order to access the actual signal we can do e.g. this:

class MyNeatClass

{

    MySignal1::Signal&

    signal_get_some_data()

    {

       return m_mysignal_1.signal() ;

    }    

}

Since Glib::Signal<> looks inside prolly like this:

template <typename RV, typename T2, typename T3>

class Glib::Signal

{

public:

   typedef sigc::signal<RV, T2, T3> RealSignal ;

private:

   RealSignal m_real_signal ;

public:

    RealSignal&

    signal() ;

};

sssssssssssoooooooo..... so far it should be clear. So far it's just a small wrapper around sigc signals.

Now comes the interesting part though: Let's look at the constructor.

class Glib::Signal

{

   Glib::Signal(

      const std::string&        name

    , Glib::Signal::RunType  type                                   (i.e. Glib::Signal::RUN_FIRST or Glib::Signal::RUN_LAST)

    ) ;

}

so now in our instance of MyNeatClass, we have:

MyNeatClass::MyNeatClass

: Glib::ObjectBase("MyObject")

: m_mysignal_1("get-some-data", Glib::Signal::RUN_FIRST)

{

}

So far, so good. With only a little overhead in complexity of the code we were able to install a C and C++-signal at the same time. Now Glib::Signal just needs some logic to, when ::emit() is being used, the emission goes out through both subsystems, or if someone uses g_signal_emit on that signal (doable with GObject voodoo).

But, issues remain.

For one, the C signal registration requires a return GType and a VA list of return types. Now this is not a big problem since already when using our Glib::Signal template we'll know how many types i.e. signal arguments we'll be dealing with. So, one could just specify these here as well:

m_mysignal_1("get-some-data", Glib::Signal::RUN_FIRST, G_TYPE_STRING, G_TYPE_INT)

(The constructor obviously needs 2 more args but since it's the RV+2args template that is of course logical).

Ok but what does that give us? Really not much at least as far as typesafety goes. YOU just have to make sure that the G types you specify correspond to the C++ signal's types. This is nut-to-crack #1.

Nut-to-crack #2 is a bigger problem. The GSignal signal requires a marshaller, and depending on what you want to pipe through that signal, you have to generate one first with glib-genmarshal. Now this is a REAL problem.

Now , I'm not even sure that this should be followed up upon, but I just wanted to show that it is in fact not that impossible, and if you can live with a few irks even quite doable.

2009/11/5 Murray Cumming <murrayc@...>

On Thu, 2009-11-05 at 15:31 +0100, Germán Diago wrote:
> >> GLIB_REGISTER_CLASS(MyClass, glib::object);
> >
> > class MyClass : Glib::Object
> > {
> > };
> >
> > MyClass::MyClass
> > : Glib::ObjectBase("myclassname")
> > {
> > }
> >
> > will also register a derived GType.
>

> But can you register signals?

No.

>  And properties?

Yes, just by adding a member propertyproxy, I think.

> I think properties can
> be registered but not signals.
> What I want to try is a way to expose c++ signals into GObject type
> system, so that they can be
> seen in glade.

OK. Good luck. That's difficult.

> Anyway, the problem is that until you don't create an instance of
> MyClass, you don't have
> the GType available. Correct me if I'm wrong.

--
murrayc@...
www.murrayc.com
www.openismus.com

_______________________________________________
gtkmm-list mailing list
gtkmm-list@...
http://mail.gnome.org/mailman/listinfo/gtkmm-list

--
Please note that according to the German law on data retention,
information on every electronic information exchange with me is
retained for a period of six months.
[Bitte beachten Sie, dass dem Gesetz zur Vorratsdatenspeicherung zufolge
jeder elektronische Kontakt mit mir sechs Monate lang gespeichert wird.]

--
Please note that according to the German law on data retention,
information on every electronic information exchange with me is
retained for a period of six months.
[Bitte beachten Sie, dass dem Gesetz zur Vorratsdatenspeicherung zufolge
jeder elektronische Kontakt mit mir sechs Monate lang gespeichert wird.]

_______________________________________________
gtkmm-list mailing list
gtkmm-list@...
http://mail.gnome.org/mailman/listinfo/gtkmm-list

[Germán Diago]

> Just reading this and thinking about it, it occured to me that there is a
> rather uncumbersome way, similar to propertyproxy, by which we can have
> automatically C and C++ signals


Maybe I can try some of the above. I have a doubt about wrapping
Gobjects from c++ (for now I'm trying my own implementation of
Glib::Object too)

I have

class glib::object {
  GObject parent_class;
public:
   ....

};


class MyClass : public glib::object {

....
};


My problem is that if I make my destructors virtual (which I do want
to do), then:

GObject * obj = G_OBJECT(g_type_new(g_type_from_name("MyClass"), NULL));

G_OBJECT casting won't work. I think it's because with a vtable, the
layout for the type changes, but I don't know how to workaround this
and
keep G_OBJECT macro working, which is very important for C
compatibility and exposure.
_______________________________________________
gtkmm-list mailing list
gtkmm-list@...
http://mail.gnome.org/mailman/listinfo/gtkmm-list