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>
Similar systems already exist un luaobject, wibox and the declarative
widget system. This close the gap and also bring the property based
syntax to wibox and other gears.object users.
While this need to be enabled explicitly for legacy reasons, it
doesn't break the API.
Once widespread, this implementation will replace the one found
in wibox.widget.base_widget.
Lua will remove objects as values from a weak table before these objects are
finalized, but as values only in the next garbage collection cycle after the
object was finalized. Up to now, gears.object uses a table with weak keys so
that :disconnect_signal() works. This means that a signal can still call methods
which were already considered garbage by the garbage collector and thus can use
userdata from the C side which was already finalized. Crashes and other bugs
result.
This commit changes the code so that the function is also a value in the weak
table. Thus, the GC will remove the entry before the object is finalized.
Special magic is needed for Lua 5.1, because there only userdata has the
behavior that we want while we have a function. We do some magic with function
environments to make this work...
Closes https://github.com/awesomeWM/awesome/pull/567.
Signed-off-by: Uli Schlachter <psychon@znc.in>
Connecting to a signal weakly has the same effect as connecting to it strongly,
but it allows the garbage collector to disconnect the signal in case nothing
else references this function.
Signed-off-by: Uli Schlachter <psychon@znc.in>
Uli Schlachter
Emmanuel Lepage Vallee
Daniel Hahler
Julian Wollrath