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>
This patch fixes focus hooks calls - for every call to focus hook, there
should be call to unfocus hook.
Focus related info:
In this shape, awesome doesn't support multiple focused clients, that
means it follows the rule "there is only a single focus", which is not
true for MPX. To change this, I think it will need some magic with
FocusOut events handling and changes to some structures
(e.g. globalconf.screen_focus, screen_t.client_focus should be arrays) :p
Now we don't need to handle FocusOut events.
Signed-off-by: Mariusz Ceier <mceier@gmail.com>
Signed-off-by: Julien Danjou <julien@danjou.info>
We stop retrieving useless key, since we have constant.
We also grab correctly all keycode for a keysym.
Signed-off-by: Julien Danjou <julien@danjou.info>
Pretty much every single source file needs this struct, so it makes sense to
define it in a common header instead of in every single .c file.
Signed-off-by: Uli Schlachter <psychon@znc.in>
Signed-off-by: Julien Danjou <julien@danjou.info>
- We are tracking focus, using FocusIn/FocusOut events handlers, so user
should never be confused about which client has focus
- window_setfocus function generates focus change requests to the X server
- client_focus uses window_setfocus to set input focus
- revert_to when setting input focus set to Parent, compliant with
ICCCM convention ([1])
- DEBUG flag for those who want to debug focus handlers
Most of the changes, are compliant with X11 handbook ([0]), but some
where obtained experimentally.
Kudos to Maarten Maathuis who helped a lot with this.
[0]
http://cgit.freedesktop.org/xorg/doc/xorg-docs/plain/hardcopy/X11/xlib.PS.gz
[1] http://tronche.com/gui/x/icccm/sec-4.html#s-4.2.7
Signed-off-by: Maarten Maathuis <madman2003@gmail.com>
Signed-off-by: Mariusz Ceier <mceier@gmail.com>
Signed-off-by: Julien Danjou <julien@danjou.info>
Cheers,
Alex
From b5816ec55073507d4527ad3a77eae1878adb30d3 Mon Sep 17 00:00:00 2001
From: Alex Cornejo <acornejo@gmail.com>
Date: Sun, 29 Mar 2009 14:24:27 -0400
Subject: [PATCH] Fixed some styling issues.
Noticed in the latest pull that a commit introduced a lot of styling
inconsistencies, decided to remove those and others found by a simple
grep.
Signed-off-by: Alex Cornejo <acornejo@gmail.com>
Signed-off-by: Julien Danjou <julien@danjou.info>
Version 1 was supposed to store somehow the mouse coordinates to drop
spurious EnterNotify.
Now, we use a simpler way: we just tell the X server we do not want to
receive this events while we are arranging, since we would get spurious
ones.
Signed-off-by: Julien Danjou <julien@danjou.info>
We stop grabbing buttons on root windows. We select button press and
release events, and then we check that we have a bindings for them.
This allow to simply grab buttons on client once, and not redo such
things on arrange or mouse-over-window changes.
Most window managers do like this, anyway.
Signed-off-by: Julien Danjou <julien@danjou.info>
We need to handle FocusIn event to update focused client, when client
with GAIM sends SetInputFocus message (that is FocusIn event for WM).
Signed-off-by: Mariusz Ceier <mceier@gmail.com>
Signed-off-by: Julien Danjou <julien@danjou.info>
This should fix the problem seen with Firefox. When clicking on a
file that will launch a "Save as" dialog, and switching tag quickly,
the client is banned and move off of the viewport.
Then FF send a ConfigureRequest to re-move it to this negative
coordinates, which we did handle and set as its geometries.
Now we just honor the (bad and useless) move but we do not use
client_resize()
Signed-off-by: Julien Danjou <julien@danjou.info>
ConfigureRequest are sent with real X windows size, not fake size with
border and titlebar.
So we need to re-add size of borders and titlebar before calling
client_resize(), otherwise we set a X size the client can considers wrong
and then we start loopin forever since we do not handle its request to
be sized correctly.
Signed-off-by: Julien Danjou <julien@danjou.info>
Uli Schlachter
Julien Danjou
Mariusz Ceier
Maarten Maathuis
Alex Cornejo
Gregor Best