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

[Stephen Berman]

On Mon, 25 Mar 2024 01:40:36 +0100 Stephen Berman <stephen.berman@gmx.net> 
wrote:

> On Sun, 24 Mar 2024 19:47:16 +0100 Stephen Berman <stephen.berman@gmx.net> 
> wrote:
>
>> 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.)
>
> Ok, I've gotten further with implementing disinguishing by faces
> selected (chosen) and unselected radio buttons in radio-button-choice
> widgets and check boxes in checklist widgets, see the attached patch.
> Initial tests seem ok, but it definitely needs more testing.

Any comments on this patch for using a widget-unselected face?  I have
been detained from further testing this past week, but can now resume.

Steve Berman