Как реагировать на события, вызванные пользователями, в отличие от периодических обратных вызовов? - PullRequest
0 голосов
/ 12 мая 2019

Более конкретно, у меня есть ползунок (который я называю clock), значение которого я увеличиваю с периодическим обратным вызовом:

clock = Slider(start=0, end=1000, value=0, step=1, title='clock')

def increase_slider_value():
    clock.value = (clock.value + 1) % 1000

period_ms = 50
curdoc().add_periodic_callback(increase_slider_value, period_ms)

Когда значение часов изменяется, источники некоторых графиков обновляются:

clock.on_change('value', update_sources)

Обновление источников является дорогостоящим и довольно оптимизированным, с использованием патчей и операторов if для ключевых значений часов.Это прекрасно работает, если обратный вызов меняет часыНо если пользователи берут слайдер и перемещают его вокруг патчей, они больше не создают нужные источники, т. Е. Создают недопустимые состояния источников и графики мусора.Единственный полу элегантный способ, который я вижу, чтобы исправить это, состоит в том, чтобы рассматривать изменения значений, вызванные пользователем, иначе, чем изменения значений, вызванные обратным вызовом.Пользовательские обновления потребовали бы нового вычисления источников, в то время как периодический обратный вызов продолжал бы использовать исправления.

A) Имеет ли это смысл для вас / вы одобряете?

B) Какмогу ли я получить clock.on_change(..), чтобы различить событие, которое вызвало изменение?Есть ли события «перетаскивания ползунка»?

1 Ответ

2 голосов
/ 12 мая 2019

Нет никакого способа различить события напрямую.Я бы посоветовал вам использовать слегка хакерский, но работоспособный подход, описанный в Throttling in Bokeh application .Это служит двум целям:

  • Вы можете указать обратный обратный вызов для «поддельного» источника данных, чем clock.on_change(...).

  • Выможет фактически перебрасывать обновления пользователя из ползунка только в «законченные» состояния, поэтому дорогой обратный вызов не выполняется излишне часто.

...