All windows which use globalconf.default_depth must also have a backpixel,
borderpixel and colormap set when they are created. Without this, all these
xcb_create_window() calls would fail when globalconf.default_depth is no longer
the screen's default depth.
Signed-off-by: Uli Schlachter <psychon@znc.in>
All the APIs that accept both an image and a cairo surface now only accept cairo
surfaces. Images are gone.
Signed-off-by: Uli Schlachter <psychon@znc.in>
The last commit caused some lua errors and reading a wibox' type property
didn't work. This should all be fixed now.
Signed-off-by: Uli Schlachter <psychon@znc.in>
While drawing the wibox, the C core builds up a list of widgets and their
associated geometry. This list consists of widget_node_t objects and is
constructed like this (This is from luaA_table2widgets()):
widget_node_t w;
p_clear(&w, 1);
w.widget = luaA_object_ref_item(L, idx, -1);
widget_node_array_append(widgets, w);
After we are done with this list of widget nodes, it is freed via
wibox_widget_node_array_wipe(). However, wibox_widget_node_array_wipe() passed
"&w" to luaA_object_unref_item() while it should have used "w.widget" (which is
what was returned from luaA_object_ref_item()). This made the unref fail and the
wibox was carrying around a reference to this widget forever. This was
effectively a memory leak.
Signed-off-by: Uli Schlachter <psychon@znc.in>
When setting a new widgets table, the wibox obviously should drop its reference
on the old widgets table.
Signed-off-by: Uli Schlachter <psychon@znc.in>
This commit makes it an error if an unknown signal is connected, disconnected or
emitted. All signals have to be added before they can be used.
Signed-off-by: Uli Schlachter <psychon@znc.in>
This makes awesome support only a single X11 protocol screen. If you are still
using zaphod mode, you can run multiple instances of awesome on the single
screens, e.g.:
DISPLAY=:1.0 awesome & DISPLAY=:1.1 awesome &
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>
Next commit will need this function and I wanted to make it clearer that no
changes where done to this function.
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>
Uli Schlachter
Julien Danjou
Daniel Graña