GNU bug report logs -
#69942
30.0.50; Fontification of radio-button widget labels
Previous Next
Reported by: Stephen Berman <stephen.berman <at> gmx.net>
Date: Fri, 22 Mar 2024 15:06:01 UTC
Severity: normal
Found in version 30.0.50
Done: Stephen Berman <stephen.berman <at> gmx.net>
Bug is archived. No further changes may be made.
Full log
View this message in rfc822 format
On Mon, 25 Mar 2024 01:40:36 +0100 Stephen Berman <stephen.berman <at> gmx.net> wrote:
> On Sun, 24 Mar 2024 19:47:16 +0100 Stephen Berman <stephen.berman <at> gmx.net> wrote:
>
>> On Sat, 23 Mar 2024 18:05:30 -0300 Mauro Aranda <maurooaranda <at> gmail.com> wrote:
>>
>>> Stephen Berman <stephen.berman <at> 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
This bug report was last modified 328 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.