- exit with a non-zero status code when dbus-send fails.
If awesome does not respond to the D-Bus message, e.g. because it is not
running (yet), awesome-client now returns with a non-zero return code.
This can be used to check if awesome has finished starting up, which is
meant to be used for the functional test runner.
- changed the shebang to use bash directly, which simplifies the logic
to detect/handle "bash as /bin/sh" and allows to use `set -o pipefail`
(which makes handling the D-Bus error easier - without using a subshell).
- fix the prompt: now with trailing space, and the prompt is actually used
(which wasn't the case with /bin/sh not pointing at bash before).
Closes https://github.com/awesomeWM/awesome/pull/304.
I've noticed that `Pango.parse_markup` returns "userdata" instead of a
string in case of errors [1], which then causes the `debug::error`
handler to not handle it correctly:
W: awesome: luaA_dofunction:77: error while running function
stack traceback:
[C]: in ?
[C]: in function 'error'
/usr/local/share/awesome/lib/wibox/widget/textbox.lua:63: in function 'set_markup'
[string "require("wibox").widget.textbox():set_markup(..."]:1: in function 'f'
/usr/local/share/awesome/lib/awful/remote.lua:25: in function </usr/local/share/awesome/lib/awful/remote.lua:21>
error: attempt to concatenate a userdata value
This patch makes sure that `err` is a string when passing it to
naughty.notify in the default `debug::error` handler.
Closes#302.
1: https://github.com/pavouk/lgi/issues/115
In ed09d8e this was changed accidentally, while only `request::focus`
should have been changed:
- c:emit_signal('request::activate',"rules")
+ c:emit_signal('request::activate', "rules", false)
Currently `taglist_update` gets triggered often, because it listens to
a lot of signals.
This patch makes it only call the last one through `timer.delayed_call`.
Currently `tasklist_update` gets triggered often, because it listens to
a lot of signals.
This patch makes it only call the last one through `timer.delayed_call`.
This fixes issue #280 as well, just as the previous commit does, because it was
decided that that issue should be about two different things.
Signed-off-by: Uli Schlachter <psychon@znc.in>
When you run a mousegrabber, the C code calls this callback when the pointer is
moved or when a button is pressed/released. However, the button state is totally
bogus on press/release events, always claiming that the button that was
pressed/released is the only button that is pressed (even for release events!).
This commit fixes up the code so that the button state after the press/release
event is passed to the mousegrabber callback function.
Fixes: #280
Signed-off-by: Uli Schlachter <psychon@znc.in>
Forgot to commit the change that adds _NET_FRAME_EXTENTS to the list of atoms
that we actually query for and export to the C code.
Signed-off-by: Uli Schlachter <psychon@znc.in>
In #152 I've changed the autofocus handler to emit the request::activate
signal, instead of setting client.focus only.
This is wrong IMHO, and can be annoying:
If you have two floating clients above a tiled / maximized one, and
close one of the floating ones, with the tiled one being the one
selected by autofocus, it will be raised above the other floating
client.
This is changed now to use the new `request::focus` signal instead.
This basically reverts 20cdb5d (#152), but allows for customizing this
behavior, by overriding the default `request::focus` handler
(`ewmh.focus`).
It would be nice if there was a helper to check if a window's content
isn't visible at all (i.e. covered by other windows), and that could be
used then by the (new) default handler for request::focus - raising the
client only, if it's completely covered by another window.
Fixes https://github.com/awesomeWM/awesome/issues/217
This still does `client.focus = c` by default, but allows to customize
it.
This was initially suggested in #194, but by using `request::activate`
instead, which would not be the same. Therefore a new signal is being
used instead.
Helped-by: Samir Benmendil <samir.benmendil@gmail.com>
This way "that other widget" doesn't prevent the current widget from being
garbage collected.
Please note that this in all of these cases the widget under consideration does
have a strong reference to the callback function. This means that the callback
cannot be garbage collected until "this widget" itself is collected. Thanks to
this, this change is safe.
Signed-off-by: Uli Schlachter <psychon@znc.in>
Connecting to a signal weakly has the same effect as connecting to it strongly,
but it allows the garbage collector to disconnect the signal in case nothing
else references this function.
Signed-off-by: Uli Schlachter <psychon@znc.in>
Emmanuel Lepage Vallee
Daniel Hahler
Daniel Hahler
bjp
Uli Schlachter
actionless