Re: Glib::SignalProxyProperty Problem
- From: Murray Cumming <murrayc murrayc com>
- To: Gunther Laure <gunnar2 sbox tu-graz ac at>
- Cc: gtkmm-list <gtkmm-list gnome org>
- Subject: Re: Glib::SignalProxyProperty Problem
- Date: Tue, 15 Feb 2005 15:22:14 +0100
On Tue, 2005-02-15 at 15:15 +0100, Gunther Laure wrote:
> On Tue, 2005-02-15 at 14:55 +0100, Murray Cumming wrote:
> > And you are not intended to use this directly. It is returned by
> > property_*() accessor methods.
>
> Thank you, I completely missunderstood the semantic of this class
>
> > I don't think there is anything in glibmm to connect a signal by name at
> > runtime. How could the compiler or runtime know that your method
> > signature matches? You can use the glib API.
> >
> > Is this for some generic thing, or have we forgotten to wrap some
> > signal?
> >
>
> A generic thing :). We have a Component based C++ API that allowes to
> request slots/hooks at runtime. Using this API I am able to directly
> process a glade file and use the information of the <signal> tag to
> automatically connect the widgets and the component instances.
>
> Using the C variant of GObject, I am able to query for signals, using
> g_signal_lookup and g_signal_query. Sadly I have no idea, how to set a
> functor/slot as callbacks for C based GObjects :(
You need to use the user_data to maintain state. There are various hand-
coded SignalProxy_* classes in gtkmm that show this.
--
Murray Cumming
murrayc murrayc com
www.murrayc.com
www.openismus.com
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]