To recreate the problem, the code:

MenuItem::create("foo", "app.foo);

is all that is required.

Created attachment 250532 [details] [review]
Delegate to wrapped methods instead of constructor methods

Yes, I noticed today that these GMenuItem _new() functions are awkward. I filed bug #705201 just in case it can be improved in glib.

For now, I would prefer to reimplement these _new() functions in our constructors rather than call them, because they are fairly simple _new() functions. That lets us continue to instantiate our derived GType.

Would you like to try that?

That's actually the first thing I wanted to do, but I have absolutely no familiarity with the wrapping macros at all.

Is there somewhere I can read up on how to override the constructor bodies?

I would say, however, that the wrapping the methods does have an advantage. It protects glibmm against any future changes in the g_menu_item_new method.

(In reply to comment #4)
> That's actually the first thing I wanted to do, but I have absolutely no
> familiarity with the wrapping macros at all.
> 
> Is there somewhere I can read up on how to override the constructor bodies?

I'll take care of it. That's probably the best way to show you.

> I would say, however, that the wrapping the methods does have an advantage. It
> protects glibmm against any future changes in the g_menu_item_new method.

Yeah, it's a calculated risk.

Thanks.

(In reply to comment #5)
> I'll take care of it. That's probably the best way to show you.

Okay, cool, thanks! :)

Here it is:
https://git.gnome.org/browse/glibmm/commit/?id=23823fdf3a54ed3851b8564fa8df993ce6e5e33f

Those _CONSTRUCT() macros would contain property values if there were any properties in GMenuItem. It's documented in the gtkmm-documentation book.

Please confirm that it fixes the problem for you.

Note that these are fairly new classes that obviously haven't been used much yet, so you are likely to find other problems.

Thanks for this! :)

That commit fixes the problem for me.