The goal is to catch cases where the return value exists, but is
forgotten. There was a large enough number of them to turn this
into a real check. Initially, I just wanted to implement it to fix
the problems, then delete the code. But since this is so common, I
think it is worth the annoyance.
* Rendering problems
* Incomplete type information
* Obsolete type information
* Missing type information
* Missing return value
* Incomplete return value type
Some code in awesome concatenate color strings. This means it blows
up when the pattern are used instead of color, with this, it fails
gracefully (by returning the unmodified pattern).
Some widgets like the tasklist serialize the theme colors to use them
in Pango markup. If the theme color were already converted to pattern,
that blew up. With this fix, pattern can be converted back into strings
correctly.
Previously, it was monkey-patching the input layout object. This will
allow to replace the laoyut at runtime. For example, switching from
`fixed.horizontal` to a grid when the number of client gets too large.
It was previously monkey-patching the input layout object into
the final tasklist.
This is a breaking change, but affects undocumented behaviors. By
doing this, it becomes possible to expose the properties in the
public API. This, in turn, allows to document them. Right now,
the documentation is very vague on some behaviors.
As pointed out by @sclu1034, some users might actually pass the return
values of a function with multiple returns. This would cause some
confusing behavior. Documenting previous mistakes is in this case better
than hiding them.
* Check the correct variable
* Fix table access
In every other use of _private.keybindings in this file, the key is a
string, not an awful.key
* Simplify code
key.key is always defined
* Add tests
* add(spec) add_keybinding unit test
* Revert "Add tests"
This reverts commit 808b17cd5c.
Co-authored-by: Aire-One <aireone@aireone.xyz>
the actual key is BackSpace, not Backspace, so this translation was always unused
Co-authored-by: Lucas Schwiderski <4508454+sclu1034@users.noreply.github.com>
The constraint:set_width function listed ‘height’ as a required parameter; the constraint:set_height function listed ‘width’ as a required parameter. Swapped those around.
Also, fix the fitting logic so that the result width and height are fitted in the available space. Previously the result dimensions can be larger than the input, but cropped in e7a21947e6/lib/wibox/widget/base.lua (L547). But still it can cause problems e.g. when used inside wibox.container.place.
It looked horrible/buggy when combined. Now it looks like people would
expect it to work. Another problem was the `bar_border_width` look
when `ticks` was `true.
luajit was failing to GC the notification about 5% of the time. This
commit stores all widget notifications in a weak table and don't let
any lambda access the parent object notification object.
Each of those changes reduces the failure rate. There might still be
a couple in there, but the test passed 200x on my laptop with 100%
success rate.
The old behavior would move the client when `nil` was passed by
an almost arbitrary value. It would most of the time go off screen.
While this is a behavior change, what it replaces was so broken I
doubt anybody actually used `nil` in `relative_move`.
When the theme variables were moved to the backend instead of `rc.lua`,
some magic was added to disable them if the user set the border. However,
some undocumented `awful.placement` code also set them and turned off
the theme variables. So it worked *once* then stopped working.
If client client was tiled, the `fallback` could be
`theme.border_color_normal`, but if the client was
tiled, this fallback was never tried.
Now it tests for both "floating" and "active" fallbacks.
This problem actually affects the default theme.
Right now, all rules are additive, they are squashed into one big
array of properties. This is normally fine, but sometime you want
explicit rules for some objects, but also default rules if nothing
matches.
While this can be expressed in the current system by overriding
*all* properties, this require more effort than having "special"
and "fallback" rules.
It might be a good idea to deprecate them and move them to the tag
class. However, these APIs are not exactly well designed, so
moving them wont solve that. Some day the dynamic client layout will
hopefully be merged and send these functions to the heap of smelly
bad ideas trash.
The last time this page had a refresh was in parallel with another
massive whole-doc project. Thus, this page still had older
conventions which everything else had already removed.
Emmanuel Lepage Vallee
Grzegorz Bednarski
Kamack38
Matthias Paulmier
Actionless Loveless
A.I
Grumph
Lucas Schwiderski
sarubo
Aire-One
Pepijn Krijnsen
Pepijn Krijnsen
SystematicError
Xinhao Yuan
HumblePresent
Anton Bulakh
sarubo
Sergey