[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#69942: 30.0.50; Fontification of radio-button widget labels
From: |
Mauro Aranda |
Subject: |
bug#69942: 30.0.50; Fontification of radio-button widget labels |
Date: |
Sat, 23 Mar 2024 18:05:30 -0300 |
User-agent: |
Mozilla Thunderbird |
Stephen Berman <stephen.berman@gmx.net> writes:
> 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?
Thanks for working on this. What about adding a widget-unselected face?
I think that might be the intention with using the widget-inactive face
for unselected radio items.