The current taglist/tasklist allow filter function to remove elements
from the list. However they don't allow sorting or additional entries
to be listed.
This commit introduced such a concept. It will later be used by the
layoutlist where it becomes more relevant since layouts are used created
"objects".
This property is based on Motif WM hints and checks if the client
requests that it is not decorated with a titlebar.
Signed-off-by: Uli Schlachter <psychon@znc.in>
Commit fec8d6aa8f fixes awful.placement.no_offscreen to behave
like other placement functions. This means that the margins=40 argument
that this test used and that was previously was just ignored, now
started working. Thus, there are now 40 pixels less on each side of the
client in this test.
Signed-off-by: Uli Schlachter <psychon@znc.in>
When poll() is interrupted because of a signal, it sets errno to EINTR.
GLib ignores this kind of failure.
However, a_glib_poll() calls a_xcb_check() at its end. This will call
xcb_poll_for_event() which internally might call recv(), which can fail
with EAGAIN if no new events are available. Thus, a_glib_poll() will
return an error and set errno to EAGAIN. This leads to the following
error message being printed by GLib:
GLib-WARNING: poll(2) failed due to: Resource temporarily unavailable.
Fix this by preserving the errno from g_poll() in a_glib_poll().
Signed-off-by: Uli Schlachter <psychon@znc.in>
GLib is very careful not to "fetch" any children that it was not asked
to fetch. Thus, if awesome inherits some children, it does not reap them
and starts collecting zombies.
Thus, this commit makes awesome handle SIGCHLD directly: On SIGCHLD, a
byte is written to a pipe. The main loop reads from this pipe and
collects children via waitpid(-1). Unknown children cause a warning to
be printed. We might want to remove this warning if it turns out to be
annoying.
This commit adds 79 lines and removes 89 lines. Thus, this is a net
reduction in lines of codes. This is because previously, we gave the
list of still-running children that we know about to the next awesome
instance we a --reap command line argument. This was added so that
awesome does not get zombie children. However, this commit fixes this
problem and makes all the code for this 'feature' unnecessary.
Fixes: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=886393
Signed-off-by: Uli Schlachter <psychon@znc.in>
c->size_hints.win_gravity only contains something valid if the
XCB_ICCCM_SIZE_HINT_P_WIN_GRAVITY bit is set in the flags. Most likely
this wasn't noticed before, because most code just happens to
zero-initialize this field and gravity 0 is NorthWest, which does not do
anything.
Signed-off-by: Uli Schlachter <uli.schlachter@informatik.uni-oldenburg.de>
The function window_set_border_width() causes its own gravity handling.
Thus, to make sure that this gravity handling does not interfere with
what the code in here does later, we just apply changes to the border
width first, and then do everything else.
Signed-off-by: Uli Schlachter <uli.schlachter@informatik.uni-oldenburg.de>
Before this commit, the code in here first handled clients changing its
x/y position and afterwards it handled resizes. This meant that the
special case of "client resizes without moving itself so we need to
apply gravity" had to have special checks on whether the client moved
itself or not.
Change the code so that resizes are handled first and moves later. This
naturally handles the problem: If the client resizes and moves itself,
the move done for the resize is later overwritten when the move is
handled.
No functional changes are intended.
Signed-off-by: Uli Schlachter <uli.schlachter@informatik.uni-oldenburg.de>
When an icon is sent over dbus, we turn this into a cairo ImageSurface.
This is done by turning the actual icon data into a string and using
cairo.ImageSurface.create_for_data() to create a surface for this data.
However, this function only creates an ImageSurface that refers to this
data. It does not copy the data. Thus, when the Lua GC later frees the
string, we have a cairo surface that refers to already-freed data.
Fix this by duplicating the cairo surface, which makes cairo create a
copy of the data. Then, we finish the original surface. While doing
this, the string is kept alive in a local variable.
(Possibly) Fixes: https://github.com/awesomeWM/awesome/issues/2361
Signed-off-by: Uli Schlachter <psychon@znc.in>
Some window gravities require a division by two. Up to now,
test-gravity.c expected this division to always be rounded up. This
commit changes the code to also allow rounding down.
Signed-off-by: Uli Schlachter <psychon@znc.in>
Previously, this function overwrote the value of its argument with the
result. After this change, the function merely changes the given
variable by the calculated argument.
Thus, the old behaviour is achieved by setting the variable to zero
before the call, which all callers already did. However, for most
callers this change means that a temporary variable can be removed and
instead xwindow_translate_for_gravity() will directly change the target
variable.
No change in behaviour intended.
Signed-off-by: Uli Schlachter <psychon@znc.in>
When a tag is specified by name, awful.rules only searched for the tag
on the client's screen. This commit extends the search to all screens,
but only if no specific screen was specified for the new client by some
rule.
Signed-off-by: Uli Schlachter <psychon@znc.in>
There are two ways in which the input focus can change: Lua can request
a change and the X11 server can inform us that the input focus changed
(because some application changed it).
In the first case, we still have to inform the X11 server about the
desired change, in the second case we must not to avoid races due to
X11's asynchronous nature.
However, there was a case where we screwed up: When a focus change is
still pending, meaning that Lua assigned the focus elsewhere, but we
have not yet sent this focus change to the X11 server, we could get an
event from the X11 server telling us that the focus changed. To make
sure that the pending focus change is not lost, we sent the focus change
out in this case (call to client_focus_refresh() in
event_handle_focusin()). After sending out this pending call, we updated
the internal state to record that whatever the X11 server just told us
had the focus. The intention was that our just sent-out focus change
will cause the X11 server to send a new event and our to-be-focused
client then has the focus.
However, if the pending focus change was for a client which only showed
up in this event loop iteration, the client was still banned. This means
that client_focus_refresh() would call client_unban() to be able to give
the focus to this client. However, since awesome (partly) allows to
"focus" currently banned clients, client_unban() recorded that there is
a pending focus change. This caused confusion later on.
In this specific bug, a main window opened a dialog, and when this
dialog was closed, a new dialog window was opened immediately. When the
first dialog was closed, Lua (the focus history) gave the input focus to
the main window. Now, a new dialog showed up and Lua focused it. Next,
we received the event from the X11 server telling us that the main
window was focused. Because there was still a pending focus change to
the new dialog window, event_handle_focusin() called
client_focus_refresh() to send out this focus change. This set
globalconf.focus.need_update to false and continued. However, because
the new dialog only just now appeared, it was still banned, meaning that
client_focus_refresh() had to call client_unban(). This set
globalconf.focus.need_update to true. Thus, when client_focus_refresh()
returned, globalconf.focus.need_update was incorrectly true. Next,
event_handle_focusin() recorded that the main window had the focus.
Thus, it now appeared as if there was a pending focus change for the
main window. Next, we got the event from the X11 server telling us that
the dialog is now focused, and because focus.need_update was set,
awesome now send out a focus change request for the main window.
Fix this race by unsetting globalconf.focus.need_update at the end of
client_focus_refresh() and not at the beginning, thus making sure that
client_unban() cannot set this flag again.
Fixes: https://github.com/awesomeWM/awesome/issues/2220
Signed-off-by: Uli Schlachter <psychon@znc.in>
The typo was introduced in commit a1941efc9.
Its effect should be minimal: :item_enter() itself does not care about
the 'mouse' option, but it forwards to :exec(). Here, an action is
invoked either if it was not caused by the mouse, or if it was caused by
the mouse and either auto_expand is enabled (which is the default), or
the item-to-be-executed is actually the active item.
In other words, it is quite non-trivial to come up with a case where
this typo made a difference. But of course that's no reason to leave the
typo in.
Fixes: https://github.com/awesomeWM/awesome/issues/2347
Signed-off-by: Uli Schlachter <psychon@znc.in>
When a window has a WM_TRANSIENT_FOR property that is later unset,
awesome would still keep c.transient_for pointing to the previous
"parent client". This commit fixes that.
First, property_update_wm_transient_for() is fixed so that it unsets
c->transient_for_window if the WM_TRANSIENT_FOR property is deleted.
Additionally, this then calls client_find_transient_for() to update the
c->transient_for pointer.
Secondly (and a bit unrelated), this changes client_find_transient_for()
so that it always sets c->transient_for. Previously, if updating this
property would introduce a cycle in the transient_for relation, it would
just leave c->transient_for with its old value. After this change, it
gets explicitly set to NULL instead.
Signed-off-by: Uli Schlachter <psychon@znc.in>
The old keygrabber API wasn't doing what the users want from a
keygrabber module. With tons of boilerplate code, everything could
be done, but it wasn't trivial.
This commit add a default grabber function that implements the
keybinding API already used by `awful.key` and `awful.prompt`.
It also add syntax candy left and right to make the module "feel"
like a native CAPI object.
Nothing is perfect and some parts, like adding root keybindings, are not
vevy pleasing. However it fulfill its goal when it comes to make
previously non-trivial use case very easy to implement and deploy.
Emmanuel Lepage Vallee
Uli Schlachter
mergify[bot]
Yauhen Kirylau
Peter Kasza
Uli Schlachter
Mak Kolybabi