Closed eoinell closed 4 years ago
Looks ok to me, I'm yet to test it. Either way, I want to get @wdeacon opinion on threading in nplab. Do we have a standard way of doing them? Are we sticking to PyQt threads or using the threading package? I feel the code is a mix of everything, but just wondering if you know pros and cons
Way back at the start, I avoided qThreads on the grounds that we hadn't settled on using Qt as our GUI toolkit and I was keen to avoid too many hard dependencies. I did start trying to standardise some amount of threading with the Experiment class, but I think possibly the only bit of that that gets used regularly is the progress bar function?
Given that the no-hard-dependencies ship has well and truly sailed, it might be that qThreads make more sense now. They should integrate better with the event loop, my only concern would be whether there's any performance penalty over plain threads (and I suspect it will be pretty minimal).
Mostly I tend to use threading.Thread
because that's nicely portable if I want to re-use my code without Qt (which I do), but as I'm not contributing much code to nplab any more, there's very little reason to apply that logic here.
Thanks @rwb27! That's exactly what I needed 😃
I've also been trying to use threading
as much as possible (see this for example). Would that be something @eoinell or @J-Griffo would be interested in changing? If that's a hard pass, go ahead and merge it (I've had a play around already)
Other than that, and answering @eoinell question, no, there's no way of changing that behaviour when you make it Live. Normally you would always have your andor._logger
level set to INFO
not DEBUG
and all of that output will not appear. When you are in DEBUG
the logger is set to let you know every time the DLL is called
I had a quick go and it seemed hard so I think I'll just merge it. I copied this format from the live mode part of seabreeze anyway
Works, only issue is that the output goes a bit haywire when in live mode
Is there a way to turn this off?