You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
some more details ... ultimately, I think this bug is due to a failure in the disconnection strategy i mentioned above in #147 (comment).
If you add self.sample_menu.destroyed.connect(lambda: print("DESTROY")) somewhere, you'll see that the destroyed
event IS indeed emitted, but the intended _disconnect callback is never getting called (and so self._app.menus.menus_changed.disconnect(self._on_registry_changed) is never getting called either). I think this probably means that the strategy of having a QObject connect its own method to its destroyed signal isn't going to work (presumably that callback method itself is cleaned up and no longer called).
If you try to outsmart it by using a locally defined function closing on the QObject:
then the _disconnect function does get called, but then psygnal has an issue actually executing the disconnection cause it can no longer find the callback to disconnect it:
Traceback (most recent call last):
File "/Users/talley/dev/self/app-model/src/app_model/backends/qt/_qmenu.py", line 58, in _disconnectself._app.menus.menus_changed.disconnect(self._on_registry_changed)
File "src/psygnal/_signal.py", line 827, in disconnect
File "src/psygnal/_signal.py", line 799, in _slot_index
File "src/psygnal/_weak_callback.py", line 130, in weak_callback
File "src/psygnal/_weak_callback.py", line 363, in __init__
File "src/psygnal/_weak_callback.py", line 190, in __init__
File "src/psygnal/_weak_callback.py", line 258, in object_keyRuntimeError: wrapped C/C++ object of type QModelSubmenu has been deleted
It's possible we could catch and special case that in psygnal itself (to handle the case where essentially all attribute access is no longer permitted on the previously connected callback)... but I need to look into that.
some more details ... ultimately, I think this bug is due to a failure in the disconnection strategy i mentioned above in #147 (comment).
If you add
self.sample_menu.destroyed.connect(lambda: print("DESTROY"))
somewhere, you'll see that thedestroyed
event IS indeed emitted, but the intended
_disconnect
callback is never getting called (and soself._app.menus.menus_changed.disconnect(self._on_registry_changed)
is never getting called either). I think this probably means that the strategy of having a QObject connect its own method to itsdestroyed
signal isn't going to work (presumably that callback method itself is cleaned up and no longer called).If you try to outsmart it by using a locally defined function closing on the QObject:
then the _disconnect function does get called, but then psygnal has an issue actually executing the disconnection cause it can no longer find the callback to disconnect it:
It's possible we could catch and special case that in psygnal itself (to handle the case where essentially all attribute access is no longer permitted on the previously connected callback)... but I need to look into that.
Originally posted by @tlambert03 in #147 (comment)
The text was updated successfully, but these errors were encountered: