These events are generated when the mouse pointer moves between our
window and one of its child windows. For our purposes, this never counts
as an enter or leave, so just ignore these events completely.
Fixes: https://github.com/awesomeWM/awesome/issues/2560
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>
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>
XCB_CURRENT_TIME really should be avoided as much as possible (see
ICCCM).
However, the screen, mousegrabber and keygrabber code have cases where
they really want up-to-date information / want to activate a grab *now*.
These cases are fine with XCB_CURRENT_TIME since they are not related to
some events.
Signed-off-by: Uli Schlachter <psychon@znc.in>
This changes the xembed code so that the caller passes in a timestamp
that should be used instead of XCB_CURRENT_TIME.
Signed-off-by: Uli Schlachter <psychon@znc.in>
All we do with MappingNotify events is to print a warning. This is
because the XKB protocol specification says (§12.4):
Once a client requests XkbMapNotify events, the server stops
sending it MappingNotify events to inform it of keyboard changes.
However, as our test-keyboard-layout-changes.lua test shows, this is not
actually what happens. Instead, we seem to be getting both XkbMapNotify
and MappingNotify events.
Thus, just drop this print-a-warning-code.
Signed-off-by: Uli Schlachter <psychon@znc.in>
Xrandr provides new physical sizes in millimeters when sending a
RRChangeNotifyEvent, either to preserve DPI when monitors are added, or
to change DPI when a DPI change was requested. Keep track of the changes
so that our DPI information is always fresh.
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>
Since commit 4daa6e8, we are denying resizes and moves for embedded windows
(=tray icons). However, the Xembed spec says that the embedding client acts like
a WM (as specified by ICCCM) to the embedded window. Thus, when denying a
configure request, we have to inform the window by sending it a synthetic
configure notify. Otherwise, GTK seems to sometimes not draw its tray icon.
Fixes: https://github.com/awesomeWM/awesome/issues/986
Signed-off-by: Uli Schlachter <psychon@znc.in>
The XEmbed protocol defines a special property that defines if the embedded
window wants to be visible or not. Up to now, awesome always ignored this entry
and instead behaved as if the bit was set. This commit makes it properly respect
the bit.
Testing done: None. No idea how. Apparently nothing really uses this bit,
because we didn't get bug reports about it yet.
Signed-off-by: Uli Schlachter <psychon@znc.in>
The Xembed specification states that the protocol ends by reparenting the
embedded window elsewhere while unmapping the window can be done without ending
the protocol.
This commit makes us follow this part of the spec.
Signed-off-by: Uli Schlachter <psychon@znc.in>
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>
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>
This commit adds a "removed" signal to screens. Together with the "added" signal
that we have since a while, this allows the C code to update the list of
available screens dynamically without needing to restart.
So far, this code received only minimal testing. So far, I don't have a nice
idea on how to easily test this...
Closes: https://github.com/awesomeWM/awesome/issues/672
Signed-off-by: Uli Schlachter <psychon@znc.in>
Xorg server from git[1] generates ConfigNotify event when monitor
configuration changes.
We handle the event, but only trigger required awesome_restart() if
screen size is changed. It's not what happens in case of monitor
configuration change.
Let's relax the condition and call awesome_restart() in response to all
ConfigNotify events to root window.
I'm not entirely sure that it wouldn't lead to superfluous restarts, but
I don't see an option.
[1] dbe8d03c42f0 ("randr: Send ConfigNotify when manual monitor list changes")
Signed-off-by: Kirill A. Shutemov <kirill@shutemov.name>
The code that claims to do what XRRUpdateConfiguration() would do was actually
wrong. That function does not send any requests to the X11 server, but it just
updates the local, in-memory state.
This commit makes us do the same: We update the size of the root window if it
changed. The code is directly inspired from the code in libXrandr.
Signed-off-by: Uli Schlachter <psychon@znc.in>
This commit copies part of what XRRUpdateConfiguration() would do. When the root
window is resized, we update the information that the X11 server sent to us when
we connected to it to contain the new size of the root window.
This is 50% ugly, but having our own copy of the root window size would be 51%
ugly, so it's better to write to the XCB-owned structure.
Right now this is all dead code anyway, because we restart anyway, but since the
goal is to get rid of that restart, this is a step in the right direction (e.g.
root.size() will automatically return the new size).
Signed-off-by: Uli Schlachter <psychon@znc.in>
This function needs the event numbers for events from some extensions. These are
assigned dynamically by the server. Right now, this is done by having a bunch of
static variables that are initialized when needed.
Refactor this to have a function event_init() instead that sets variable in
globalconf (where all of our state should be saved). Also, a preprocessor macro
is introduced to handle event dispatch which also looks a bit nicer.
Signed-off-by: Uli Schlachter <psychon@znc.in>
p_dup really only duplicates the given region of memory. It does not append a
zero byte. Thus, the string we are using here was not zero-terminated.
Fix this by just using lua_pushlstring() so that we do not have to worry about a
null terminating the string at all.
Signed-off-by: Uli Schlachter <psychon@znc.in>
This one actually uses the return value from the function (where's the
consistency?!), so the code is fixed to only pop the return value if there is
actually one.
Signed-off-by: Uli Schlachter <psychon@znc.in>
We called the keygrabber and told Lua we are expecting one return value, so Lua
will always get us one return value on the Lua stack. However, when an error
happens, nothing is pushed on the stack, but we still tried to pop the return
value. This corrupted the Lua stack.
The easiest fix is to just not ask for a return value that is not used anyway.
Not adding a test for this, because the test has to cause a Lua error which the
C code will then log to stderr and the test runner considers this a test
failure...
Fixes: https://github.com/awesomeWM/awesome/issues/735
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>
The only remaining calls are for a window's opacity and in the DBus type
handling. Everything else wants integers, not something with a comma.
Signed-off-by: Uli Schlachter <psychon@znc.in>
A quote from the XKeyboard specification:
The server notifies interested clients of keyboard map changes in one of two
ways. It sends XkbMapNotify to clients that have explicitly selected them and
core protocol MappingNotify events to clients that have not. Once a client
requests XkbMapNotify events, the server stops sending it MappingNotify events
to inform it of keyboard changes.
This commit moves the code that we had for handling MappingNotify events to the
place where we handle XkbMapNotify events. This might even fix some bugs where
parts of awesome continued to use old key binding "stuff"!
Signed-off-by: Uli Schlachter <psychon@znc.in>
When a client is unmanaged, we know emit mouse::leave on its titlebar before the
client object is invalidated, so that Lua can still work with it. Before, this
event was emitted only when we got a LeaveNotify from the X11 server.
Fixes: #620
Signed-off-by: Uli Schlachter <psychon@znc.in>
When there are multiple X11 screens (i.e. :0.0 and :0.1) for zaphod mode
style X setups, this triggers a refresh of focus when the instance
running on a particular root receives the mouse
Fixes https://github.com/awesomeWM/awesome/issues/599.
These fields were only ever written to since commit 19137a55c3.
This commit removes the fields and the code that sets them.
Signed-off-by: Uli Schlachter <psychon@znc.in>
In commit 532ec0cd, we started grabbing keys on the client window directly
instead of its parent window (the frame window). This commit fixes one place
which was overlooked back then.
Signed-off-by: Uli Schlachter <psychon@znc.in>
Before this, we grabbed the keys on the frame window. That meant we only got key
events for things that nothing else grabbed directly on the key window.
After this, we grab directly on the client window itself and so we "fight" with
everything else which wants to grab keys. I don't actually know how the winner
is decided... First come, first serve, the rest gets an error?
Signed-off-by: Uli Schlachter <psychon@znc.in>
This ensures that systray icons cannot resize themselves. We assign them some
size and they have to deal with what they get!
Fixes: https://github.com/awesomeWM/awesome/issues/487
Signed-off-by: Uli Schlachter <psychon@znc.in>
The previous commit added some variables and this commit makes the surrounding
code use these new variables as well.
Signed-off-by: Uli Schlachter <psychon@znc.in>
There is a client window C. Around this window, awesome adds a frame window F.
When the pointer is inside of C and then moves inside of F, we get a LeaveNotify
with detail=Inferior, but from our point of view, the pointer is still inside of
C, because F is contained in C.
Similarly, if the pointer is in F and moves to C, we get an EnterNotify with
detail=Inferior that we should ignore. However, for an EnterNotify the pointer
can now be inside of a titlebar, so this case has to be handled now.
The above explains the enter/leave behavior for clients. Let's now think about
titlebars: When the pointer moves from C to F, it cannot be in any titlebar any
more, so we must generate a leave event on that titlebar. Similar when the
pointer moves from F to C, but in this case we also have to figure out which
titlebar now contains the pointer.
This patch makes the code handle these events with detail=Inferior correctly.
Closes https://github.com/awesomeWM/awesome/pull/461.
Signed-off-by: Uli Schlachter <psychon@znc.in>
This adds a global variable that tracks the drawable that is currently under the
mouse cursor. This new variable is then used so that we get consistent behavior
for enter/leave signals. Such signals are now also generated when a MotionNotify
event tells us that the pointer is now in a different titlebar.
Before this, it was possible that we did not generate a leave event on a
titlebar since the LeaveNotify contains the cursor position after the leave and
we did not manage to figure out which titlebar was left.
Signed-off-by: Uli Schlachter <psychon@znc.in>
Uli Schlachter
Uli Schlachter
Emmanuel Lepage Vallée
BuildTools
Giuseppe Bilotta
Vitja Makarov
Uli Schlachter
Kirill A. Shutemov
Daniel Hahler
Cory Burgett
Kimball Thurston
Daniel Hahler