When a window is moved, it should be sent a synthetic ConfigureNotify describing
its new position. This also documents why we send a synthetic event if nothing
was changed in response to a ConfigureRequest.
Signed-off-by: Uli Schlachter <psychon@znc.in>
When a client is unmanaged, we destroy our frame window. But since the client's
own window was still a child of the frame window, it was destroyed, too. This
commit fixes this by reparenting the client's window back to the root window
first.
Signed-off-by: Uli Schlachter <psychon@znc.in>
ICCCM mandates that window managers have to trigger the conversion to withdrawn
state on the synthetic and the real unmap notify, no matter if any is missing.
Previously we couldn't do this, but thanks to the reparenting, we can now do
this properly.
Signed-off-by: Uli Schlachter <psychon@znc.in>
This splits up client_getbywin() into two different functions. One of them finds
a client by its frame window, the other checks against the client's own window.
Signed-off-by: Uli Schlachter <psychon@znc.in>
Each window is now reparented under a window created by awesome. This window is
NOT visible, this commit should not cause any visible differences. Instead, this
is done to work around problems with X11.
The only alternative would be to ban windows by moving them offscreen which is
ugly in itself and breaks pagers. Doing it like this seems to be the better
solution.
Signed-off-by: Uli Schlachter <psychon@znc.in>
We no longer use libxcb-event, so we don't have to follow it's API any more.
This means the pointless arguments and return values can be removed.
Signed-off-by: Uli Schlachter <psychon@znc.in>
Upstream removed most of the code from libxcb-event and there is no
event-related stuff left in this library. We now no longer use any of the parts
that were removed.
Signed-off-by: Uli Schlachter <psychon@znc.in>
This commits makes awesome remove systray windows from the save set when they
are unmapped. This happens for the same reason as with normal client windows.
Signed-off-by: Uli Schlachter <psychon@znc.in>
This will store the widgets references that the wibox have inside their
environment table, and not in the global registry, avoiding memory leaks.
This should fix FS#771.
Signed-off-by: Julien Danjou <julien@danjou.info>
Second try:
Turns out I messed up with XCB_EVENT_SENT() and had a "!" too much. The old code
already tried to cope with this, but forgot to actually unmap the window which
it just set to withdrawn state.
This time I tested the patch *again* and now I found even less bugs than on my
last try.
P.S.: I suck.
Signed-off-by: Uli Schlachter <psychon@znc.in>
Signed-off-by: Julien Danjou <julien@danjou.info>
According to the Inter-Client Communication Conventions Manual, if you want to
switch your window to withdrawn state, you unmap it and send a synthetic
UnmapNotify to the root window.
This synthetic event fixes a race condition. When you map and unmap a window
quickly, the map will generate a MapRequest for the WM but won't actually map
the window. Thus, the unmap will be discarded (-> window not yet mapped) and the
window stays map once the WM handles the MapRequest
Before this patch, awesome just ignored the synthetic unmap notify which caused
the bug to appear again. With this patch it doesn't happen anymore.
Signed-off-by: Uli Schlachter <psychon@znc.in>
Signed-off-by: Julien Danjou <julien@danjou.info>
This changes wibox_t::mouse_over to a proper reference. That way one can't
remove that widget from underneath us which would lead to an unprotected lua error.
Signed-off-by: Uli Schlachter <psychon@znc.in>
Signed-off-by: Julien Danjou <julien@danjou.info>
Wiboxes are lazily updated. This means that we could receive an expose event on
them between making them visible and actually painting their content.
Due to this we were copying undefined content to the wibox, because the pixmap
was only created just now, but it wasn't actually filled with anything yet.
Signed-off-by: Uli Schlachter <psychon@znc.in>
Signed-off-by: Julien Danjou <julien@danjou.info>
This avoid the problem we can had while modifying globalconf.keys in a
callback function from a key or button event. Now we push all matching
objects on the stack, and call each callback function. If something
modify globalconf.keys, we do not care.
Signed-off-by: Julien Danjou <julien@danjou.info>
This variable didn't really have any effect on anything. It was only ever
checked in a function that would never be called if this flag was false.
Signed-off-by: Uli Schlachter <psychon@znc.in>
Signed-off-by: Julien Danjou <julien@danjou.info>
Uli Schlachter
Julien Danjou