This makes "make install" not run the unit tests (again).
Instead "check-unit" is added to the top-level wrapper Makefile to be
run for its "all" task.
[ 57%] Building C object CMakeFiles/awesome.dir/dbus.c.o
…/awesome/build/dbus.c: In function ‘a_dbus_message_iter’:
…/awesome/build/dbus.c:137:27: warning: statement will never be executed [-Wswitch-unreachable]
int datalen = 0;
^~~~~~~
It was changed in dd862007, but probably not intentional.
This test runs into an lgi bug that causes awesome to segfault. Work
around this by just disabling the test where needed.
Signed-off-by: Uli Schlachter <psychon@znc.in>
This does not actually test anything. It just makes sure that the code
runs. A proper test still seems to need some time and some hacks, but
this basic test is enough to check that the menubar does not cause any
Lua errors.
Signed-off-by: Uli Schlachter <psychon@znc.in>
The combination of TEST_PREV_COMMITS=1 and EMPTY_THEME_WHILE_LOADING=1
does not work. When trying to test the previous commits, the following
error happens:
error: Your local changes to the following files would be overwritten by
checkout:
lib/beautiful/init.lua
This local modification was done by EMPTY_THEME_WHILE_LOADING=1.
Signed-off-by: Uli Schlachter <psychon@znc.in>
Without this, users would modify the beautiful table directly instead of
the theme. This made a difference for code using beautiful.get() to get
the theme.
Reference: https://github.com/awesomeWM/awesome/pull/1854
Signed-off-by: Uli Schlachter <psychon@znc.in>
When awful.tag.new() got a list of layouts shorter than the list of
names, it would previously create tags with nil as their layout. This
commit changes this so that the first layout is repeated if necessary.
Related-to: https://github.com/awesomeWM/awesome/issues/1853
Signed-off-by: Uli Schlachter <psychon@znc.in>
If an error occurs while a layout is being applied, arrange_lock could
get stuck at true, meaning that no more re-arranges will happen, thus
breaking the whole layout machinery.
Such errors could happen because the layout itself produces an error,
but also because a width is too large and c:geometry() throws an error.
Thus, this commit moves all of the actual "apply a layout"-code into a
protected context.
Fixes: https://github.com/awesomeWM/awesome/issues/1853
Signed-off-by: Uli Schlachter <psychon@znc.in>
Using `beautiful.get()` has the drawback of not supporting theme
variables set from `rc.lua`. It is also used less often than
direct theme access, making it a bit inconsistent with how other
modules behave.
Previously this code checked the generated documentation to decide if
something is a class or a module. Now, it parses the source file and
looks for the @classmod, @module and @submodule tags to make the same
decision.
Fixes: https://github.com/awesomeWM/awesome/issues/1255
Signed-off-by: Uli Schlachter <psychon@znc.in>
The return value for this function is used as an index in a table and
Lua does not like nil as an index.
The function that actually looks for icons, find_icon_theme() already
falls back to "hicolor" if it does not find anything via the current
theme, so fix this issue by just falling back to "hicolor" here as well.
Fixes: https://github.com/awesomeWM/awesome/issues/1819
Signed-off-by: Uli Schlachter <psychon@znc.in>
The documentation for awesome.register_xproperty, awesome.get_xproperty
and awesome.set_xproperty were lost in commit 26f15a13f3. This
commit adds them back.
Fixes: https://github.com/awesomeWM/awesome/issues/1817
Signed-off-by: Uli Schlachter <psychon@znc.in>
Previously, the lgi check used the normal Lua interpreter to check if
lgi is installed. However, nothing ensures/requires that awesome is
built against the same Lua version as the Lua interpreter. This means
that if lgi is only available for some Lua version, then the check could
succeed even though awesome would later fail to start. Also, the check
might have failed even though awesome would not have any problems
finding lgi.
This commit replaces lgi-check.sh by a small C program which does the
same thing. This ensures that the same Lua version is used as awesome
will be using.
There are some places that still use the Lua interpreter: Example tests
(run through the Lua interpreter directly) and unit tests (run through
busted). For unit tests, this should not make much of a difference and
example tests might later get similar treatment.
Signed-off-by: Uli Schlachter <psychon@znc.in>
This makes sure that the liblua.so that we built actually depends on the
libraries that it needs (libm and libdl). Previously we already tried
this, but specified "-ldl" at the beginning of the command line. Since
nothing needed this library yet, the linker just ignored it.
Signed-off-by: Uli Schlachter <psychon@znc.in>
LGI's async support was trying to yield inside a protected call. Lua 5.1
cannot do that. Work around this by reverting to the behaviour before
commit 50cfa6c: Only call the callback in a protected context.
Fixes: https://github.com/awesomeWM/awesome/issues/1837
Signed-off-by: Uli Schlachter <psychon@znc.in>
Daniel Hahler
Uli Schlachter
Emmanuel Lepage Vallée
Tim Roes
SammysHP
Uli Schlachter
Yauhen Kirylau
nahsi
getzze
Simon Désaulniers