bug#69942: 30.0.50; Fontification of radio-button widget labels

[Eli Zaretskii <eliz@gnu.org>]

> Date: Fri, 22 Mar 2024 16:04:15 +0100
> From:  Stephen Berman via "Bug reports for GNU Emacs,
>  the Swiss army knife of text editors" <bug-gnu-emacs@gnu.org>
> 
> In bug#69941 I reported a faulty fontification of radio-button widgets
> and noted in passing that the labels associated with the radio buttons
> also have unexpected faces, namely, the widget-inactive face regardless
> of whether the associated radio buttons are inactive or active (except
> for the label of a radio button that has been pressed, which has the
> default face).  While the faulty fontification discussed in bug#69941
> appears to be a real bug, the widget-inactive face assigned to
> radio-button labels is apparently by design -- it was present in the
> initial commit of the widget library.  But this seems to me to have been
> a UX mistake, since it effectively ignores the semantics implied by the
> name widget-inactive.  I think a less surprising UI would be for the
> labels to be fontified according to the widget's activation state:
> default face when the widget is active and widget-inactive face when
> it's inactive.  The attached patches provide two possible
> implementations of this UI.
> 
> The first patch makes the change unconditionally, treating the current
> fontification as a UI/UX bug.  But it may be argued that this aspect of
> the widget UI should not be unconditionally changed, since it was
> apparently a deliberate design choice and there have been (AFAIK) no
> complaints about the semantic discrepancy till now.  The lack of
> complaint could be because the widget-inactive face inherits the shadow
> face, so it is not sharply different from the default face.  But if one
> uses a very different face (as I did for illustrative purposes in
> bug#69941), the inconsistency is very obvious and (IMO) jarring.
> Nevertheless, to allow keeping the current fontification, the second
> patch conditionalizes the change from the current fontification by means
> of a user option (with the default being the current fontification).
> 
> Is either of these changes acceptable?

Adding Mauro to the discussion.