Re: libgoocanvasmm

["Paul Davis" <pjdavis engineering uiowa edu>]

Answered my own generate_extra_defs question by guessing.

Hoorah.

Now, anyone know why:

_WRAP_METHOD(Glib::RefPtr<Model> get_model(),goo_canvas_item_get_model)

translates to:

Glib::RefPtr<Model> Item::get_model()
{
  return Glib::wrap_interface(Glib::RefPtr<Model>);
}

I think it should be:

Glib::RefPtr<Model> Item::get_model()
{
  return Glib::wrap_interface(Glib::RefPtr<Model> goo_canvas_item_get_model( gobj() ) );
}

Do I have to manually write these or something?

Paul

On 9/27/06, Paul Davis <pjdavis engineering uiowa edu > wrote:

So, to cross check that i have this in my head right,

GtkTreeModel has a method called get_column_type
GtkTreeModelIface has a method called get_column_type

I should _WRAP_METHOD GtkTreeModel's get_column_type
and _WRAP_VFUNC( GtkTreeModelIface's get_column_type )

And _WRAP_VFUNC adds _vfunc to the get_column_type from the Iface so the C++ names don't clash?

Wow, I really can't think in C anymore.  Objects have taken over my life.

The section in the docs about signal generation is umm, well incomprehensible.

    std::cout << get_defs(EXAMPLE_TYPE_SOMETHING)
              << get_defs(EXAMPLE_TYPE_THING);

Now, the thing compiles just fine cause I commented this out.

How do I know what EXAMPLE_TYPE_BLAH's to put in there?  Should I just grep goocanvas for GOO_CANVAS_TYPE* and list them all?  And does that then automagically generate all of my signal handler definitions and what not?

And properties too?

Cause that'd be sweet.

next question, do I have to hand code all of my _vfunc definitions?  There's a note in treemodel.ccg:

// Custom vfunc callbacks, because the C++ vfuncs have different parameters and return types
// that can not be generated automatically:

Cuase I'm getting vfuncs generated, they're just braindead, but so are some other functions too.

Anyway, its coming along.  Hopefully I can whip this out in a day or two

On 9/27/06, Murray Cumming < murrayc murrayc com> wrote:

> Hey,
>
> Murray made me do it.
>
> I've started work on libgoocanvasmm.

Great.

>  So I'll be asking lots of questions
> about these rather frustrating gmmproc macros.
>
> First question:
>
> What is going on with the _WRAP_VFUNC macros?
>
> I've got my vfuncs defined (I assume correctly) in
> libgoocanvas_vfuncs.defs
>
> I looked at treemodel.hg in gtkmm, its got a _WRAP_VFUNC and _WRAP_METHOD
> for some of its methods.  I'm confused.  But following suit.
>
> In one place this works out all right for me.  In another place, if I do
> the
> _WRAP_VFUNC and _WRAP_METHOD both, gmmproc tells me the original function
> isn't being wrapped.

No vfuncs are wrapped by _WRAP_METHOD(). You have just been unlucky and
seen vfuncs (function pointers in C structs) and functions (C functions)
that have the same name.

I mentioned that recently here:
http://mail.gnome.org/archives/gtkmm-list/2006-September/msg00141.html

So just wrap a vfunc with _WRAP_VFUNC() if you want to wrap it.

You can probably ignore the vfuncs anyway. It's unlikely that you'll want
to override them from C++, but they add per-object and code-size (linked
symbols) overhead. I suggest that you wrap them but comment them out in
the .hg file, so we can double-check later whether we need them.

> Oh, and I almost forgot, how, when, and why do I use the
> ./tools/extra_defs_gen/generate_defs_goocanvas.cc thing?
>
> Docs kinda skipped that too.

See "Generating the signals and properties .defs" here:
http://www.gtkmm.org/docs/gtkmm-2.4/docs/tutorial/html/aphs02.html


Murray Cumming
murrayc murrayc com
www.murrayc.com
www.openismus.com