The magnifier layout wants to ignore floating clients. Before 82342f0 this was
done by calling awful.client.floating.get(focus). If "focus" was nil, this might
have checked the floating status of a wrong client (if some other client was
focused, and the code in magnifier set focus=nil before). This issue can easily
be missed and might exist since forever. After 82342f, floating status is
checked via "focus.floating" and this now causes an "attempt to index nil value"
error instead. Much easier to notice.
Fix this by adding the missing nil check and while touching the code, merge this
with the previous "if" and correct another error (the wrong thing happened if we
had #cls=0).
Fixes: https://github.com/awesomeWM/awesome/issues/1103
Signed-off-by: Uli Schlachter <psychon@znc.in>
A client is supposed to go to a screen when:
* It has been started using `awful.spawn` with explicit instructions [1]
* An `awful.rules` rule **or any of its callbacks** set the screen [2]
* When something handle `request::screen` and/or `request::tag` in some
custom ways. [3]
* Some clients can request a screen and mean it (like MythTV/Kodi/XBMC and
some multi-window DAW) [4]
A client is supposed to go to the focused screen when none of the above are
true [5].
Other constraints:
* The screen need to be set only once, anything will will emit
`property::screen` many time and cause side effects.
* There has to be a single entry point to the algorithm, no multiple
"manage" handler.
* Awesome internals must use the `request::` signal API and not force
their decision outside of request handlers.
* Restarting Awesome must not change the client screen
Commit 2178744 fix use case number [1] and [2]. It actually fix [4] too, but
it is an accident and I am not sure we care about [4] anyway. Use case [1]
and [2], however, are very important.
Fix#1091
The geometry storage has been moved into awful.placement. This
code was never executed as data[] was never populated.
There is some behavior that is indeed lost, but it is unlikely
someone will ever notice (it has been broken for 6 months).
The previous code attempted to handle scrren changes while
maximized. The new code organization shift this responsability
to awful.placement. However, it doesn't yet fully implement the
previous logic.
Awesome 3.5.9 accepts `_active`/`_inactive` names for `beautiful`
minimize keys (such as "titlebar_minimize_button_focus_inactive").
Some themes rely on those, meaning that when they loaded under
the current Git, the minimize button went missing. This adds a
fallback, to improve compatibility with the existing themes.
This commit remove the `awful.tag` "manage" hook. The relevant
code has been moved to ewmh.lua request::tag handler. The handler
is called either by a volontary screen change or by a forced one.
It also require the awful.rules to be executed. This is done by
default and the user would have to explicitly disable that
behavior. From now on, disabling the rules require the user to
handle tag selection.
Fixes#1028#1052
There was still a problem that caused the "old" tags to be
inserted in the wrong position when "saved" from a screen being
removed.
Also, this use a :get_tags(true) to save an uneeded sorting pass.
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.
Reported on IRC. I am not sure why swap() is not enough, but the
old code removed before the mouse refactor did this, so apparently
it is necessary.
The fix has been reported to work by spyroboy on IRC, thanks!
First some reminder on how client geometries works (in X11, awesome just copied
that!):
- The position (x,y) defines where the border of the client begins
- This means that the content starts at (x+border_width,y+border_width)
- However, the size is the size of the client without border
- Thus, the client covers the rectangle from (x,y) to (x+2*bw,y+2*bw)
The client snapping code got this wrong. It only deals with rectangles and thus
for things to work as expected, the width/height have to be increased by two
times the border width. When snapping a client against other visible clients,
the geometry of the client to snap against wasn't calculated correctly.
This was apparently noticed at one point and worked around by decreasing the
position by two times the border width. While this is terribly wrong, it
actually makes things work correctly when snapping to the right or bottom edge
of a client, but breaks for the other edges.
Fix this by just calculating things correctly.
This is based on a patch from jk411.
Fixes: https://github.com/awesomeWM/awesome/issues/928
Signed-off-by: Uli Schlachter <psychon@znc.in>
The requirement to call add_signal() was added to catch typos. However, this
requirement became increasingly annoying with property::<name> signals and e.g.
gears.object allowing arbitrary properties to be changed.
All of this ended up in a single commit because tests/examples fails if I first
let add_signal() emit a deprecation warning.
Signed-off-by: Uli Schlachter <psychon@znc.in>
There was already a bug, as self.active_child.visible
was used instead of self.active_child.wibox.visible
This caused some confusion that this attribute was a widget.
It wasn't.
Uli Schlachter
Daniel Hahler
Emmanuel Lepage Vallee
Hisham
Akulen
modk
Akulen
cmertz
Julian Wollrath
Uli Schlachter
Daniel Hahler
Salorium
Max