This reverts commit facf676b13.
Using capi.client.focus.screen to decide which screen is focused breaks
a multiscreen setup. At least makes it extremely annoying to use.
In particular, if you have a focused client on screen 1, move the mouse
to screen 2 and launch a new client, the new client appears in screen 1,
since screen.focused reports that current focused screen is 1, not 2
because of the focused client.
Close#1035Fix#1029
The spawn code didn't properly handle the case where there
is an empty command stream. In that case, no error is
reported as there is simply nothing to do. The error message
was probed and this caused an invalid read and crash.
Fix#1033
The deprecation wrapper that we still have for this function didn't return
anything. However, awful.util.pread() used to return strings. This breaks
script.
Work around this by returning an empty string. That way code will still break,
but at least it should not error out.
Signed-off-by: Uli Schlachter <psychon@znc.in>
I'm not good with these, but we have to start somewhere. Feel free to extend
with own ideas. The main point for me here is to ask for the output of `awesome
--version`.
Signed-off-by: Uli Schlachter <psychon@znc.in>
The default config creates the same set of tags for all screens ("1" to "9"). An
awful.rules-rule with e.g. screen = 2, tag = "3" should obviously tag matching
clients with tag "3" of the second screen.
However, the implementation used the first matching tag in the list of all tags
and thus the client ended up tagged with tag "3" from screen 1. Fix this by
calling find_by_name() with the screen that the client is assigned to.
The existing implementation of awful.rules guarantees that any
"screen"-properties are applied before the code touched by this commit is run,
thus this should always work.
This commit does not add a test catching this because we are currently quite bad
at testing multi-screen scenarios and I don't want to invent the necessary
machinery right now.
Fixes: https://github.com/awesomeWM/awesome/issues/988
Signed-off-by: Uli Schlachter <psychon@znc.in>
Commit 0318c6132840413b1f added an image for the minimize button which was
missing before. However, only the default theme and xresources where fixed to
contain the path to the image.
This commit adds the path to all themes.
Also, minimized clients aren't visible, just as closed (=killed) clients aren't
visible. Thus, we don't need an "active" version of this image.
This commit makes us handle the image for the minimize button just like we
handle the close button: There is no difference between "active" and "inactive"
and the file path in the theme doesn't get any path suffix.
Fixes: https://github.com/awesomeWM/awesome/issues/387
Signed-off-by: Uli Schlachter <psychon@znc.in>
When called with "--version", awesome prints the Lua version that it was
compiled against and the one that it is running against. This commit makes the
code detect LuaJIT and makes it print the LuaJIT version instead of an
unspecific "Lua 5.1".
Signed-off-by: Uli Schlachter <psychon@znc.in>
The actual bg is drawn either with fake transparency over the wallpaper (this
uses operator OVER) or for true transparency with operator SOURCE. The bgimage
should be drawn ontop of this without erasing the background and thus needs
operator OVER.
However, before this commit the bgimage was drawn in the same way as the bg and
thus inherited its SOURCE operator if a compositor is running. Fix this by
restoring the default operator (OVER) and also e.g. the default source before
drawing the bgimage.
Fixes: https://github.com/awesomeWM/awesome/issues/954
Signed-off-by: Uli Schlachter <psychon@znc.in>
When called with the file name of an image, this function failed to turn that
file name into a cairo surface.
Fixes: https://github.com/awesomeWM/awesome/issues/954
Signed-off-by: Uli Schlachter <psychon@znc.in>
With luacov 0.12.0-1 our travis build fails. It was always kinda broken, but now
this breakage is revealed.
What likely happens: Our .luacov errors out because some needed environment
variable to figure out where to put the results is not set. Due to the way we
load luacov, it runs with its default config which luckily happens to work. With
luacov 0.12.0-1 the error is propagated instead and the build fails.
Signed-off-by: Uli Schlachter <psychon@znc.in>
Since commit 4daa6e8, we are denying resizes and moves for embedded windows
(=tray icons). However, the Xembed spec says that the embedding client acts like
a WM (as specified by ICCCM) to the embedded window. Thus, when denying a
configure request, we have to inform the window by sending it a synthetic
configure notify. Otherwise, GTK seems to sometimes not draw its tray icon.
Fixes: https://github.com/awesomeWM/awesome/issues/986
Signed-off-by: Uli Schlachter <psychon@znc.in>