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

Closed
canavandl opened this Issue Oct 4, 2016 · 2 comments

Comments

Projects
None yet
2 participants
@canavandl
Contributor

canavandl commented Oct 4, 2016

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?)

@canavandl canavandl referenced this issue Oct 4, 2016

Closed

UIEvents model #5276

0 of 3 tasks complete
@canavandl

This comment has been minimized.

Show comment
Hide comment
@canavandl

canavandl Oct 26, 2016

Contributor

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.
Contributor

canavandl commented Oct 26, 2016

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.
@bryevdv

This comment has been minimized.

Show comment
Hide comment
@bryevdv

bryevdv Mar 15, 2017

Member

closed by #5941

Member

bryevdv commented Mar 15, 2017

closed by #5941

@bryevdv bryevdv closed this Mar 15, 2017

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment