These warnings might help catching some problems in the future. These
could be asserts, but printing a warning is a lot nicer than dying.
Signed-off-by: Uli Schlachter <psychon@znc.in>
X11 does not allow to resize a window to size 0x0. Also, there are some
possibilities of integer overflows in our case. We tried to handle this
already, but there was a loop-hole: If the too-small-value is only
produced after applying size hints, then this was not caught.
Fix this by applying size hints before checking if the resulting size is
valid. However, this means some check needs to be duplicated to handle
the possibility of integer underflows while applying size hints.
Helps-with: https://github.com/awesomeWM/awesome/issues/1340
Signed-off-by: Uli Schlachter <psychon@znc.in>
The code in luaA_client_swap() is incorrect, because
luaA_object_emit_signal() already pops the arguments to the signal.
Still, the code here tried to remove the arguments from the Lua stack
again, thereby corrupting the stack (removing more items than there are
in the stack).
Normally, popping more things from the stack than it has entries
silently corrupts the Lua stack. Apparently this doesn't necessarily
cause any immediate issues, because this code has been broken since nine
months and no one noticed. This mistakes was introduced in commit
55190646.
This issue was only noticed by accident. Thus, this commit also adds a
small integration test that exercises this bug. This test catches the
issue, but only on Travis, because there we are building our own version
of Lua 5.3 and that one has assertions enabled.
Signed-off-by: Uli Schlachter <psychon@znc.in>
It does not provide much value. The version number is already known to
ldoc globally in the "description" variable.
Signed-off-by: Uli Schlachter <psychon@znc.in>
Daniel sees a short flicker of his wallpaper when he closes a client.
This happens because the window is destroyed immediately, but other
clients are re-arranged only shortly later. In the mean time, the X
server updates the display and repaints the root window (= wallpaper
becomes visible).
Work around this by delaying the destruction of frame windows to the end
of the current main loop iteration. This means that we first update the
position of all other windows and later destroy the window that was
actually closed.
Signed-off-by: Uli Schlachter <psychon@znc.in>
There are some situations where we do things that can make the mouse pointer
enter another window. We do not want to react to these "self inflicted" mouse
enter and leave events, because they aren't "real" (= generated by the user).
Before this commit, this is done by going through all windows and toggling the
"please send us enter and leave events"-bit on them. This becomes slower when
many windows are visible and floods the server with requests.
This commit changes this to a constant-time logic. Each event contains the
sequence number of the last request that the X11 server handled. Thus, we just
remember the right sequence numbers and ignore any events that comes in whose
sequence number falls into the ignored range.
In detail, we keep a list of "begin" and "end" sequence numbers and ignore any
enter and leave events that fall in this range. If we get any event with a
sequence number higher than "end", we remove this pair from the list, since it
is no longer needed.
To generate these pairs, we use a GrabServer request in
client_ignore_enterleave_events(). This gives us a sequence number and makes
sure that nothing else besides us can cause events. The server is ours! In
client_restore_enterleave_events(), we first do a NoOperation request to
generate the sequence number for the end of the pair and then do UngrabServer.
Any event that is generated after UngrabServer will have at least the sequence
number of the UngrabServer request and thus no longer fails between begin and
end.
Fixes: https://github.com/awesomeWM/awesome/issues/1107
Signed-off-by: Uli Schlachter <psychon@znc.in>
This commit makes the function only call client_ignore_enterleave_events() when
it actually has to. Since we expect that most of the time, no client's geometry
is changed, this means that most of the time this function is not called.
Fixes: https://github.com/awesomeWM/awesome/issues/1107
Signed-off-by: Uli Schlachter <psychon@znc.in>
This should "protect" the user from some stupidities that Lua code might be
doing that e.g. makes a client jump to another position and then immediately
back to where it was before. Only the last change in a single main loop
iteration will actually have any effect.
Original idea by Daniel here: https://github.com/awesomeWM/awesome/pull/174
Signed-off-by: Uli Schlachter <psychon@znc.in>
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>
Instead of computing the workarea whenever some Lua code asks for it, it is now
remembered explicitly as a property on a screen. This allows us to only emit
property::workarea if the workarea actually changed.
Fixes: https://github.com/awesomeWM/awesome/issues/756
Signed-off-by: Uli Schlachter <psychon@znc.in>
Apparently the spec allows to set the _NET_STARTUP_ID value on the property that
WM_CLIENT_LEADER points to instead of the window itself. Thus, if we don't find
a _NET_STARTUP_ID on the window itself, check again on the client leader window.
Apparently GTK even does this (for whatever reason...)...
Signed-off-by: Uli Schlachter <psychon@znc.in>
Remove request::fullscreen and request::maximized_* and use
a single request for them. The other client resizing features
will soon also start to use this.
In the case where one want to put the cursor at the middle of the
workarea, it is logic to do:
x=screen.workarea.x+screen.workasrea.width/2
However, this can cause floating points. This commit move the
burden back to the C-API so the Lua placement code doesn't have
to add a large number of rounding methods. Given 1 type of rounding
cover a vast majority of use cases for each types of coordinates,
the C-API can take care of it in peace. For the other corner cases,
it is still possible for the Lua code to do the rounding there, but
no longer necessary. The convenstions are:
'x' and 'y': use round (move to the closest point)
'width' and 'height': use ceil (to avoid involontary truncating)
This change catches things like c:geometry { width = -42 }.
Helps-a-bit-with: https://github.com/awesomeWM/awesome/pull/820 (fixes X errors)
Signed-off-by: Uli Schlachter <psychon@znc.in>
Instead of focusing the root window, we now create a "focus window" inside of
our frame window. This window is placed so that it is not visible, but we can
grab key bindings on it to simulate the window having the input focus.
Fixes: https://github.com/awesomeWM/awesome/issues/699
Signed-off-by: Uli Schlachter <psychon@znc.in>
Even when a screen is just an integer, the code becomes a bit more
self-documenting. Even better, if we start to handle screen objects to Lua
instead of screen indicies, there will only be one place that needs to be
changed.
Signed-off-by: Uli Schlachter <psychon@znc.in>
When we manage the transient before the main window, the client object's
.transient_for property would stay nil. This happens because the property points
to a window which we don't know (yet) and thus is ignored.
Fix this by remembering the value of WM_TRANSIENT_FOR and checking in
client_manage() if the new client is the "missing window we did not find
before".
Fixes: https://github.com/awesomeWM/awesome/issues/181
Signed-off-by: Uli Schlachter <psychon@znc.in>
This creates a new helper function for setting the transient_for property of a
client. This is a preparation for a following commit. No behaviour changes
intended.
Signed-off-by: Uli Schlachter <psychon@znc.in>
To quote from ICCCM (§4.1.2): "The window manager will not change properties
written by the client."
We tried to do this anyway to update WM_HINTS so that the current urgency state
is reflected. Apparently, Chrome does a similar read-modify-set cycle and the
resulting race condition meant that the "accepts input" hint on Chromium's
window was permanently disabled.
This helps with https://github.com/awesomeWM/awesome/issues/670, but I still
think that Chrome shouldn't try to implement "please don't focus me when I do
the following" by temporarily claiming "please don't ever focus me".
Signed-off-by: Uli Schlachter <psychon@znc.in>
ICCCM specifies when the WM has to send a ConfigureNotify. Java does not care
and wants one all the time. Meh.
Fixes: #248
Signed-off-by: Uli Schlachter <psychon@znc.in>
Luke Bonham
Vitja Makarov
Uli Schlachter
Daniel Hahler
Daniel Hahler
Uli Schlachter
Emmanuel Lepage Vallee
blueusername