This allows to figure out if a test will generate an image without
having to run it. The long term plan for this is to run the tests during
compiling ("make") and not during configuring ("cmake"). Since the list
of files to e.g. install needs to be known during configuring, this
commit is a necessary step in that direction.
Signed-off-by: Uli Schlachter <psychon@znc.in>
No currently existing test produces a PNG image, so why do we even check
for such an output file?
I did 'rm -rf build && make -j9 && cp -r build /tmp', then applied this
patch, and then did another 'rm -rf build && make -j9'. According to
diff, the resulting directories are basically the same (except for lots
of timestamps and some non-determinism in CMake).
Signed-off-by: Uli Schlachter <psychon@znc.in>
The getters for properties already get the object as their second
argument, so there is no need to get the object again from Lua.
Fixes: https://github.com/awesomeWM/awesome/issues/2299
Signed-off-by: Uli Schlachter <psychon@znc.in>
When a new client appears, we reparent its window into a window of our
choice so that we can add decorations. However, windows can be difficult
making the reparenting fail. For example, some snapshots of GTK+ set a
parent-relative background, which means that its parent windows have to
have the same depth as the window itself. This makes reparenting fail if
transparency is used/supported.
Make the failure mode... different, by checking if reparenting
succeeded. If it failed, we print an error message and unmanage the
window immediately. This means that those GTK+ windows just do not
appear at all, instead of behaving weirdly.
This idea of this patch came from i3.
Related-to: https://github.com/awesomeWM/awesome/issues/2279
Signed-off-by: Uli Schlachter <psychon@znc.in>
Layouts work with the client's geometry in "space on screen that is
assigned to this client". This means that the geometry should include
decoration (titlebar and borders) and useless gaps.
Everything else (especially the C code) works with client's geometry in
"space that the client can draw on". This means that the titlebar,
borders and the useless gaps are not included into this size.
Thus, when applying size hints, the tile layout has to convert between
these two representations. Otherwise, size hints are applied incorrectly
and to a wrong geometry.
Fixes: https://github.com/awesomeWM/awesome/issues/1418
Signed-off-by: Uli Schlachter <psychon@znc.in>
The systray_cleanup() function gives up the _NET_SYSTEM_TRAY_Sn
selection ownership and should be called only when Awesome exits.
Calling systray_cleanup() from drawin_systray_kickout() is not correct,
because drawin_systray_kickout() is called when the system tray window
needs to be hidden, including the case when the last tray icon was
removed and the tray became empty.
Fixes: https://github.com/awesomeWM/awesome/issues/2301
Signed-off-by: Sergey Vlasov <sigprof@gmail.com>
From `kill(3p)`:
> If pid is greater than 0, sig shall be sent to the process whose
> process ID is equal to pid.
> If pid is 0, sig shall be sent to all processes (excluding an
> unspecified set of system processes) whose process group ID is equal to
> the process group ID of the sender, and for which the process has
> permission to send a signal.
> If pid is −1, sig shall be sent to all processes (excluding an
> unspecified set of system processes) for which the process has
> permission to send that signal.
> If pid is negative, but not −1, sig shall be sent to all processes
> (excluding an unspecified set of system processes) whose process group
> ID is equal to the absolute value of pid, and for which the process has
> permission to send a signal.
I do not know how a GDataInputStream / GBufferedInputStream decides
about the size of its internal buffer when reading input by line, but in
issue #2288, an example where the output of date (about 30 bytes) was
read ten times per second caused ten megabytes of memory usage for this
internal buffer. Try to save some memory by explicitly shrinking the
buffer size when we are done reading from the stream.
Reference: https://github.com/awesomeWM/awesome/issues/2288
Signed-off-by: Uli Schlachter <psychon@znc.in>
This allows to e.g. easily run awesome from source (for an hour) via
TEST_TIMEOUT=42d tests/run.sh /dev/null.
Signed-off-by: Uli Schlachter <psychon@znc.in>
* Default config: Unify mouse dragging behavior
When moving or resizing a client by dragging its titlebar with mouse,
the client is automatically focused and raised. However, this behavior
is not replicated by tne other dragging method, i.e. grabbing it with
mouse while pressing the modkey. Sometimes, this causes a client to
disappear below another one while moving.
This commit unifies handling of dragging clients with mouse, by ensuring
that the client is focused and raised, whichever dragging method is
used. The fix applies both to moving and resizing clients.
Signed-off-by: Piotr Śliwka <contact@psliwka.info>
* Default config: Fix clientbuttons style
This commit unifies code style of click handling functions defined in
`clientbuttons` table, to match the style introduced in a228696.
Signed-off-by: Piotr Śliwka <contact@psliwka.info>
Instead of printing the list of commits for which tests failed, this
printed all commits.
Testing done on this change: None. Testing the infrastructure for Travis
is a bit hard and quite meta. (Tests for the tests?)
Signed-off-by: Uli Schlachter <psychon@znc.in>
* Make fake screens permanent
Before this, screen_scan() made sure that awesome's information about
available screens conforms to what the X11 server reports. Since fake
screens are, well, fake, this meant that they were deleted.
This commit marks fake screen and handles them specially in
screen_scan() so that they are not deleted.
Note that I did not test this commit at all since I still haven't
figured out how to test RandR stuff without actually messing with
hardware.
Thanks to @madduck for bringing this up and making me fix this long
standing "huh? is that really supposed to work like that?".
Signed-off-by: Uli Schlachter <psychon@znc.in>