There's a new tutorial for using a GTK Grid. You can find it
here: http://gtkdcoding.com/2019/03/29/0022-grids.html

Thanks!
The first link in the blog post to '..the last blog post' links
to the 0022 article itself, not to a previous one.
BTW, it compiles fine without 'import gtk.c.types', too.
Main.d (and maybe others) contains a 'public import gtk.c.types;'

Thanks for catching that. I've made the following changes:
- removed all import gtk.c.types statements,
- added a comment below the import statement block stating which
flags are brought in from c.types,
- rewrote all coverage of examples to reflect the above points.

Today's the day for (yet) another blog post over on
gtkDcoding.com and the subjects are:
- the RadioButton, and
- the ColorButton.
You can find it here:
http://gtkdcoding.com/2019/04/02/0023-radio-and-color-buttons.html

Today's the day for (yet) another blog post over on
gtkDcoding.com and the subjects are:
- the RadioButton, and
- the ColorButton.
You can find it here:
http://gtkdcoding.com/2019/04/02/0023-radio-and-color-buttons.html

Thank you!

But if we want one of the others to be active on start-up, as
well as syncing up the observed object, we have to call that
button’s setActive(true) function. To simplify this two-step
process, I broke it out into its own function,
setActiveButton().

The function ignores its argument and always uses member variable
button2 instead. Changing the parameter type to MyRadioButton and
using 'button' instead of 'button2' in the body works, so you
could pass another default in RadioBox.this().
Can somebody explain why getRgba() (apparently inherited from
ColorChooser) does take an out parameter instead of returning an
Gdk.RGBA?

The function ignores its argument and always uses member
variable button2 instead. Changing the parameter type to
MyRadioButton and using 'button' instead of 'button2' in the
body works, so you could pass another default in
RadioBox.this().

Thanks for catching my typos. I gotta stop messing with the code
once it's working. :) Fixes are uploaded.
Anyway, you can also declare it as a RadioButton and that works,
too... as long as the variables inside the function are changed
to 'button.'

Can somebody explain why getRgba() (apparently inherited from
ColorChooser) does take an out parameter instead of returning
an Gdk.RGBA?

My understanding is this:
Returning an object (as opposed to a single value) means
returning a pointer rather than the entire object. And the object
will cease to exist once the function returns because the scope
no longer exists. So, it follows that an out variable passed in
will preserve the object itself once program control returns to
the caller.

Can somebody explain why getRgba() (apparently inherited from
ColorChooser) does take an out parameter instead of returning an
Gdk.RGBA?

My understanding is this:
Returning an object (as opposed to a single value) means returning a
pointer rather than the entire object. And the object will cease to
exist once the function returns because the scope no longer exists. So,
it follows that an out variable passed in will preserve the object
itself once program control returns to the caller.

While that would be true for things that live on the stack, this is not
the case for RGBA. The C version of getRgba uses the "out" parameter so
you can pass in a existing GdkRgba, even tough that would make it more
like ref.
This doesn't make sense for the d binding since you will always get a
new RGBA passed through the out parameter.
--
Mike Wey

While that would be true for things that live on the stack,
this is not the case for RGBA. The C version of getRgba uses
the "out" parameter so you can pass in a existing GdkRgba, even
tough that would make it more like ref.
This doesn't make sense for the d binding since you will always
get a new RGBA passed through the out parameter.

Glad you're around to step in when I don't really understand
what's going on, Mike. Thanks for clearing this up. :)