Awesome: Error on gears, everytime i open something

Created on 23 Oct 2019  Â·  2Comments  Â·  Source: awesomeWM/awesome

Output of awesome --version:

awesome v4.3-505-g0297bfff-dirty (Too long)
• Compiled against Lua 5.3.5 (running with Lua 5.3)
• D-Bus support: yes
• xcb-errors support: no
• execinfo support: yes
• xcb-randr version: 1.6
• LGI version: 0.9.2

How to reproduce the issue:

Error happens when opening something with a titlebar

Actual result:

2019 10 23-00 29 16 screenshot

Everytime i open something, it returns this error. I tried everything from now, installing many versions of Lua, Lua-lgi, building Awesome from git, installim from Awesome-git aur, and everytime this error appears. Help anyone?

Most helpful comment

Finally had time to figure this one out. This turns out to be a behavior change in type detection. The previous code was silently discarding an invalid method input while the new code was "letting it fail because it should not happen". I will amend #2894 to ensure the old behavior is restored.

The is from the most popular (and amazing) AwesomeWM config ever on Reddit:

-- Padding
-- Only visible when equal padding is desired for the client
{
    visible = user.anti_aliasing and equal_padding or only_borders,
    buttons = user.anti_aliasing and only_borders and buttons,
    bg = anti_aliasing_padding_color,
    forced_height = anti_aliasing_padding,
    widget = wibox.container.background
},

If I do:

print("\n\n\n\nHAS BUTTONS", user.anti_aliasing, only_borders, buttons, user.anti_aliasing and only_borders and buttons)

Then the result is false instead of nil. Because true and false and {} evaluates to a boolean, not "table or nil" like you might expect when using the or operator to do thing_a or thing_b or thing_c.

So the old code was silently rejecting the boolean buttons while the new code acts like most of Awesome and assume the type is right or let it print the error popup (and/or exception handler).

All 2 comments

Might be a regression due to recent changes

Finally had time to figure this one out. This turns out to be a behavior change in type detection. The previous code was silently discarding an invalid method input while the new code was "letting it fail because it should not happen". I will amend #2894 to ensure the old behavior is restored.

The is from the most popular (and amazing) AwesomeWM config ever on Reddit:

-- Padding
-- Only visible when equal padding is desired for the client
{
    visible = user.anti_aliasing and equal_padding or only_borders,
    buttons = user.anti_aliasing and only_borders and buttons,
    bg = anti_aliasing_padding_color,
    forced_height = anti_aliasing_padding,
    widget = wibox.container.background
},

If I do:

print("\n\n\n\nHAS BUTTONS", user.anti_aliasing, only_borders, buttons, user.anti_aliasing and only_borders and buttons)

Then the result is false instead of nil. Because true and false and {} evaluates to a boolean, not "table or nil" like you might expect when using the or operator to do thing_a or thing_b or thing_c.

So the old code was silently rejecting the boolean buttons while the new code acts like most of Awesome and assume the type is right or let it print the error popup (and/or exception handler).

Was this page helpful?
0 / 5 - 0 ratings

Related issues

deb75 picture deb75  Â·  4Comments

doronbehar picture doronbehar  Â·  5Comments

batmanm0b1E picture batmanm0b1E  Â·  6Comments

xordspar0 picture xordspar0  Â·  5Comments

blkdr picture blkdr  Â·  5Comments