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

[Stephen Berman]

On Sat, 23 Mar 2024 18:05:30 -0300 Mauro Aranda <maurooaranda@gmail.com> wrote:

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

Yes, I agree that was likely the intention.  But I think it's
superfluous: after all, the distinction between selected (or chosen) and
unselected items is already clear from the appearance of the radio
buttons or, with checklist widgets, the check boxes (my patch neglected
checklists, but it's straightforward to account for them: in
widget-checklist-add-item the (widget-apply child :deactivate) sexp
should be wrapped in an (unless widget-radio-face-from-state ...)).

On the other hand, with an unselected face for the labels of the radio
button or check boxes, if it defaults to inheriting the shadow face for
unselected items, that corresponds to the current appearance with the
widget-inactive face, and by setting the widget-unselected face to the
default face, all labels would appear the same, which is what I want.
So for me that's an acceptable alternative to my proposed defcustom.  I
tried to implement it, but I'm not very conversant with the workings of
widget properties and how to apply faces depending on the widget's
state, and I haven't managed to come up with a working implementation
yet.  I'll keep trying, but you or someone else might be able to do it
sooner.

(There is another argument, besides superfluousness, against using a
separate face for unselected items: using multiple check boxes instead
of a checklist, as e.g. recentf-edit-list does.  With these the label of
each check box is supplied by the :tag property, so it is not touched by
the current handling in terms of the child widget's activation state.
I'm not sure if using an unselected face here would be unproblematic or
not.)

Steve Berman