For some even more strange reasons than commit 047729ae1, it seems
we can also have the error that `item.inherited` can be sets to `true`
on items that are not inherited...
I just had this issue with `wibox.widget.imagebox` where properties
were marked as inherited from `wibox.widget.imagebox`. Best way to fix
it is to only trust the check on `item.baseclass`, and completly
dismiss its `inherited` property.
Add a new ldoc tag `@hidden`. This tag allows us to keep documentation
for magic methods (e.g. `wibox.widget.base:get_visible`) but prevent
it from being part of the documentation used by final users.
For some reasons, sometime `item.inherited` is `false` even if the
item was added to the `all_module_kinds` table by the "hierarchy
lookup" for-loop, and we already force the `inherited` property to be
sets to `true` at this moment.
With this commit, we add a second fail-check condition based on the
`item.baseclass` property to determine if the item is inherited or not
when we do the render.
This commit adds a new ldoc custom tag `@supermodule`. It has to be
used at the module level. It should refer to the module
supermodules.
This tag can be used multiple time by the same module, but we ignore
other calls (for now?) as (AFAIK) we only use one way inheritance.
This tag is used in the ldoc template to find modules hierarchy and
draw the inheritance tree. It makes it easy to find and navigate to
parents modules.
For each widget, the layout function checks whether placing it would
make the function exceed the allowed geometry.
If not, the function places both the widget and a spacing widget.
This check ignores the size of the spacing widget itself, this can cause
overloading of widgets on top of each other.
For example, the following scenario with these widgets:
widgets: widget1 { width = 10, height = 10 }
widget2 { width = 10, height = 10 }
widget3 { width = 10, height = 10 }
and a call to horizontal layout with the
{ width = 10, height = 10, spacing = -5 } parameters.
The function would layout the widgets the following way:
{
widget1: { x = 0, y = 0, width = 10, height = 10 }
spacing: { x = 5, y = 0, width = 5, height = 10 }
widget2: { x = 5, y = 0, width = 5, height = 10 }
spacing: { x = 5, y = 0, width = 5, height = 10 }
widget3: { x = 5, y = 0, width = 5, height = 10 }
}
This behaviour would be the same for any number of widgets for negative
layout.
This patch changes the layout function to check whether the current
widget uses up the whole space.
It also removes 'pos' variable. Its purpose isn't intuitive in the
presence of x and y. This helps to understand where each widget is
placed now that x, y don't hold the end location of the widget in the
previous loop iteration.
The result of the previous example becomes:
{
widget1: { x = 0, y = 0, width = 10, height = 10 }
}
While this might not be the wanted behaviour exactly, distinguishing
between the scenario where 2 widgets are drawn and a scenario where 3
are drawn might complicate the layout function too much.
This patch also adds unit testing that catches the described behaviour.
Signed-off-by: Shay Agroskin <agrosshay@gmail.com>
The fit function is called twice in row.
- The first time it gets the maximum available width, and returns how
much of it it needs (with 0 spacing it would be 477)
- The second time the available width it gets is the same as it returned
last phase (and probably is expected to return the same result again)
The width fit requests is the total width of all widgets together + the
spacing (e.g. if each tag widget is 53 px and spacing is -10 then the
requested width 53 * 9 - 80).
The function tries to first fit all its widgets (the tag numbers) in the
amount of width it received, and only then adds the spacing to it. This
is problematic because in the second phase the widgets need to fit
themselves in the same width they requested earlier minus the spacing
(in case of negative spacing). This is of course impossible and so some
widgets are just not being drawn correctly.
This patch makes fit function take into account the spacing while
placing the widgets and not afterwards.
Also add unit-testing that test the bug described.
Signed-off-by: Shay Agroskin <agrosshay@gmail.com>
The function has several expressions of the form
if self._private.dir == "y" then
This patch stores the result of
self._private.dir == "y"
to avoid code duplication.
Also remove the 'used_in_dir' and 'in_dir' variables since their values
can be calculated using other variables in the function and updating
them individually is error prone.
This patch doesn't do any functional changes.
Signed-off-by: Shay Agroskin <agrosshay@gmail.com>
This removes the section about advanced build options and build
dependencies and points to the docs page instead.
Signed-off-by: Lucas Schwiderski <lucas@lschwiderski.de>
This converts the code snippets to the alternate block definition and
adds language hints to enable syntax highlighting for compatible parsers
(such as on the GitHub page).
Signed-off-by: Lucas Schwiderski <lucas@lschwiderski.de>
Some platforms, such as Arch Linux, already moved to Lua 5.4, while
offering Lua 5.3 as a separate executable, such as `/usr/bin/lua5.3`.
To be able to build awesomeWM on these platforms without extensive
shims, this change introduces a new CMake variable `LUA_EXECUTABLE`.
Its default is set by `find_program` to the usual `/usr/bin/lua`,
but allows running CMake like this:
```sh
cmake ../ \
-DLUA_INCLUDE_DIR=/usr/include/lua5.3 \
-DLUA_LIBRARY=/usr/lib/liblua.so.5.3 \
-DLUA_EXECUTABLE=/usr/bin/lua5.3
```
Emmanuel Lepage Vallee
Aire-One
mergify[bot]
Lucas Schwiderski
Lucas Schwiderski
Yauhen Kirylau
Shay Agroskin
James R
Jonas Belouadi