Quote:
Originally Posted by kiwidude
@chaley - thx for the info and that makes sense, but why would __init__() be being called more than once on a GUI plugin? Surely only one instance of the Reading List plugin is ever being created?
|
To quote Kovid:
Quote:
|
__init__ can be called at anytime or multiple times on a plugin class. There can be multiple plugin objects.
|
I haven't been able to find a spot outside of a worker process where this would happen, but that doesn't mean that there isn't one.
Quote:
What happens with this plugin is that the configuration widget subscribes to some signals from the plugin action, which it uses to updates its grid to shwo device status, in case a user plugs in a device while they have the config screen open. It looks to me like those signals are not being disconnected in PeterT's case (I can't replicate the error myself).
At the moment I disconnect those signals in an __exit__() function on my config widget, but that must be the wrong place for PeterT. The problem is that there are no guaranteed callbacks to my widget from calibre's do_user_config code() if the user does not click on "ok" so that save_settings gets called. So where should I put my signal disconnections?
|
__exit__ is part of the "with x:" construct. Do you do something like "with configWidgetClass() as widget:"? Interesting idea. I haven't ever tried that.
Doesn't do_user_config open a Qt widget of some kind? If so, then override the accept and reject methods. One of the two of these will get called when the dialog is closed in some way.
Another possibility is to connect the signals to methods that will not go away. These methods verify the situation and pass the calls along only when it is correct to do so. This way you connect the signal once, never disconnecting it. Edit: Kovid has provided a method to check if it is correct to pass the call along.