Over using ui.delay ? Or threads better even for someone that does not understand them
I am sure asked this question before in different ways. But I don't think exactly this way.
I want threading, but threading for dummies. I would like it to work and be reliable.
So my question is, the little higher level API of ui.delays up to this. In the image below, each image is a class with object as its base class.
If it's suppose to display the time, then the below is called
def time_update(self): self.parent.set_needs_display() ui.delay(self.time_update, 1)
From the image below, you can see there are 3 objects doing this. It seems to work ok. I get the occasional crash, but i am using beta 3 and changing a lot. Just not sure this is a valid approach or not. While I have this working, I want to make a timer class that just uses ui.delays. Then if a object requires animation or drawing the date or checking the elapsed time etc , just attach the timer object. Somehow it seems straight forward. But I have a feeling it not really. Seems too easy 😱
Again, sorry. I have sort of asked about this before. Just does not sink in.
Hmmm, I just had a bad thought. I wonder what happens if ui.cancel_delays() is called. I am guessing it's global in the sense it will stop every live objects ui.delays. Maybe there is a way to stop that behaviour with a context manager or some other magic
Found an easy way to test it. Seems one call to ui.cancel_delays() kills them all. So back to the drawing board for me
Ok, no replies needed. I could use a Timer Object or other ways. Just been a while since trying this. Still gives me a headache 😱
Well with Python 3.2 ++ there is added bonus. A Thread is a class, thread.Timer is a subclass of thread.
So I am trying to make my timer by subclassing thread.timer
with a threading.Timer, you are creating new instances constantly, which might be sort of wasteful, although as long as you don't store references to them, they should be gracefully deleted as they fall out of scope.
check out the chess timer thread. My favorite approach these days is a decorator which wraps a function in a Thread, and a while someCondition loop with a sleep. The condition might be on_screen, or checking some flag in the object, etc.
The approach is simple and robust. Another approach I have used is a Timer (start the Timer at the start if the function for the most accurate call period, if that is important, whch it usually is not. for instance if your function takes 0.5 sec to execute, and you sleep(1) at the end, then effectively it is called every 1.5 sec. if your call takes msec, it doesn't matter)
@JonB , thanks. I abandoned the idea of subclassing a thread or thread.timer. Did not behave the way I expected it too, I did override the run method. It Was a train out of control 😱
Then I went back to the same idea I was using more or less for the virtual cells. Copied what I was doing before.
I did a gist , a little long to paste here. But I am looking for this sort of functionality. I am sure I trivialise the complexity in what I have done. I will also look at the wrapper you suggest.
But in my mind there should only be one! I am sure there is one great way to do this. My prime was wasted on my youth 🤐
Oh, my gist looks like crap. Just hammering away at it
@JonB , I had a look at your drop in run_async. I think for what I want is better to continue to make the generic type timer. Actually for the idea I presented here the BarrierObject looks interesting. The test I was working on is having a series of steps complete over time with a ui. I was wondering how I would easily control each steps stage. I was going to relying on polling and callbacks. But it looks like Barrier may be made for this sort of thing. Yet to try it.
Well after more reading and trying, barrier objects are not going to save my life for linear step processing. I had some idea, it would allow be me to just queue some threads and it would execute each in a series with some extra control. I see now, it waits until the number of threads it's expecting to complete, do complete before moving on. Still very handy, I just didn't understand its purpose.