Quote:
Originally Posted by kiwidude
Yeah I had wondered about that. Won't that signal also get fired when I change the restrictions, so I will still need to unhook/rehook around when my plugin makes changes to those right? At least that is isolated and controllable rather than the clear signal I was attempting to use.
|
Yes, you will see the signal. I can't deactivate it, because that would affect all the other listeners.
After some thought, I think you would be better served to hook into activated instead of currentIndexChanged. If the user chooses index 1 (current search), activated will fire and the restriction will change to the current search. However, currentIndexChanged will not fire, because the index didn't change.
I don't know if you should unhook/rehook, or if you should have an 'ignore' flag. By the latter I mean using a double-signal arrangement, something like:
Code:
def do_search_restriction_activated(self, idx):
if not ignoring_signals:
self.restriction_changed.emit()
def do_restriction_changed(self):
do what you need to do
pyqtSignal restriction_changed()
def __init__()
self.ignoring_signals = False
gui.search_restriction.activated[int].connect(self.do_search_restriction_activated)
self.restriction_changed.connect(self.do_restriction_changed)
Then in your code, when you mess with restrictions you set self.ignoring_signals = True, do what you need to do, then set it to False. As your code uses the private signal, it will see it only when it should. You can connect multiple things to it, without worrying about adding the test to each connected method.
FWIW
