Do it now since the future awful.popup and notification widget
also uses it.
The `load_ldoc.cmake` changes allow to include `.ldoc` blocks in
existing ldoc comments. Previously, it added some extra newlines
and an autogenerated comments saying the content below was imported.
The problem is that this prevented the system to be used for shared
function arguments.
This commit also renames the `wibar` argument table from `arg` to
`args` as the name has to be the same in the `wibox` and `wibar`
constructor for this to work.
When doing w.shape_bounding = foo on a wibox, the code would first read
shape_bounding from the underlying drawin. This would create a
(possibly) huge cairo image surface that just waits to be collected by
the garbage collector, resulting in increased memory usage.
Fix this by checking the force_forward table first. This tables contains
the names of shape properties. Thus, the evaluation of this statement
gets short-circuited and the property is on the drawin is not read.
Helps-with: https://github.com/awesomeWM/awesome/issues/1958
Signed-off-by: Uli Schlachter <psychon@znc.in>
This bridges between gears.shape and the shapes. So far, it does not try
to do any kind of anti-aliasing magic, so you get "steep edges".
Signed-off-by: Uli Schlachter <psychon@znc.in>
Up to now, a drawable always figured out the screen that it is on by
looking at its position. This causes memleak-like problems with wibars:
A wibar has a screen assigned, but its underlying drawable will end up
referring to another screen. Via this, we were managing to build a long
reference chain of screens and drawable that meant that none of the fake
screens that our test suite added could be garbage collected.
To fix this, add wibox.drawable._force_screen(s). After this function is
called, the normal screen detection based on the position is skipped and
instead the given screen is always used. This breaks the above reference
chain and things become garbage-collectable.
Also, this chains the drawable to the life time of the screen: When the
screen becomes invalid (.valid == false), the drawable will stop
redrawing.
Fixes: https://github.com/awesomeWM/awesome/issues/1237
Signed-off-by: Uli Schlachter <psychon@znc.in>
It does not provide much value. The version number is already known to
ldoc globally in the "description" variable.
Signed-off-by: Uli Schlachter <psychon@znc.in>
No idea what self referencing loops this refers to. Lua 5.1's and
LuaJIT's garbage collector both should handle cycles just fine. Things
only start getting complicated when you start using weak tables.
Unless someone comes up with an example where this patch causes a leak,
let's remove the weak table magic.
Signed-off-by: Uli Schlachter <psychon@znc.in>
This new function is called whenever the visibility of the drawable
changes. Later commits can use this for explicitly tracking the lifetime
of drawables instead of using magic weak tables.
Signed-off-by: Uli Schlachter <psychon@znc.in>
widget_at() no longer exists since 0aa4304bda (and the surrounding commits
stopped us using this function).
Signed-off-by: Uli Schlachter <psychon@znc.in>
The requirement to call add_signal() was added to catch typos. However, this
requirement became increasingly annoying with property::<name> signals and e.g.
gears.object allowing arbitrary properties to be changed.
All of this ended up in a single commit because tests/examples fails if I first
let add_signal() emit a deprecation warning.
Signed-off-by: Uli Schlachter <psychon@znc.in>
Before this commit, it was necessary to call 'rawset' to be
able to add new fields to the wibox. This is no longer required.
This solution was choosen because wibox is itself a base class of
menus and wibars. Those classes can now add new properties without
hacks.
As wibox contain a drawin, but isn't one, it is necessary to map
drawin to wibox.
This could eventually be fixed by turning wibox into drawin just
like the client, tag and screen do.
It's unused since commit 0aa4304bda. Before this was a stable sorting
algorithm since table.sort is allowed to be unstable. Apparently we don't need a
stable sorting algorithm anymore.
Signed-off-by: Uli Schlachter <psychon@znc.in>
A widget hierarchy describes the position of widgets. The hierarchy is a
recursive tree of widget hierarchy instances. This functionality depends on a
:layout function that is not yet implemented on widgets, but will be added
later.
Signed-off-by: Uli Schlachter <psychon@znc.in>
This table contains the drawable, wibox and titlebar that we are drawing on, but
also includes the screen and the DPI of that screen. This allows widgets to
depend on the DPI in their rendering.
Signed-off-by: Uli Schlachter <psychon@znc.in>
Emmanuel Lepage Vallee
Uli Schlachter
Uli Schlachter
Daniel Hahler
Daniel Hahler
Julian Wollrath