This makes sure that all sizes that are specified in themes go through
the dpi() function. For most themes this just means that the value 0 is
DPIfied, which should not make much of a difference. However, for
zenburn this actually adds the very first calls to dpi() to this theme.
Fixes: https://github.com/awesomeWM/awesome/issues/1807
Signed-off-by: Uli Schlachter <psychon@znc.in>
Commit e54361a374 added code so that we pass the list of
currently running children across restart via an environment variable.
As Colin Walters correctly points out, setenv() is not safe in a
multi-threaded processes.
Thus, instead of using the environment, use the command line to pass
this information along.
https://github.com/awesomeWM/awesome/issues/1812
Signed-off-by: Uli Schlachter <psychon@znc.in>
Before this, we used a_exec() with started a shell and used it to parse
our glued-together command line. That only asks for escaping trouble
(think: Path to the config file is given on the command line and
contains a space), so use execvp() directly.
Signed-off-by: Uli Schlachter <psychon@znc.in>
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>
Uli Schlachter
Caleb Maclennan
Uli Schlachter
Emmanuel Lepage Vallée
Daniel Hahler
Åsmund Ervik
ReVMatthias
Haochen Tong
BuildTools
Benoit de Chezelles