Gobject and c++ types.

[Milosz Derezynski <internalerror gmail com>]

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


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 murrayc com>

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 murrayc com
www.murrayc.com
www.openismus.com

_______________________________________________
gtkmm-list mailing list
gtkmm-list gnome org
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.]