alloca() allocates stack space. The image that we were producing is possibly
huge which means that we were asking for e.g. 9MiB of stack space. This is not
really a good idea and caused crashes.
Fix this by using heap memory instead.
Signed-off-by: Uli Schlachter <psychon@znc.in>
Function imlib_create_cropped_image() from imlib2 doesn't initialize
buffer for new image, so if we use crop bounds bigger than original ones
we need to erase garbage from derived image.
This bug produced colorful pressed buttons (FS#516, FS#822).
Signed-off-by: Roman Kosenko <madkite@gmail.com>
Signed-off-by: Uli Schlachter <psychon@znc.in>
With this patch, we track the number of objects that are alive for any class.
This information can be accessed via class.instances()
For example:
print("wiboxes", wibox.instances())
print("widgets", widget.instances())
Signed-off-by: Uli Schlachter <psychon@znc.in>
If we called the widget layout for x widgets, but the layouts returned less
geometries than this, we silently ignored the left-over widgets. If the layouts
returned more geometries, we crashed.
Fix this by verifying that the number of widgets and the number of geometries
are equal. If they are different, we use the smaller of the two.
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>
It seems like with lots of bad luck, the garbage collector manages to "steal"
the table with the buttons right after we decided to use it. Evil collector!
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>
The data table is used to map objects (clients/tags) to the buttons associated
with them. This is done so that we don't have to re-create the button objects
each time this lists are updated.
The problem was that this weak-keyed table was never cleared, because the value
had a strong reference to the key (via the button's signal):
btn:connect_signal("press", function () b:emit_signal("press", o) end)
"o" is the key in the table and btn is reachable from the value. This prevented
the garbage collection of the key. Using a weak-keyed and weak-valued table
fixes this.
Signed-off-by: Uli Schlachter <psychon@znc.in>
WINDOW is a deprecated define which will be removed. We should be using
XCB_ATOM_WINDOW instead.
This is a follow-up to 5d0a81c8bf.
Signed-off-by: Uli Schlachter <psychon@znc.in>
Turns out there are files in themes/ which are still needed (e.g. the default
wallpaper and the layout icons).
Signed-off-by: Uli Schlachter <psychon@znc.in>
The current code used "if(MATCHES)" to decide if a path was inside the source
directory or the build directory. MATCHES uses regular expressions and so this
check failed miserably if the path contained any characters that have a special
meaning in regular expressions (e.g. "+").
Fix this by only using paths inside the build dir for the icons. All icons are
copied from the source dir to the build dir so that we can freely assume that
everything is inside the build directory.
Instead of trying to "transform" the existing paths from the source dir to the
build dir, we use "file(GLOB)"'s RELATIVE option that gives us relative path.
Together with the way "file(COPY)" interprets its arguments, that's all we need.
Signed-off-by: Uli Schlachter <psychon@znc.in>
The only string format for colors that we now support are #rrggbb and #rrggbbaa.
All other strings will cause errors.
Thanks to this, color_init_cookie_t can be removed. There won't be a request to
the X server for transforming named colors any more and so there won't be a
cookie. This means that color_init_reply() has to be removed, too.
Signed-off-by: Uli Schlachter <psychon@znc.in>
This adds a lua module for parsing colors. Named colors like "black" aren't
supported, but #rrggbb and #rrggbbaa colors do work.
Signed-off-by: Uli Schlachter <psychon@znc.in>
EWMH describes desktop windows like this:
"_NET_WM_WINDOW_TYPE_DESKTOP indicates a desktop feature. This can include a
single window containing desktop icons with the same dimensions as the screen,
allowing the desktop environment to have full control of the desktop, without
the need for proxying root window clicks."
An example for such a window is nautilus' virtual root window. Naturally, such a
window would always overlap with any given client, so awful.placement.no_overlap
just didn't do anything at all. The fix is to ignore such clients for placement
calculations.
Signed-off-by: Uli Schlachter <psychon@znc.in>
Currently, this code requires a compare functions to return either -1, 0 or 1.
Values outside of this range will result in endless loops. Fix this by using if
instead of switch() for the result of the compare function.
Signed-off-by: Uli Schlachter <psychon@znc.in>
The systray bases its extents on the size of the wibox that it is contained in.
No idea how this is supposed to work when the systray doesn't get the full size,
but in a vertical wibox, using <height of wibox> * <number of icons in systray>
certainly doesn't work for computing the size.
The fix isn't hard: Check the wibox' orientation when drawing and base our
calculation on its width if its orientation is different from East.
Signed-off-by: Uli Schlachter <psychon@znc.in>
If you entered a multi-byte character into a prompt and then changed your mind
and used backspace to fix the character, only the last byte of the character was
removed. Because pango is intelligent, it noticed the broken utf8 and
complained.
So far nothing new. But since 711d78b50c the textbox will throw a lua error
when it gets an invalid text (= pango complains). Throwing an unprotected lua
error in this context causes the keygrabber to be killed which stops the prompt.
Fix this by removing bytes as long as there are bytes left that can be removed.
This is FS#801.
Signed-off-by: Uli Schlachter <psychon@znc.in>
Uli Schlachter
Roman Kosenko
Ignas Anikevicius (gns_ank)
Julien Danjou
immerrr