The index was updated on an unordered table. As the elements
order did not match the relative indices once they have been
changed, further calls to set_index produced garbage.
The default taglist didn't notice because it use screen.tags
table index instead of the tag index. A debug using
echo 'for _,t in ipairs(mouse.screen.tags) do
print("INDEX:", _, t.index, t.name) end' | awesome-client
Would have shown two or more elements with the same index. To
debug issues related to tag indices, this bash script can be
enabled:
while true; do
echo 'for _,t in ipairs(mouse.screen.tags) do
assert( _==t.index) end' | awesome-client
sleep 0.5
done
This commit add the last placement function imported from the
Radical module.
It allows to place a wibox/client next to another object. It tries
to find the best fit. It also support wibox widgets.
This is intended for tooltips and menus, but can also be used in
`awful.rules` to place the new client as close as possible to the
focused one without overlap.
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 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>
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>
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>
All other shape did it. While it usually have no side effects,
as seen in #920 screenshot from @actionless, there is instances
where this produce a invalid rectangle.
If:
1) An app is open in a tag
2) A new tag is created
3) The app is closed in the first tag
4) The first tag is deleted
5) The new tag is deleted
Then this history would try to restore an inactive tag without
a screen. Bad things will then happen.
Emmanuel Lepage Vallée
cmertz
Julian Wollrath
Uli Schlachter
Uli Schlachter
modk
Daniel Hahler
Salorium