For setting the shape of the tooltip, this code creates an image surface
describing the wanted shape. After this commit, this image surface is
finished when it is no longer needed. This results in most of the
image's memory to be freed immediately instead of only later when the
garbage collector collects the image surface.
Related-to: https://github.com/awesomeWM/awesome/issues/1958
Signed-off-by: Uli Schlachter <psychon@znc.in>
This function creates a temporary image surface to set the shape of a
wibox. After this commit, the image is now finished after use. This
results in most of the image's memory to be freed immediately instead of
waiting for the garbage collected to collect it.
Related-to: https://github.com/awesomeWM/awesome/issues/1958
Signed-off-by: Uli Schlachter <psychon@znc.in>
This function queries the shape of a client and then does something with
it. This commit makes sure the image is finished afterwards, which means
that most of its memory is released immediately instead of waiting for
the garbage collector to collect it.
Related-to: https://github.com/awesomeWM/awesome/issues/1958
Signed-off-by: Uli Schlachter <psychon@znc.in>
When doing w.shape_bounding = foo on a wibox, the code would first read
shape_bounding from the underlying drawin. This would create a
(possibly) huge cairo image surface that just waits to be collected by
the garbage collector, resulting in increased memory usage.
Fix this by checking the force_forward table first. This tables contains
the names of shape properties. Thus, the evaluation of this statement
gets short-circuited and the property is on the drawin is not read.
Helps-with: https://github.com/awesomeWM/awesome/issues/1958
Signed-off-by: Uli Schlachter <psychon@znc.in>
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!
Uli Schlachter
Crazy Lemon
Uli Schlachter
Tomoya Tabuchi
Daniel Hahler
Emmanuel Lepage Vallée
Jan Larres
mqus
morethanoneanimal
actionless
Daniel Hahler