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>
If c->honor_size_hints is set to false and the client indicates through
its hints that it wants to be fixed size (by setting min and max width
equal), size hints are not ignored due to client_isfixed not taking
honor_size_hints being false into account. This commit fixes that.
Signed-off-by: Gregor Best <gbe@ring0.de>
Signed-off-by: Julien Danjou <julien@danjou.info>
This fixes problem with Qt 4.6.
Our implementation cannot be standard, and was not standard, so just
stop using this EWMH crap.
Signed-off-by: Julien Danjou <julien@danjou.info>
There is a push 15 lines before the push that is removed here, but the client
that is pushed there was never popped. Bad.
Fix this by letting luaA_class_emit_signal() do the needed pop for us.
Signed-off-by: Uli Schlachter <psychon@znc.in>
Signed-off-by: Julien Danjou <julien@danjou.info>
This makes imlib add images loaded from files to its image cache again. That way
we avoid loading the same image again and again (e.g. if you cycle through the
list layouts all the layout icons are loaded).
To not reintroduce FS#651 (fixed in 2dadce9b), we call
imlib_image_set_changes_on_disk(). This causes two stat() calls if the same file
is loaded again to check if the file's timestamps changed which is still less
expensive than loading the whole image again.
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>
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>
Julien Danjou
Gregor Best
Uli Schlachter
Lukas Hrazky