Here goes my 100% support! :D thank you

No strong opinion.
I used to see the checkmarks where it's obvious (like Display mode). On the other hand, I like standardization.

Anyway, if the idea is accepted, more places to change: Gesture manager action list - Default, Pass through, Nothing (upper 3 items).

I'd put the radio = true, line right near the checked line, the callback can be long and the radio line goes too far.

Font list is a discussable question.

Mind, aside from what's mentioned in #8167 about exclusivity not being a user concern but a code concern, it's also uglier on eink with regard to refreshes and ghosting. The problem can be mostly avoided by using something less filled like ⦿ but that feels like it's not really indicating filled out or selected, but the fully filled one also feels a bit heavy.

what is the problem with changing the font ones as well?

Just what @Frenzie mentionned: our square checked checkboxes looks a lot nicer than the big solid black rounded radio boxes.

so the only concern is that the black-filled circle is a little harder to clear than the much thiner ticks? am I reading that right?

couldn't the filling be a little less black then, a few shades less? don't we have like 50 shades of grey...

Gray is even worse. 😄 (Somewhere between more flashing and not showing, depending on the device and what you can live with.)

I vote for complete uniformity of the UX, with radio buttons in the font list as well.

I don't see that list too many times anyway, because I use profiles.

I think what @hius07 means is that it's not really a radiobutton if you can't see the activated option.

There's also the bullseye btw: ◎

Well, the list is still a list, the fact that it is divided into 63782 pages is unrelated to how a single selection is represented :D

On the contrary, when I see a checkmark next to any item in any list, I briefly involuntarily think "what other items are selected?" and I start scrolling through the whole list (like in Dispatcher items). If I saw a radio button, then that's it! The only selected option.

You scroll through pages with a few fonts on each, yes, but still stay in the same "list context" and ultimately you can only choose one font in that font list. Other options like monospace font override are hidden in their own menus, so font list is ready for radio buttons.

Here is a real life hardware example of a radio button in action.

In our lab we have those vacuum gate vales. They operate under 100 psi pressure of compressed air.

They are normally closed (when not pressurized). White mark shows up in the "Closed" window - as in the photo.

When we command it to open, white mark moves to the "Open" window.

When we have a failure, it is neither - this is because the pressure is somewhere between 0 and 99 psi - and this is by design! Then white mark gets stuck between those "Open" and "Closed" windows, and this is a red alert to us as operators (because looking at this status radio buttons is in the routine operation checklist) - we immediately go and check what's wrong.

I think what @hius07 means is that it's not really a radiobutton if you can't see the activated option.

There's also the bullseye btw: ◎

That ostensibly sounds like a rather weak argument; the boxes and tick do the very same thing... ninety-nine unticked boxes and one Lonesome Dove-tick

That ostensibly sounds like a rather weak argument; the boxes and tick do the very same thing... ninety-nine unticked boxes and one Lonesome Dove-tick

It's only a guess. I could be wrong about it. I'm not in favor of treating the font list as an exception in any case.

By now, I think I totally support this PR, everywhere.

(Not a style guide, but Kindle native interface uses our radiobutton, exactly)

video killed the radio star?

@poire-z review time

I don't like it for the font list...
But KOReader being all about anal-retentiveness (aka consistency), have it you all your way :)

@Commodore64user

Found other checkboxes worth being replaced by radio buttons.
Group None/Auto, and a group with those four options below (as well as the list inside Obsolete). Besides, I think the horizontal bar above Obsolete is not needed because selection of None/Auto determines if either of the four items will be selected.

Also, Top menu - Gear - Screen - E-ink settings - Full refresh rate:

Besides, I think the horizontal bar above Obsolete is not needed because selection of None/Auto determines if either of the four items will be selected.

It's needed to say that it's separate and not a logical part of it. It's never been about grouping or separating radio buttons specifically.

Then I am confused. Because the horizontal line usually meant (I thought) either mutually exclusive groups or unrelated (at least not really) groups (like fonts themselves vs fallback fonts.

Those four styles will act as a single group of radio buttons - as soon as any one of those four is selected, the rest are unselected. I understand that the Obsolete styles are not suggested to be used frequently because they are legacy, but the horizontal line contradicts its UX nature in other menus here.

Maybe Obsolete can be taken into parentheses instead?

The refresh one would need a slight adjustment to make sense, i don’t believe there are any radio buttons that are long press-able for more settings (i.e., custom ones)

That style one, is a bit of a mess as well...

fonts themselves vs fallback fonts.

But it's exactly like that. Not obsolete vs obsolete.

Maybe Obsolete can be taken into parentheses instead?

Random parentheses would be out of place and draw attention to themselves.

Like random horizontal line as well :D

Came here to thank for this @Commodore64user
Finally proper radio buttons. They look chonky on screenshots but perfect weight on e-ink.