wibox.widget.checkbox -> unchecked checkbox returns nil not false
Output of awesome --version:
awesome v4.3 (Too long) • Compiled against Lua 5.1.5 (running with Lua 5.1) • D-Bus support: ✔ • execinfo support: ✔ • xcb-randr version: 1.6 • LGI version: 0.9.2
How to reproduce the issue:
set an instance of wibox.widget.checkbox to false, e.g.: mycheckbox =wibox.widget{ ..., checked=false, widget=wibox.widget.checkbox }
Actual result: mycheckbox:get_checked() should return false, but returns nil
Expected result: mycheckbox:get_checked() should return false.
Hello, this one is a funny bug. It still exists on the master branch.
Most of the properties accessors are dynamically generated, in the case of the checkbox widget, this is this code you want to read:
https://github.com/awesomeWM/awesome/blob/b54e50ad6cfdcd864a21970b31378f7c64adf3f4/lib/wibox/widget/checkbox.lua#L267-L278
The important part here is the getter code:
return self._private[prop] or beautiful["checkbox_"..prop]
If the current value of checked is false, this ternary-like statement will fallback to beautiful["checkbox_"..prop], aka beatiful.checkbox_checked. In other words, when checked is false, the value returned by the getter is a value from the user theme. No one would define a theme value for checkbox_checked, so the returned value is nil.
This behavior makes the "let's ignore this issue and just say nil == false" solution unacceptable.
To fix the bug, we need to either discriminate the boolean false value to a falsy self._private[prop] or have a short-circuit statement for the prop == "checked" case.
I'm not so happy with this fix, tho. Because it doesn't warrant that other places with a similar pattern will be fixed.
Will self._private[prop] return false in the case of the property "checked"? Are there really any other cases than a boolean property that one would have to consider? If so, maybe another category of properties is needed?
All these dynamically generated properties are theme related properties (or beautiful["checkbox_"..prop]). checked should have custom getter/setter and could also handle the indeterminate (nil) state that is often available on checbox controls in other frameworks.
Well, but it is not very intuitive to set a checkbox's value as a theme variable, as it demands user input. The other properties are about size and shape of the widget.