Re: Using (or not using) sigc::mem_fun with the G_CALLBACK macro

[Paul Davis <paul linuxaudiosystems com>]

On Thu, 2005-06-16 at 06:08 -0500, Bob Caryl wrote:
> Murray Cumming wrote:
> 
> >And if you must provided a C function pointer, you'll need to provide a
> >pointer to a static method (or global function) and the state
> >information as user_data. See the various SignalProxy classes, for
> >instance, in TreeSelection.
> >
> >  
> >
> In other words, the way I've done it (separate executable invoked via 
> fork, execv) is the only thread safe way to do this until GtkHTML has a 
> C++ wrapper.

what are you thinking? this has nothing to do with threads. it doesn't
even have a *lot* to do with language, except for the fact that you
can't use a non-static C++ member function as a C callback. if you
really want to use C++ objects with GTK widgets, then do this:

	class Foo {
            public:
	       static gint my_c_proxy_for_bar (arglist...);
	       gint my_handler_for_bar (otherarglist...);
        };

	gint
        Foo::my_c_proxy_for_bar (..., gptr user_data, ...) 
        {
	    return reinterpret_cast<Foo*>(user_data)->my_handler_for_bar
(relevant_args...);
	}
	
	gint
	Foo::my_handler_for_bar (otherarglist...)
	{
	}

and then somewhere, connect

	gtk_signal_connect (widget, "signal", ...., SomePtrToFoo);

I have done this a lot with the GtkCanvas widget which has never been
wrapped for C++ (and never will be; we're migrating to GNOME::Canvas
ASAP)

--p