The default `rc.lua` was using the focus/unfocus signals to set
the border color along with `awful.rules`. This logic block was
no longer aligned with the rest of `rc.lua` since it was
the only place where `beautiful` variables where only used by
`rc.lua`.
On top of this, the new request handler also has extra contexts
for the urgent and floating/maximixed use cases. So it can be used
by themes to implement much smarter borders than just focus based
ones. They were previously limited by the fact most of the
(un-monkey-patchable) logic was in `rc.lua`.
Note that this commit also shuffle the awful.rules order between
the titlebar and the border and changes the tests accordignly.
After some consideration, I came to the conclusion the previous
behavior was bogus and the fact that the placement tests required
to know about the titlebar height is simply a proof of that. The
change was required in this commit because since the border is no
longer in the default rules, a new buggy edge case surfaced.
Having the new object layout will be important soon when the
append/remove methods start to get added to the client and the
reborn `awful.keyboard` module.
ldoc has a magical `@classmod` module type which tries to detect
what is a method and what is a static function. It fails about as
often as it works. This commit makes everything explicit to remove
such issues.
Fixes#2640
Ref #1373
* Fixed input_passthrough property not being set
In the table of properties supplied to the `wibox` function, you couldn't set the `input_passthrough` property. You could only set it after the wibox was created like this: `my_shlick_wibox.input_passthrough = true`. This commit fixes that and now you can set it in both ways.
Before this commit, it was added by `wibox.widget.base` if
`:setup()` is used. However it doesn't work for the `awful.popup`
because of the extra indirection.
This commit stops the monkey-patching and make sure the function
always exists. This doesn't prevent it from not working and in
the long run this should still be moved into the hierarchy.
However for now it makes the situation a lot more consistent and is a
quick band-aid without too much controversy.
Mitigate #2181
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>
Emmanuel Lepage Vallee
Adrian Gabriel
Uli Schlachter
Uli Schlachter
Daniel Hahler