There was a problem that the examples were considered to have failed as soon as
they produced any kind of output, but there were legitimate cases of warnings
being printed that triggered these checks. Commit 4819be4f4f used a
regular expression to detect and ignore this warnings.
This commit reverts the above commit and instead silences the warnings by
monkey-patching the function that prints the warnings into a no-op.
Signed-off-by: Uli Schlachter <psychon@znc.in>
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 a race with autofocus. To overcome this, add another step that tests
that moving the client back to a visible tag and focusing it updates
_NET_CURRENT_DESKTOP. Afterwards, we kill the client so that it can no longer
interfere.
Signed-off-by: Uli Schlachter <psychon@znc.in>
NET_CURRENT_DESKTOP is now being set to the index of the tag with currently focused client.
In case of no focused clients present, first selected tag index is taken, with fallback value being 0.
Current desktop is updated on next client signals: focus, unfocus, tagged, untagged.
Current desktop is also updated on tag property::selected signal.
This should fix drag and drop issues with chrome-based applications on multihead setups
A client c could have no c.machine or no c.pid because the corresponding
properties are not set on its window. Previously, the C code would return an
empty string or 0 for these values. This commit makes the C code give Lua no
value instead (not even a nil).
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.
The XEmbed protocol defines a special property that defines if the embedded
window wants to be visible or not. Up to now, awesome always ignored this entry
and instead behaved as if the bit was set. This commit makes it properly respect
the bit.
Testing done: None. No idea how. Apparently nothing really uses this bit,
because we didn't get bug reports about it yet.
Signed-off-by: Uli Schlachter <psychon@znc.in>
Uli Schlachter
Daniel Hahler
Uli Schlachter
Emmanuel Lepage Vallée
Max
Daniel Hahler
Mikhail Schemelev