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>
This reverts commit 7575f64993.
As seen on ML:
Switching tags with multiple heads causes focus to change
screens with this commit
Signed-off-by: perry <perry.hargrave@gmail.com>
Signed-off-by: Julien Danjou <julien@danjou.info>
We check the wibox border width for inappropiate values now, if we set
border_width to a negative value (invalid) in our theme and draw it, the
actual border_width will be 0 so the menu will be drawn incorrectly.
This fixed this.
Signed-off-by: Hiltjo Posthuma <hiltjo@codemadness.org>
Signed-off-by: Julien Danjou <julien@danjou.info>
There might be multiple screens with visible windows. When closing the
last window of the current screen, try to focus them as well.
If no window has focus and yet some windows are visible (e.g. on another
screen), awesome misbehaves: it uses sloppy keyboard focus (as is the X11
default), but doesn't refresh their border colors or tasklists etc.
Signed-off-by: Tomi Belan <tomi.belan@gmail.com>
Signed-off-by: Julien Danjou <julien@danjou.info>
wibox_set_border_color() and luaA_wibox_set_border_width() didn't check if a
wibox really had an associated X11 window before changing this window which
resulted in (silent) errors.
Signed-off-by: Uli Schlachter <psychon@znc.in>
Signed-off-by: Julien Danjou <julien@danjou.info>
Function set_geometry was never called if the timer_function argument
was omitted. show function only called place() which would not display
a tooltip since it didn't have proper geometry.
Signed-off-by: Adrian C. (anrxc) <anrxc@sysphere.org>
Signed-off-by: Julien Danjou <julien@danjou.info>
If you change the .bg of an existing wibox which isn't attached to any screen
yet, then there is no window for which we can update the XCB_CW_BACK_PIXEL.
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>
After the last patch, after each resize the X server fills the complete wibox
with its background color which means that the widgets will still flicker. This
patch fixes this by setting the wibox' bit gravity to NorthWest.
This means that if a wibox is enlarged, only the new, larger part will be filled
with the wibox' background color and the rest of the wibox' content will be left
intact. With this patch I couldn't see any flickering anymore.
Signed-off-by: Uli Schlachter <psychon@znc.in>
Signed-off-by: Julien Danjou <julien@danjou.info>
Currently wiboxes have their background set to "inherit parent pixmap". That
means that each time a wibox is e.g. resized, the X server sets the wibox'
content to the wallpaper and then immediately awesome redraws the wibox with the
proper background. This causes flicker when you e.g. resize clients which have a
titlebar.
With this patch, wiboxes get their proper background color for their "back
pixel" value. Now, instead of showing the wallpaper, the X server will fill the
complete wibox with its background color.
With this patch, the actual widgets will still flicker. Also, if the wibox has a
background image, this image obviously won't be used by the X server and we get
some flicker again. My next patch will address these issues.
Signed-off-by: Uli Schlachter <psychon@znc.in>
Signed-off-by: Julien Danjou <julien@danjou.info>
This kind-of-reverts 058dbab828.
If banning_refresh() is called, only the lua events that it generated before are
now generated (the unfocus event). The actual mapping and unmapping of X11
windows is defered until the end of the main loop via a new per-screen
need_lazy_banning flag.
Signed-off-by: Uli Schlachter <psychon@znc.in>
Signed-off-by: Julien Danjou <julien@danjou.info>
client_ban_unfocus() generates the unfocus events that client_ban() would
generate, but it doesn't do the actual banning.
Signed-off-by: Uli Schlachter <psychon@znc.in>
Signed-off-by: Julien Danjou <julien@danjou.info>