[…]

There is a trade off between minimizing manually added code and usability.

Usability by programmers should clearly be the driving force. For me gtkmm doesn't really work despite being very C++. Python use of GTK+ is great since it presents as naturally Python. GtkD is part way between, far better than gtkmm, but not quite as intuitive as the Python binding.

The single biggest problem for GtkD use is that the API documentation is D signatures with C comments. I have no solution to suggest, only that this is the single biggest problem I have. The GtkD demos are useful for what they do but I am finding I am going beyond what they show and am therefore a bit "on my own" using guesswork. Your replies on this forum (even though I hate forums) keeps me sane, on the right track, and inching towards a D port of GFontBrowser that is far nicer to work with that the gtkmm one, and works better than the Python port. I will be retiring the C++ and Python versions, now leaving the D ones as the mainline.

In this case first we the user no longer needs to know if the class they
want to use is stored as a object, a boxed type or a pointer.

And for boxed and pointer options the getBoxed and getPointer functions
return a pointer to the C struct and not the D class. Where you need to
instantiate the D class from the C pointer.

Now that I have working code, this all makes sense. Sadly it took me a while to get there, mostly because I misread your code fragment above – totally my fault. If I had read it correctly in the first place, success would have been swifter.

I would though still have to admit to a slight confusion between 'Boxed' and 'Pointer' in this context.

Luckily the getObject function already returns a ObjectG so the
boilerplate to handle the reference count correctly isn't needed.

GTK+ doesn't seem to handle 'Object', 'Boxed', and 'Pointer' in a way that is intuitive.