When awful.tag.new() got a list of layouts shorter than the list of
names, it would previously create tags with nil as their layout. This
commit changes this so that the first layout is repeated if necessary.
Related-to: https://github.com/awesomeWM/awesome/issues/1853
Signed-off-by: Uli Schlachter <psychon@znc.in>
If an error occurs while a layout is being applied, arrange_lock could
get stuck at true, meaning that no more re-arranges will happen, thus
breaking the whole layout machinery.
Such errors could happen because the layout itself produces an error,
but also because a width is too large and c:geometry() throws an error.
Thus, this commit moves all of the actual "apply a layout"-code into a
protected context.
Fixes: https://github.com/awesomeWM/awesome/issues/1853
Signed-off-by: Uli Schlachter <psychon@znc.in>
The documentation for awesome.register_xproperty, awesome.get_xproperty
and awesome.set_xproperty were lost in commit 26f15a13f3. This
commit adds them back.
Fixes: https://github.com/awesomeWM/awesome/issues/1817
Signed-off-by: Uli Schlachter <psychon@znc.in>
LGI's async support was trying to yield inside a protected call. Lua 5.1
cannot do that. Work around this by reverting to the behaviour before
commit 50cfa6c: Only call the callback in a protected context.
Fixes: https://github.com/awesomeWM/awesome/issues/1837
Signed-off-by: Uli Schlachter <psychon@znc.in>
Just re-arranging on every focus change would cause useless/needless
re-arranges (which have no effect except to waste CPU time). Thus, this
adds a special (undocumented) flag on layouts that makes sure that a
rearrange occurs when the focus changes.
Fixes: https://github.com/awesomeWM/awesome/issues/1799
Signed-off-by: Uli Schlachter <psychon@znc.in>
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>
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>