Before this commit, do this:
c.maximize_hoizontal = true
c.maximize = true
c.maximize = false
assert(c.maximize_hoizontal)
Would not work because the states were not preserved individually.
This commit fixes that. Awesome wont be confused about it's own
state anymore.
This may seem pointless, but when it come to undoing these
maximizations, it was ambiguous.
Before 4.0, maximizing could only be done in 2 operations.
4.0 add an unified way, but kept doing 2 operations. The old
Lua EWMH code to serialize the 2 operations was dropped when
the codepath was simplified and replaced by a generic version
in awful.placement. However this version never implemented
combining multiple mementos into 1.
This commit unify the maximize C code, drop the ugly macro
template and actually fixes a couple more issues that were
caused because request::geometry was sent twice.
I explicitly did not add client_shape_input property since querying the
input shape of the client window seems useless to me.
Signed-off-by: Uli Schlachter <psychon@znc.in>
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>
We have many places where we are sending an XCB request and expect an
answer where the protocol guarantees that no error can occur and we are
sure to get an answer. However, for example if the X11 server crashes,
these places can still fail. This commit tries to handle failures at all
these places.
I went through the code and tried to add missing error checking (well,
NULL-pointer-checking) to all affected places.
In most cases these errors are just silently ignored. The exception is
in screen querying during startup. If, for example, querying RandR info
fails, we will fall back to Xinerama or zaphod mode. This is serious
enough that it warrants a warning. In most cases, we should exit shortly
afterwards anyway, because, as explained above, these requests should
only fail when our connection to the X11 server breaks.
References: https://github.com/awesomeWM/awesome/issues/1205#issuecomment-265869874
Signed-off-by: Uli Schlachter <psychon@znc.in>
Similarly to what we do with the client list, this signal is emitted
whenever the list of screens changes.
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>
This adds a tparam alias "@screen" for "@tparam screen" (when used to
document e.g. arguments for callbacks), and "@screen_or_idx" when a
function accepts a "screen" or "number".
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>
drawin_apply_moveresize() calls client_ignore_enterleave_events() internally,
because it also wants these to be ignored. This means that the code disables
enter/leave events twice and then enables them twice. This recursive disabling
is something that should not occur.
Fix this by having drawin_map() disable the events a bit later.
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>
Emmanuel Lepage Vallee
Uli Schlachter
sudo-nice
Luke Bonham
Holger Schurig
Uli Schlachter
SammysHP
Vitja Makarov
Ingo Bürk
Daniel Hahler
Daniel Hahler
blueusername