In Unix, so that a process can learn about the exit status of the child
processes that it started, children become zombie processes until the
parents collects their exit information. We use glib both for starting
and for collecting processes. However, when awesome is restarted, the
new instance inherits children, but does not know about them and does
not inherit them.
Fix this by explicitly tracking a list of running child processes and by
serialising them across a restart via an environment variable. The new
awesome instance can then watch for these child processes, but besides
that it ignores them and does not use their exit status in any way.
Thanks to Colin Walters for the hint with serialising the list of processes.
Fixes: https://github.com/awesomeWM/awesome/issues/1193
Signed-off-by: Uli Schlachter <psychon@znc.in>
Previously, running make in the build/ directory depended on the "cmake"
target which was running the cmake command. This target was phony,
meaning that it was always considered to be out of date and needed to be
re-generated.
Change this so that instead things depend on the CMakeCache.txt file. If
that file is already there, we do not re-run cmake.
Signed-off-by: Uli Schlachter <psychon@znc.in>
This marks the functions gears.surface.widget_to_svg() and
gears.surface.widget_to_surface() as deprecated in awesome 5. This means
that by the time that awesome 6 becomes a thing, we can finally remove
these...
Signed-off-by: Uli Schlachter <psychon@znc.in>
These are supposed to eventually replace the already-existing functions
in gears.surface which have a similar signature
Signed-off-by: Uli Schlachter <psychon@znc.in>
luaL_dostring(L, s) is a macro that expands to
luaL_loadstring(L,s)||lua_pcall(L,0,LUA_MULTRET,0). Then,
lua_pcall(L,n,r,f) sometimes (since Lua 5.3?) is a macro that expands to
lua_pcallk(L,n,r,f,0,NULL), but can sometimes also just be a function.
Explaining all the above would make this section more complicated and
apparently no one uses this hint anyway, because no one told us yet that
this hint does not work.
Signed-off-by: Uli Schlachter <psychon@znc.in>
Commit 222f0a133c optimised the case where we change the wallpaper
so that we can give the new wallpaper to Lua faster. However, contrary
to what was intended, it also caused another wallpaper update later when
the server told us that the wallpaper actually changed. This was because
the juggling with multiple X11 connections went wrong.
Fix this by using the right connection to actually change the wallpaper.
Signed-off-by: Uli Schlachter <psychon@znc.in>
When the border width changes, we move the client according to its
gravity. This can cause problems with the following code. Fix this by
restoring the original border width again, which undoes the move.
Signed-off-by: Uli Schlachter <psychon@znc.in>
This implementes the FIXME added a few commits ago. A new
request::geometry handler turns client requests into normal
lua `c.maximized = true` property changes.
This function tried to move the client to its new screen based on
shifting around its current geometry. However, it assumed that the
client was actually visible on its current screen, which is not always
the case.
Fix this by just forcing the client into its new screen if our moving
approach does not work.
This also reverts commit d5e365804c which
is no longer necessary. This commit only hid the issue (partly).
Fixes: https://github.com/awesomeWM/awesome/issues/318
Signed-off-by: Uli Schlachter <psychon@znc.in>
The code here made sure that clients were not moved outside of the root
window. However, that's not enough, because clients can still end up
inside the root window, but outside of anything that is visible in some
output. Thus, just remove this.
Related-to: https://github.com/awesomeWM/awesome/issues/318
Signed-off-by: Uli Schlachter <psychon@znc.in>
A relatively common problem with awesome is with mixing sticky clients
and the focus history. Once a sticky client ever had the focus, it will
always get the focus after a tag switch. This is because the focus
history is global and the sticky client is always the most recently
focused and currently visible client in the list.
Work around this by discriminating sticky clients: First try to find a
client to focus, but ignore sticky clients. When this does not find
anything, try again, but this time also consider sticky clients.
(Basically the same issue exists with clients that are on multiple tags,
but I guess that one can be ignored.)
Fixes: https://github.com/awesomeWM/awesome/issues/733
Signed-off-by: Uli Schlachter <psychon@znc.in>
Once upon a time, 4b9584fdb1 already fixed this problem: We have to
set the border width to zero before applying the new geometry to the
client, because changing the border width makes the client move
according to its gravity.
Then came e54387904b and made this code use awful.placement instead
of just fullscreening the client itself (without explaining why in the
commit message!). After this commit, the border width was just ignored
and left as-is. This was then fixed in 0bf8bb6a64 (no idea which
callback the commit message refers to, the old code was basically just
c.border_width=0, c:geometry(screen_geo)). However, now the border width
was again changed after the geometry and the bug that was fixed by
4b9584fdb1 was back.
This commit fixes this regression again by making sure that the border
width is set to zero before the geometry is set. This becomes slightly
more complicated, because now it is also awful.placement's job to
restore the old border width.
This is why this commit adds a new option to awful.placement so that it
sets the border width to zero after creating its memento of the old
border width.
Fixes: https://github.com/awesomeWM/awesome/issues/1607
Signed-off-by: Uli Schlachter <psychon@znc.in>
This adds a C program which tests if the window manager handles
gravities correctly. This program is loosely based on metacity's
test-gravity.c, but completely rewritten and this version does automatic
tests instead of allowing the user to perform testing by hand.
By having this as a self-contained C program, it is possible to compare
awesome's behaviour with the behaviour of other WMs.
In my testing, only metacity and awesome pass this test. This is not
that much of a big surprise since awesome was fixed in
https://github.com/awesomeWM/awesome/pull/505 to work correctly with
metacity's test-gravity.c. However, I am surprised that e.g. Fluxbox
gets this wrong.
Signed-off-by: Uli Schlachter <psychon@znc.in>
Emmanuel Lepage Vallée
Daniel Hahler
Uli Schlachter
Åsmund Ervik
Uli Schlachter
ReVMatthias
Haochen Tong
BuildTools
Benoit de Chezelles