Widget Messaging Protocol Schema
See original GitHub issueProblem
I’m doing an implementation of jupyter-widgets for the IHaskell kernel, and I’m using messages.md as a reference.
I can’t seem to understand what version_major
and version_minor
are on the display_data
message.
Are they the widget messaging protocol version, as specified in the comm_open
message? Are they the widgets’ view module version? Or these numbers come from a completely different thing.
Suggested Improvement
Specifying where these numbers come from
Issue Analytics
- State:
- Created 2 years ago
- Reactions:1
- Comments:5 (2 by maintainers)
Top Results From Across the Web
ipywidgets/messages.md at master · jupyter-widgets ... - GitHub
A Jupyter widget has both a frontend and kernel object communicating with each other using the comm messages provided by the Jupyter kernel...
Read more >Widget option schema - Product Documentation | ServiceNow
Widget instances allow users to uniquely configure each widget they add to a page. Use the option schema to define the parameters for...
Read more >Widget protocol specs - Tiledesk Developer Hub
This document describes the raw JSON protocol specifications used by external chatbots (and by Tiledesk itself) to send messages to the widget.
Read more >Widgets Development Guide | ThingsBoard Community Edition
Resources/HTML/CSS; JavaScript; Settings schema; Widget preview ... You should see a “connected” message in the console. Navigate to Dashboards and create a ...
Read more >Schema and Topic Design in Event-Driven Systems (featuring ...
The way to enforce a communication protocol with services using a messaging system is by using a schema, a strongly typed description of ......
Read more >Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start FreeTop Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
Top GitHub Comments
Thanks for bringing this up.
I’d love to see that core schema complemented (in another file) with a concrete schema of all the public widget models, and custom events. This nasty PR shows such a thing is possible, generating a TS backend for at least parts of ~60 of the ~80 core classes (including private classes and members)… but eventually, it seems like the Schema could become the source of truth, and could be used to test the public API of different implementation… especially if we warmed jupyter_kernel_test back up.
I have another question. I’m trying to implement the Output widget, but I can’t make it work.
I’ve been “reverse-engineering” the messages exchanged when I use it on IPython and replicating it on my kernel, but I still can’t make anything appear on the cell where I’ve displayed the output widget. Not even plain text.