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.
Running the tests sadly takes much to long. Since I don't have a good idea what
to do about this (I'd like to run all tests in a single Lua process, but that
doesn't seem to be possible easily), instead let's just make it more explicit
what is being done. This commit prints a message for each test that is being
run.
Signed-off-by: Uli Schlachter <psychon@znc.in>
Now that tests are no longer scanned for recursively, the hack of passing values
back and forth via the environment is no longer needed and can be removed.
While at it, this also exchanges the "useless use of regex" for an explicit
string replacement.
Signed-off-by: Uli Schlachter <psychon@znc.in>
Instead of recursively walking the directory tree, this commit makes the code us
GLOB_RECURSE to find all files and then handles them on after another.
Signed-off-by: Uli Schlachter <psychon@znc.in>
The namespace of e.g. "tests/examples/awful/mouse/coords.lua" is "_awful_mouse".
This is purely based on the path of the file.
Previously, this was computed while recursively scanning the directory tree.
This commit instead moves this to an extra function that handles this task.
Signed-off-by: Uli Schlachter <psychon@znc.in>
Previously, while recursively scanning the directory tree, the code in here also
scanned for template.lua files and remembered the latest one it found. This
commit adds a function which finds the right template.lua for a given file name,
making this search explicit and easier to understand.
Signed-off-by: Uli Schlachter <psychon@znc.in>
When a function is disconnected from a signal ("disconnect_signal") that is not
actually connected to the function, two things happened:
1. The attempt to remove the function from the signal array didn't do anything
2. Unreferencing the function noticed that the function wasn't referenced
The second step printed a big, fat scary warning.
Actually, this has the possibility of causing errors. For example, in the
following code, awesome would wrongly unreference the function at the
disconnect_signal() call and might later still try to call it when the
"refresh" signal is emitted:
do
local function f() end
awesome.connect_signal("refresh", f)
awesome.disconnect_signal("debug::error", f)
end
Fix this by making signal_disconnect() return a boolean value indicating if it
actually did something. All callers are fixed to use this value and only update
the reference counts if something was actually disconnected.
Fixes: https://github.com/awesomeWM/awesome/issues/814
Signed-off-by: Uli Schlachter <psychon@znc.in>
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>
Emmanuel Lepage Vallée
Daniel Hahler
Uli Schlachter
Uli Schlachter
Max
Daniel Hahler
Mikhail Schemelev