I cherry-picked this commit from master and there was a conflict. I fixed this
up by hand and apparently failed here.
Instead of first saving the systray window and then destroying the wibox, this
first destroyed the wibox and then tried to save the systray, but it was already
destroyed in the previous step. Just swapping these two calls fixes this.
Thanks to anrxc for making me notice how much I fail.
Signed-off-by: Uli Schlachter <psychon@znc.in>
When a wibox is destroyed or detached from a screen, it is wiped to clean up its
resources. This also includes destroying the window which is associated with the
wibox.
The problem here is that if the wibox contains the systray, the systray window
would automatically be destroyed since all childs of a window are destroyed when
said window is destroyed. To fix this, we kick out the systray window before
destroying the wibox' window.
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>
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>
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>
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>
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>
Some functions didn't check the class of objects they were passed but just
casted them to the type they expected. This lead to code like e.g. the following
to crash awesome:
c.titlebar = c
This adds a new function luaA_object_ref_class() which works like
luaA_object_ref(), but which also checks the class of the object.
Additionally, this function is now used in all necessary places.
Signed-off-by: Uli Schlachter <psychon@znc.in>
Signed-off-by: Julien Danjou <julien@danjou.info>
luaA_object_ref_item doesn't check the type of object it returns which resulted
in stuff like this:
wibox.shape_clip = wibox
wibox.shape_bounding = wibox
imagebox.image = imagebox
textbox.bg_image = textbox
All of the above calls would result in a crash (unverified) and all of them
where fixed.
This should fix all places which use luaA_object_ref_item(). The others already
did a proper type check.
Signed-off-by: Uli Schlachter <psychon@znc.in>
Signed-off-by: Julien Danjou <julien@danjou.info>
We use lua_class_t pointer as key in the registry to store metatable we
will compare.
lauxlib uses a string, which sucks, because it forces to do a
pushliteral() each time you want to get a metatable from the registry,
which is slower.
Signed-off-by: Julien Danjou <julien@danjou.info>
When the SHAPE extension is not available, this code prints
a harmless warn() on stderr.
Signed-off-by: Uli Schlachter <psychon@znc.in>
Signed-off-by: Julien Danjou <julien@danjou.info>
Before this, setting w.opacity of a wibox that was not attached to some screen
had no effect, now this is cached and applied when the wibox is attached to
some screen.
Signed-off-by: Uli Schlachter <psychon@znc.in>
Daniel Graña
Uli Schlachter
Julien Danjou
Brian Gianforcaro