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>
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>
Why:
* Two different (but related) concepts had the same name
* Users were confused for years on IRC
* The wibar name was already in use in some doc to avoid confusion
Commit 7dad0b3b87 made awesome only ask for mouse events on the actual
client window. Obviously, this means that we no longer get reports for clicks on
the titlebar. Whoops.
Fix this by asking for mouse events on *both* the actual client window and the
frame window. The passive grab on the actual client window is actually unneeded,
but we keep it so that the fix that was done by the above commit is still
present (xev will no longer report leave/enter events just for a mouse click).
Since we now get mouse events inside of a client reported twice, the event
handling code in event.c has to be fixed to handle both cases. E.g. x/y are
relative to the top-left corner of the window and thus needs to be fixed for
titlebar size; the second click has to be ignored.
Signed-off-by: Uli Schlachter <psychon@znc.in>
EWMH specifies that
If _NET_WM_WINDOW_TYPE is not set, then managed windows with WM_TRANSIENT_FOR
set MUST be taken as [_NET_WM_WINDOW_TYPE_DIALOG].
We implement this by forcing a window's type to be "dialog" when it has a
WM_TRANSIENT_FOR property. For windows that have a _NET_WM_WINDOW_TYPE property,
this type change is then later undone. However, when a window changes its
WM_TRANSIENT_FOR property during runtime, then we would set its type to "dialog"
unconditionally.
This commit fixes this by explicitly tracking if we found a _NET_WM_WINDOW_TYPE
property on the window and only applying the fallback if we did not find such a
property.
Fixes-one-of-the-sub-issues-from: https://github.com/awesomeWM/awesome/issues/889
Signed-off-by: Uli Schlachter <psychon@znc.in>
Commit 8a6787bd54 added screen.fake_add(). Commit 08845c7a4b made us cache a
screen's workarea in the struct screen_t. This new member needs to be
initialized to the screen's geometry when a new screen is added. Since both
these commits were developed concurrently, the workarea was not initialized in
screen.fake_add().
Fix this by calling in fake_add() the helper function added in 08845c7a4b.
Signed-off-by: Uli Schlachter <psychon@znc.in>
Since commit 102063dbbd, awesome is a reparenting WM. That means that we put our
own frame windows around child windows. This means that we have the option of
grabbing input events on the frame window or the child window. This commit chose
the frame window for this.
For keyboard events, this decision was already reverted in 532ec0cd90. This
commit does the same thing for mouse events.
This fixes the spurious leave/enter events that were visible on mouse clicks.
They occurred because the click activated a passive grab (all mouse events now
"belonged" to awesome). This passive grab caused the X server to inform clients
that they "lost" the mouse pointer (with the detail field set to "a grab
activated").
Fixes: https://github.com/awesomeWM/awesome/issues/427
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>
Daniel Hahler
Daniel Hahler
Uli Schlachter
Uli Schlachter
Emmanuel Lepage Vallee
blueusername
Mikhail Schemelev