-
Notifications
You must be signed in to change notification settings - Fork 60
Open
Description
A common difficulty I hear from users is understanding the attributes and other contents of an Event instance. Currently the various canvas events are typed in pygfx (PointerEvent, KeyEvent, etc.). I'm wondering if we should wrap these in fastplotlib and provide all Event classes as top level imports so they can be used for typing, and easier documentation. The description in the user guide (copied from jupyter_rfb I think?) and the event tables isn't the clearest way to define this I think. Also pygfx plans to remove pygfx.Event and directly provide dicts like rendercanvas.
Suggestion:
- Create a
fpl.Event, and documented subclasses for every single event, such asfpl.PointerEvent, etc. that wrap the pygfx event. - For graphics, event classes as class attributes so they are easy to distinguish? Ex:
ImageGraphic.DataEvent, and maybe evenImageGraphic.PointerEventwhich has thepick_infounpacked as attributes so that everything can be picked up easily by IDEs without having to scour through documentation.- might be a better way to namespace this, we can decide those details, maybe like
ImageGraphic.event.DataEvent,ImageGraphic.event.PointerEvent, etc.
- might be a better way to namespace this, we can decide those details, maybe like
In addition to making the event attrs recognized by the IDE, it becomes easy to auto-doc what every event looks like.
Example usecases:
@image.add_event_handler("click")
def image_clicked(ev: fpl.ImageGraphic.events.PointerEvent):
ev.pick_info. # IDE can display attributes
@image.add_event_handler("cmap")
def cmap_changed(ev: fpl.ImageGraphic.events.CmapEvent):
ev. # IDE can display attributes
@linear_selector.add_event_handler("selection")
def cmap_changed(ev: fpl.LinearSelector.events.SelectionEvent):
ev. # IDE can display attributes
@figure.add_event_handler("key_down")
def key_down_handler(ev: fpl.KeyEvent):
ev. # IDE displays attrsMetadata
Metadata
Assignees
Labels
No labels