Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Feature: emitting tool and ui events and attaching callbacks #5278

canavandl opened this issue Oct 4, 2016 · 2 comments

Feature: emitting tool and ui events and attaching callbacks #5278

canavandl opened this issue Oct 4, 2016 · 2 comments


Copy link

The HoloViews team is interested in implementing some complex, custom user interactions for their Bokeh backend, in order to support things like dragging glyphs or hovering over elements to drive output in an adjacent plot.

The current issues they face include:

  • Needing combinations of UI events that aren’t supported by Bokeh’s action/gesture/inspector tool UI event grouping (making custom tool models not a complete solution)
  • Needing events to be sent during UI events that don’t emit events (e.g. having the inspector tools drive changes, e.g. via mouseover/hover interactions)

The current Bokeh callback system is based on emitting events on model property changes and supports both client side and bokeh server-mediated callbacks. Tools drive callback in this system by either changing the “selected” attribute of a ColumnDataSource (select tools) or by changing the range bounds of a plot (the zoom and pan tools)

Note: There are a couple of counter examples of this property change-driven pattern, including the callbacks emitted on SelectTool events (which don’t support bokeh server callbacks) and some of the input widgets (unclear to me why, but perhaps because they’re wrapped jquery elements). I would argue that the current select tool callbacks are ill-implemented, but perhaps evidence of user desire to customize such tool events.

Proposed is a system of UI events or tool events that can be configured to execute either client-side or bokeh server callbacks. Ideally, the coordinates of the the tool or UI event would be exposed (both in screen and data space coordinates?)

Copy link
Contributor Author

The result of this experiment is:

  • Exposing the UI Events in a general matter is useful to downstream libraries that use Bokeh as a visualization backend (e.g. Holoviews)
  • Suggests that adding a real UI event message bus is a better path forward (similar to change event handling), then adding only client side callbacks (and not supporting UI events in server implementation.

Copy link

bryevdv commented Mar 15, 2017

closed by #5941

@bryevdv bryevdv closed this as completed Mar 15, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
None yet

Successfully merging a pull request may close this issue.

2 participants