Skip to content

Add KRadioGroup to reduce boiler plate code around standard QRadioButton usage

First things first, when preparing this MR, I was working under the assumption that 90%+ of radio controls in our code base would have a QGroupBox with a vertical layout inside, containing a few QRadioButtons, and nothing else. Further, I assumed that a large share of these would assign ids to the buttons. A (non-systematic) look at the code-base appears to falsify both assumptions, however, and so I'm not so sure about this MR, after all. I'll propose it anyway, in case there is any interest in the bits. E.g. item 2) of this MR could certainly be factored out.

Of course, the MR also lacks autotests. I'd add those, if it looks useful, at all.

--

This MR addresses two issues:

  1. Creating a radio control in the above layout involves a lot of boilerplate code, as the steps of creating the button, adding it to a layout, and adding it to a radio-exclusive QButtonGroup with an id all need to be handled, separately. The proposed KRadioGroup makes allows to write this in much more concise form, which is also very readable as it looks pretty close to the resulting layout.

  2. One fairly commonplace "complication" is that one or several of the options may require further input, e.g. a number or filename. This input should be greyed out by default, and enabled, when the option is selected. While this path is easy enough to achieve, it is also desirable, but more cumbersome, to activate the corresponding option, when the widget is clicked. E.g. a minor but everyday nuisance is that I have to click in two separate places in order to start entering a page range in the print dialog.

(For both, see the usage example in the documentation block).

Merge request reports