🪼 branch checks and previews

•	Name	Status	URL
	Spaces	ready!	Spaces preview
	Website	ready!	Website preview
	Storybook	ready!	Storybook preview
🦄	Changes	detected!	Details

Install Gradio from this PR

pip install https://gradio-builds.s3.amazonaws.com/de843f3a33d01c19e810a15ee4263fd6b7929449/gradio-4.37.1-py3-none-any.whl

Install Gradio Python Client from this PR

pip install "gradio-client @ git+https://github.com/gradio-app/gradio@de843f3a33d01c19e810a15ee4263fd6b7929449#subdirectory=client/python"

Install Gradio JS Client from this PR

npm install https://gradio-builds.s3.amazonaws.com/de843f3a33d01c19e810a15ee4263fd6b7929449/gradio-client-1.2.0.tgz

🦄 change detected

This Pull Request includes changes to the following packages.

• Maintainers can select this checkbox to manually select packages to update.

With the following changelog entry.

Add Timer component

Maintainers or the PR author can modify the PR title to modify this entry.

Hmm I'm finding this syntax unnecessarily complicated in this PR and internal message:

with gr.Blocks() as demo:
  def show_plot_1():
    ...
  def show_plot_2():
    ...

  with gr.Timer(5) as timer:
    plot_1 = gr.LinePlot(value=show_plot_1)
    plot_2 = gr.LinePlot(value=show_plot_2)

• I don't think it makes sense for gr.Timer() to be a context manager. First of all, this introduces a completely new use of context managers in Gradio, as right now, we only use context managers to set the layouts. Secondly, this fuses two things which should remain separate: the position of components and whether they are controlled by the same timer. Imagine that you have a row of line plots, but only some of them (say every other one) should be running every 5 seconds. This context manager syntax would be very cumbersome to apply

That being said, I do see the value in having a separate gr.Timer() object, which can be started/stopped/adjusted. I would instead make the every argument also be able to take a gr.Timer() instance, which can be started/stopped/adjusted as your PR implements.

So rewriting your example code:

with gr.Blocks() as demo:
  def show_plot_1():
    ...
  def show_plot_2():
    ...

  timer = gr.Timer(5)
  plot_1 = gr.LinePlot(value=show_plot_1, every=timer)
  plot_2 = gr.LinePlot(value=show_plot_2, every=timer)

Also added inputs= kwarg to make function values more useful, e.g. gr.Textbox(value=lambda a, b: ..., inputs=[text1, text2])

This addition to the API does feel useful to me ✔️

I would instead make the every argument also be able to take a gr.Timer() instance, which can be started/stopped/adjusted as your PR implements.

I like this suggestion.

Also, I think right now the timer only triggers tick event and value functions. Can we make it trigger any event on a schedule?

For a use case where you want to start the schedule based on a button click or tab select, you have to do something like this

with gr.Blocks() as demo:
    timer = gr.Timer(5, active=False)
    plot = gr.LinePlot(value=get_data, every=timer)
    button = gr.Button("Start")
    button.click(lambda: gr.Timer(active=True), None, timer)

If we let it trigger any event, the code could be rewritten like the following which feels more natural:

with gr.Blocks() as demo:
    plot = gr.LinePlot()
    button = gr.Button("Start")
    button.click(get_data, None, plot, every=gr.Timer(5))

don't think it makes sense for gr.Timer() to be a context manager... instead make the every argument also be able to take a gr.Timer() instance

Okay sure. Originally my logic for using context managers for Timer and InputSet had been that in a dashboard, every component is tied to the same timer and set of inputs, and its annoying to have to set the timer and the inputs for each component, but that's something we can design some other time.

I think right now the timer only triggers tick event and value functions. Can we make it trigger any event on a schedule? ...e.g. button.click(get_data, None, plot, every=gr.Timer(5))

A little confused by this syntax. Does the syntax above start the given timer, and then bind this same event to the tick of the Timer? If it gets clicked again, it does nothing?

Without any button control, the syntax is very clear:

plot = gr.Plot()
timer = gr.Timer(5)
timer.tick(get_data, None, plot)

or simply:

plot = gr.Plot(get_data, every = gr.Timer(5))

If you are adding a button to start the timer, then you probably want to be able to stop it too, so you need access to the timer object. In that case, you are suggesting:

plot = gr.Plot()
timer = gr.Timer(5)
button.click(get_data, None, plot, every=timer)
button2.click(lambda: gr.Timer(active=False), outputs=timer)

correct? Imo that's messy compared to:

timer = gr.Timer(5)
plot = gr.Plot(get_data, every=timer)
button.click(lambda: gr.Timer(active=True), outputs=timer)
button2.click(lambda: gr.Timer(active=False), outputs=timer)

The second option is much more explicit, takes the same amount of code, and starting and stopping use the same syntax.

I don't think it makes sense to add every to event listeners. It's a decent shorthand for components that have function values though.

Ok let's stick with the original proposal to have every only apply to component value functions.

I believe everything has been addressed, could use a re-review cc @abidlabs, also @pngwn if you can look at my approach to avoid calls stacking up when the browser is minimized - this was happening because window.dispatchEvent was triggering while minimized, but window.addEventListener("gradio") was not issuing callbacks until the window was restored. Fixed by only firing ticks if the document is visible

all good from my end!