The last commit moved the handling of floating wiboxes into its own function,
so the checks for floating wiboxes in here can be removed.
Signed-off-by: Uli Schlachter <psychon@znc.in>
Floating wiboxes are much easier to handle, so they deserve their own
function.
This function, wibox_position_update_floating() does exactly the same things
wibox_position_update() did before. No behaviour change involved.
Signed-off-by: Uli Schlachter <psychon@znc.in>
This moves the call to wibox_draw() into wibox_map() which fixes garbage
being displayed if a wibox is made visible by setting its .visible.
Since wibox_draw() already calls simplewindow_refresh_pixmap(), that call is
dropped. Because wibox_need_update() just makes sure wibox_draw() is later
called, we can replace the call to wibox_draw() by this call. This should avoid
superflous updates.
Found by lua code like this:
local w = wibox({ position = "floating", bg = "#ff0000" })
w.visible = false
w.screen = 1
<do some other stuff>
w.visible = true
Signed-off-by: Uli Schlachter <psychon@znc.in>
This moves some common code into a helper function to reduce code
duplication and open-coding that function all the time.
This commit doesn't cause any behaviour change at all.
Signed-off-by: Uli Schlachter <psychon@znc.in>
For a floating wibox which isn't visible, all what wibox_position_update()
does is setting the geometry fields in the simplewindow struct. Since the next
thing luaA_wibox_new() does is setting the wibox' geometry, this call makes
no sense.
Signed-off-by: Uli Schlachter <psychon@znc.in>
If a wibox's screen is set to nil, this is reflected by setting the screen
struct member to SCREEN_UNDEF.
SCREEN_UNDEF is defined as -1. If we allow such a wibox in
wibox_position_update(), bad things will happen (globalconf.screens[-1]).
Signed-off-by: Uli Schlachter <psychon@znc.in>
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>
This moves some common code into the new function wibox_need_update().
This patch is based on a patch from Julien Danjou.
Signed-off-by: Uli Schlachter <psychon@znc.in>
Signed-off-by: Julien Danjou <julien@danjou.info>
- WINDOW_TYPE_DOCK are chosen first.
- Top/Bottom take precedence over Left/Right.
- Struts are automatically updated.
- Automatically avoid overlap with other struts or wibox'es.
Signed-off-by: Julien Danjou <julien@danjou.info>
When creating a wibox the call to simplewindow_orientation_set() caused a
pixmap to be allocated, but the width and height weren't initialized yet.
Thus, awesome tried to create a 0x0 pixmap which the X server doesn't like.
This fixes the error and I haven't noticed any bad effects due to this patch.
Plus this should avoid some unneeded pixmap allocations. ;)
W: awesome: xerror:289: X error: request=CreatePixmap, error=BadValue
Signed-off-by: Uli Schlachter <psychon@znc.in>
Signed-off-by: Julien Danjou <julien@danjou.info>
- In many places i see people correcting for border width and titlebars.
- This new definition is the equivilant of what used to be fullgeometry.
- The internal geometry is now contained to a few functions that few people ever touch.
- This should avoid confusion and make code easier.
- Also protect against several unsigned overflows.
Signed-off-by: Maarten Maathuis <madman2003@gmail.com>
Signed-off-by: Julien Danjou <julien@danjou.info>
- From now on clients shall remain mapped for their entire lifetime.
- This should seriously boost tag switching speed with composite active.
- A lesser improvement may be noticed in non-composite situations.
- Titlebars that are set to invisble are still unmapped.
Since it would clutter the implementation and titlebars are cheap to render.
Not to mention that invisible titlebars are pretty rare.
- It's safe to attach titlebars while the client is banned.
- Titlebars are explicitly removed at exit.
Signed-off-by: Maarten Maathuis <madman2003@gmail.com>
Signed-off-by: Julien Danjou <julien@danjou.info>