Redo examples/explanations around RadioButtons and their Groups
I noticed some m_
prefixes on local variables, and from there it just spiralled...
commit 780c74e64ea55543458def03722d9cccb5da276d
Author: Daniel Boles <dboles.src@gmail.com>
Date: Fri Jun 28 18:17:44 2019 +0100
Drop pointless/confusing class around RadioButtons
The 2nd example seems to have been trying to be like the 1st, which put
the 3 RadioButtons in a subclass of Window, for no real reason since
they were never then added to said Window... but the 2nd omitted to
declare its members and instead declared new local variables in the
constructor with m_ prefixes, which were managed unlike the 1st example!
Just drop all of that. There's no clear reason to use a containing class
here. By not doing so, we can present both examples in a comparable way.
commit 3d1ea6bbce97d78d5673cc552516a5a4cff1f58d (HEAD -> wip/dboles/radiobutton-group, origin/wip/dboles/radiobutton-group)
Author: Daniel Boles <dboles.src@gmail.com>
Date: Fri Jun 28 18:39:29 2019 +0100
Redo odd wording @ RadioBut.set_group(get_group())
constness isn't the issue here; rather it is the value class of the
argument of set_group(). That method needs an lvalue reference as it
modifies the Group by adding the RadioButton to it. That's why we can't
`rb2.set_group( rb1.get_group() )`. But we can store the Group returned
by get_group() in a variable and then pass that to set_group() calls.
Not that there is much reason to, given join_group(), but it works fine.
Then I got carried away and added a program listing showing it
working... which, while mostly superfluous, does provide a nice
opportunity to explain briefly that RadioButtonGroup is a handle type,
meaning that it can be declared automatically and discarded by RAII
without worrying about thusly releasing the RadioButtons from itself.
That then informs readers for the next example that creates a new Group.
This is the first use of either "lvalue" or "rvalue" in the docbook!
That's either a good thing or a slippery, slippery slope to start on...