bug-gnu-emacs
[Top][All Lists]
Advanced

[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.






reply via email to

[Prev in Thread] Current Thread [Next in Thread]