We cannot possibly know what is in the PATH of a user. The completion
test cases however assume that there is nothing else in the PATH that
starts with `true` other than `true` itself.
These two methods create or respectively destroy a temporary PATH
directory especially for testing. We can put commands in there via
symlinks and verify the correct functionality of the complete commands.
The PATH environment variable is set and reset via GLib.
Several themes use `dpi(2)` which is quite thick, and it is better to
use the default of 0 here, instead of `beautiful.border_width`, which is
meant for borders on clients.
I am not sure what exactly goes on in the below bug report, so this will
just paper over the problem. I still think that this patch is a good
idea even when it is not a proper fix, since keyboard layouts are
complicated and so this code should be robust and hard to break.
Fixes: https://github.com/awesomeWM/awesome/issues/1933
Signed-off-by: Uli Schlachter <psychon@znc.in>
When gap_single_client is set to 'false', no gap is used when only one
client is shown in a tag. Since the max layout only ever shows one
client at a time it makes sense to apply this setting for this layout
regardless of the actual number of clients in that tag.
Additionally, if the 'master_fill_policy' property is set to
'master_width_factor', then use a gap even if there is only one client
visible and 'gap_single_client' is false.
It should get run explicitly only.
As for Travis: we run it there initially (when just using `make`, and
later again - at least when using check-unit-coverage).
There were multiple things which stood out to me, as I was trying to setup a simple calendar popup for my textclock:
1.: The functions in https://awesomewm.org/doc/api/classes/awful.widget.calendar_popup.html#Functions were not named correctly (calendar vs calendar_popup) which (naturally) produced an error when used as awful.widget.calendar.month() .
2.: The example for calendar_popup.month() was obviously missing a line (where does the month_calendar come from?) . Resolved by copying the line from the attach-example
3.: The same examples also only refer to the function as calendar.month() which should be changed to awful.widget.calendar_popup.month()
codecov-bash runs it by default already, therefore we do not not have to
do so manually before do_codecov_gcov.
And with `do_codecov` itself, it gets disabled using `-X gcov`.
project() automatically sets the PROJECT_NAME variable. Thus, when this
CMake code is run due to being included by awesome, this commit has no
effect.
When this CMake code is run on its own, CMake will no longer check for a
C and C++ compiler.
Signed-off-by: Uli Schlachter <psychon@znc.in>
This makes the CMake run much faster in general, and does not re-check
the dependencies every time again (since it gets cached).
There are several reports where the reference to the missing module was
not provided, and they all appear to have happened with CMake 3.6.1.
A missing "foobar" module gets reported there, but if you remove
/usr/lib/pkgconfig/libstartup-notification-1.0.pc, this does not get
reported:
-- Checking for modules '…'
--
CMake Error at /tmp/cmake/share/cmake-3.6/Modules/FindPkgConfig.cmake:424 (message):
A required package was not found
This apparently affects modules that have version requirements. After
removing that from "libstartup-notification-1.0>=0.10", it gets reported
also: "No package 'libstartup-notification-1.0' found".
The workaround is to require the package without version information
before the requirement with the version information.
This reverts https://github.com/awesomeWM/awesome/pull/1253.
This was changed in ec9a981d for no good reason, and using a temporary
file removes the requirement to restore it on exit.
And it is necessary in case the original file is not writable (e.g. in
case of a read-only Docker mount).
This adds a custom command to build the documentation, where you can
specify the generated output then. "ldoc" then depends on this output.
This way "ldoc" is not being run every time, but only if the input files
have changed. ldoc's config is added therefore to the list of
dependencies to make config changes trigger a rebuild.
CMake "fakes" a call to "project(Project C CXX)" if it does not see a
project() call in CMakeLists.txt. Since we had this call in a different
file, this default applied. This meant that CMake unnecessarily required
a C++ compiler.
Fix/work-around this by moving the call to project() into CMakeLists.txt
Reference: https://github.com/awesomeWM/awesome/pull/1907#discussion_r125581273
Signed-off-by: Uli Schlachter <psychon@znc.in>
- add colors
- count test files
- display error summary
- filter out a_dbus_connect warnings and "Test finished successfully." message
- print current step with VERBOSE=1
- kill clients at the end of tests in an extra step
It does not seem to be required by tests (anymore), and fails when the
source dir is mounted read-only (which is the case for the Docker based
builds I am working on).
I think it is clearer anyway to run it as `build/awesome`.
If `cmake ..` in the build dir failed (e.g. because Lua could not be
found), a subsequent `make` will cause a strange error (this is in
non-quiet mode):
```
/src/awesome # make
echo "Running make Makefile…"
Running make Makefile…
make -C build Makefile
make[1]: Entering directory '/src/awesome/build'
make[1]: *** No rule to make target 'Makefile'. Stop.
make[1]: Leaving directory '/src/awesome/build'
make: *** [Makefile:44: Makefile] Error 2
```
With `s` in `MAKEFLAGS` (at the top of our Makefile):
```
Running make check-unit…
make[1]: *** No rule to make target 'check-unit'. Stop.
make: *** [Makefile:44: check-unit] Error 2
```
Therefore this patch looks for build/Makefile to be generated really.
The screen object can be indexed by strings to find a screen via some
RANDR output name. However, if a string is used which does not
correspond to a known output, the code just falls through to a function
which will complain "string provided, userdata expected".
This commit provides a slightly more useful error message instead.
Signed-off-by: Uli Schlachter <psychon@znc.in>
Using exit code != 1 (e.g. 2 as with "make") appears to cause Travis to
consider the build job as an error ("!"), instead of a failure ("X").
Example build: https://travis-ci.org/awesomeWM/awesome/builds/248484247
!: https://travis-ci.org/awesomeWM/awesome/jobs/248484252
Test finished successfully
There were 3 errors!
make[4]: *** [CMakeFiles/check-integration] Error 1
make[3]: *** [CMakeFiles/check-integration.dir/all] Error 2
make[2]: *** [CMakeFiles/check-integration.dir/rule] Error 2
make[1]: *** [check-integration] Error 2
make: *** [check-integration] Error 2
++return
X: https://travis-ci.org/awesomeWM/awesome/jobs/248484250
Test finished successfully
There were 3 errors!
This now runs parse_desktop_file in a protected context so that a single
broken desktop file does not break the whole menubar.
Also, the error message that is produced when a Lua error occurs now
also includes the file name of the .desktop file which we attempted to
parse. This should help quite a lot in debugging.
Related-to: https://github.com/awesomeWM/awesome/issues/1880
Signed-off-by: Uli Schlachter <psychon@znc.in>
Florian Gamböck
Daniel Hahler
Crazy Lemon
Uli Schlachter
Tomoya Tabuchi
Emmanuel Lepage Vallée
Uli Schlachter
Jan Larres
mqus
morethanoneanimal
actionless
Daniel Hahler