Memory management for GObject signals

[oezingle]

This is a pull request to mitigate the issues I found in this issue.

demo.lua is a simple Gtk demo, modified from the issue - this fork fixes the 2 issues I found with signal handling. Signal "pads" now provide the :disconnect(handler_id) method, and signal assignment now automatically manages memory.

However, this fork shouldn't be merged without modification. I was unable to figure out how to properly register a field to a GObject. As such, lines 324-326 of lgi/override/GObject-Object.lua are some evil code:

-- TODO: someone who understands the LGI codebase much better than myself no doubt knows where to put a definition similar to this one
-- create a table of signal handlers LGI automatically memory manages
self._signal_handlers = self._signal_handlers or {}

Please advise as to how I can properly register a field such as this.

[psychon]

someone who understands the LGI codebase much better than myself

I'm sorry, but we do not have anyone around like that. The original author went missing and ever since people in the same position as you tried not to break more stuff than they fixed. Sorry.

[psychon]

I do not think I like that. There might very well be reasons to have more than one signal handler connected to the same signal. (And yes, I know that this is kinda weird that an assignment only adds but does not override, but that wasn't me 🤷.)

[oezingle]

I agree, but that's why signal handler pads are useful. GObject.on_<signal>:connect() allows us to connect multiple handlers, whereas my fork only allows a single handler at a time to be attached via the assignment operator. This, in my opinion is the best of both worlds.

[psychon]

Dunno what this comment refers to exactly, but whatever "connect signal with detail" is, does it provide a way to disconnect? Is that what the code below does / adds / implements?

[oezingle]

That comment is original to the LGI codebase, not my fork. GObject signal documentation is a bit fuzzy with detailed signals, but one example I found from Stackoverflow is the notify signal. GObject::notify is emitted any time any property is changed, but the detailed GObject::notify::<property> signal is only emitted when that given property is changed. Detailed signals are handled differently to non-detailed signals in the GObject override, but I figure behavior should be identical for both, so I chose to implement the memory management utility for both.

I realize now I misformatted my detailed notification string - info.name .. "." .. detail should be info.name .. "::" .. detail

[oezingle]

I did some more research, looks like the detailed signal implementation LGI provides is less polished than the other signal handlers.

This code, inserted into demo.lua in my fork will work, but detail names are not transformed like their parent signal name. Also, the API for details here only seems to support assignment, which is a letdown as developers would either be able to disconnect detailed signals, or assign multiple, but never both, unless the LGI detailed signal API is rewritten. I should mention it's entirely undocumented.

button_2.on_notify["has-focus"] = function ()
    print("button 2 focus state changed")
end

In my opinion, the pad metatable should allow __index and __newindex events, so that :connect() and :disconnect() can be exposed for detailed signals, along with variadic assignment. If I have time I might throw an implementation together over the weekend.

[oezingle]

Still looking to make a few improvements before any chance of a merge, but I've implemented :connect() and :disconnect() for GObject.on_<signal>.<detail>, and I believe I've found the right location to create the _signal_handlers table

Edit: nope! Going to try again. self._signal_handler refers to all GObjects of that class, not a given instance.