New widget for formatted text?

[fperez]

Context

This is just to brainstorm an idea I had while updating the widget example, before I forget. I could well be off the mark.

It seems to me that, with these new capabilities, it will become very useful to be able to define a widget that wraps a numerical value, but always displays it with predictable, controllable formatting. We can sort of achieve that today with widgets.Label the way @rowanc1 did it (esp. if we additionally use f-strings in the value setting).

Proposal

But it seems to me usage would be in general simpler/more pleasant with an API along the lines of

x = widgets.NumericLabel(value = 1.23456, format = ".1f")

This would then allow us to easily do operations on x, including numerical ones if needed (by accessing x.value), while widgets could update it, and it would display cleanly in rendered cells.

I'm proposing it here for us to discuss and experiment a bit, but obviously this would be meant to go into ipywidgets if we want it to go further.

Tasks and updates

No response

[agoose77]

This could be a useful feature, and I agree that IPyWidgets would benefit from it. We'd probably want FloatLabel and IntLabel to be able to specify the value type.

[rowanc1]

Super into ways to simplify ways to show dynamic text/control elements inline. @fperez's idea is awesome, and I think it would be a great addition as is (+/- naming, ints, floats, etc) to the widgets world.

Below are some other ideas that are in this same vein that I think are worth exploring in some capacity over the coming months. For example, thinking about ways to simplify the process of creating new dynamic widgets through addition/multiplication/etc as well as letting the renderer decide on the view (e.g. text vs slider vs scrubber) rather than the widget model in python.

# Code
x = widgets.Number(value = 42, format = ".1f", min=0, max=100)
---
% Markdown
The number {eval}`x` is slightly less than {eval}`x+10`, which can be changed by {slider}`x`.
---

All of these should be dynamic, and linked (also with js-link if possible). I think this is possible by over-riding some of the __add__ etc methods on a simple widget to create some of the boiler plate stuff that would be quite common in these examples.

I have played with some of these ideas in javascript over the years, some of the work is here:

• https://curvenote.dev/components I don't think the implementation there is worth adopting, but some of the ideas of reactivity are very compatible with widgets.

[fperez]

First, agreed on cleaner naming/typing support :)

Second - thx @rowanc1 for sharing those examples, they look great!! I totally agree on pursuing these ideas as much as possible. It will take some thinking to design APIs and patterns that make the JS-only side live in good harmony with the kernel-embedded widgets and their Python API. That approach adds obviously latency costs, but it also:

1. Lets scientists who only live in the Python world express similar ideas without learning JS.
2. Allows for interactions that legitimately require access to kernel data or computational resources.

It's a complicated set of tradeoffs, but definitely fun and worth exploring! Thanks for being receptive to the idea :)