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

Improvements to events #3210

Closed
almarklein opened this Issue Nov 30, 2015 · 3 comments

Comments

@almarklein
Copy link
Contributor

almarklein commented Nov 30, 2015

Continuing discussion from #3191 (comment)

Bokeh currently has some ways to keep track of changes/events, but its not very much "streamlined". E.g. you cannot let users pick a line without causing the line to be become part of the current selection.

cc @havocp @brendancol

@almarklein

This comment has been minimized.

Copy link
Contributor Author

almarklein commented Nov 30, 2015

Copying in @havocp's comment:

We could model events as state changes (imagine model fields like latest_event or click_count, then you watch those for change). But that would be awkward, at least if it were the only API - maybe it would be fine on the protocol/implementation level, I don't know.

I don't love the current setup with callback for certain events, because it only works for client-side callbacks. I think it'd be nicer if both Model.on_change and something like Button.on_click existed, and if you passed a Python function to them you got a server callback, and if you passed a JavascriptCallback object to them you got a client callback, or something along those lines. Also we could have a way to compile Python to JS as we do for callback now thanks to Almar.

Some things will not work well if done server side, for example I think if you did any kind of click-and-drag functionality with server side callbacks for the click and drag events, it would probably work poorly. But other things like clicking a button I imagine would work very well with server-side callbacks.

I could imagine a mechanism not unlike properties.py, or maybe part of properties.py, for registering events that a class can generate? It could automatically create a corresponding property which would be the list of client-side callbacks...

@almarklein

This comment has been minimized.

Copy link
Contributor Author

almarklein commented Nov 30, 2015

We could model events as state changes (imagine model fields like latest_event or click_count, then you watch those for change).

That sounds similar to how I currently do "events" in Flexx, using a Reactive-Programming-like approach. I'm actually starting to think that RP is not a very good model for widget systems, especially visualization oriented apps. Here is my proposal for changing Flexx' event system. Basically, I want to make things more simple/classical, but keep some of the niceties of the current system, such as the easy way to bind functions to events. It would also mean that Flexx moves from "signals" to properties, which makes me wonder about compatibility with Bokeh ...

I could imagine a mechanism not unlike properties.py, or maybe part of properties.py, for registering events that a class can generate?

This is very much what I had in mind for Flexx as well. I think that it makes sense that for each property there is a corresponding event that gets fired when that property changes, and that other events can be defined in a similar way.

@mattpap mattpap self-assigned this Sep 1, 2016

@bryevdv bryevdv added this to the 0.12.5 milestone Dec 21, 2016

@bryevdv bryevdv added type: task and removed type: discussion labels Dec 21, 2016

@mattpap mattpap removed their assignment Mar 2, 2017

@bryevdv

This comment has been minimized.

Copy link
Member

bryevdv commented Mar 17, 2017

This was closed by #5941

@bryevdv bryevdv closed this Mar 17, 2017

@bryevdv bryevdv moved this from Triage to Done in Focus: BokehJS Core Improvements May 12, 2017

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.