Support @interact(layout) in Jupyter

[jdemeyer]

CC: @kcrisman @novoselt

Component: notebook

Issue created by migration from https://trac.sagemath.org/ticket/22663

[jdemeyer]

comment:1

This isn't going to be easy. Given that it seems not used much, I wonder if it's worth the effort to support it.

[novoselt]

comment:2

Um, what do you mean not used much??? For involved interacts it is quite important to have some control on placement of controls, although perhaps we can use SageMathCell ideas that allow you to provide HTML code with locations for controls marked, see e.g. http://interact.math.ualberta.ca/MultivariateCalculus/Vector_fields.html with layout at line 289.

[jdemeyer]

comment:3

Replying to @novoselt:

Um, what do you mean not used much?

As far as I know, it's not used at all by https://wiki.sagemath.org/interact/ nor by the Sage interact library src/sage/interact.

Do you have interesting examples of interacts using layout? It would be good to have some test cases.

[novoselt]

comment:4

I consider my examples interesting, there are more at http://interact.math.ualberta.ca/, many of them started using the "list layout" of SageNB, but I had to be quite creative. Plain HTML makes things much easier for those who can write it.

As for wiki and library interacts - they were created in early days when maybe layout was not implemented and/or well-known. interacts web site used to have some examples, I think, but it is long gone.

[jdemeyer]

comment:5

Replying to @novoselt:

Plain HTML makes things much easier for those who can write it.

But that's something specific to the cell server, isn't it?

[jdemeyer]

comment:6

Replying to @novoselt:

I consider my examples interesting, there are more at http://interact.math.ualberta.ca/

None of these use interact(layout=...) which again supports my claim that this just isn't used much in practice.

[kcrisman]

comment:7

I consider my examples interesting, there are more at http://interact.math.ualberta.ca/, many of them started using the "list layout" of SageNB, but I had to be quite creative. Plain HTML makes things much easier for those who can write it.

As for wiki and library interacts - they were created in early days when maybe layout was not implemented and/or well-known. interacts web site used to have some examples, I think, but it is long gone.

Andrey is correct. One of the annoying things about working with an open source project is we have no clue sometimes what people produce. I am pretty sure that many of John Travis' interacts (including via WeBWorK) use this parameter.

The fact that Andrey doesn't use the layout parameter any more is just because he actually knows how to write good HTML, which will usually not be the case. I've certainly used the layout in a number of classroom presentations. But yes, I doubt that many research-level Sage developers use it. Which doesn't mean it's not important, contrary to popular opinion on sage-devel sometimes ...

[novoselt]

comment:8

As I said "many of them started using the list layout". One big problem with interacts that don't use it (or some other means for the same purpose) but have multiple controls: it does not fit on the screen with acceptable level of zooming to be used on a projector in class.

I don't recall using interacts once for research in 10 years of using Sage, but for teaching I almost exclusively use interacts, some of them got quite popular with students, and were beyond what Wolfram Alpha can do.

It is also quite frustrating to have instances when interacts user code has to be different depending on the used backend, so it would be nice to converge SageMathCell and Jupyter API. One problem with SageMathCell implementation relying on HTML id - it cannot be copy-pasted (or automatically generated several times) on the same page since ids are supposed to be unique.

[kcrisman]

comment:9

It is also quite frustrating to have instances when interacts user code has to be different depending on the used backend, so it would be nice to converge SageMathCell and Jupyter API.

+100

If cloud, cell, and Jupyter (now that sagenb is not part of the discussion) versions could converge (including controls depending on other controls etc.) that would be a very good thing. Slight differences might also impact MathBook XML, which in principle is supposed to be able to take one source and convert to all three of these formats.

[jdemeyer]

comment:10

Replying to @kcrisman:

I am pretty sure that many of John Travis' interacts (including via WeBWorK) use this parameter.

OK, I googled and found this one for example: http://sagenb.mc.edu/home/pub/58/

[jdemeyer]

comment:11

Replying to @kcrisman:

If cloud, cell, and Jupyter (now that sagenb is not part of the discussion) versions could converge (including controls depending on other controls etc.) that would be a very good thing.

Of course, but that's easier said than done. For example, I already mentioned some differences between Sage interacts in the Jupyter notebook and in SageNB on #21267.

Part of the problem with Jupyter is that we adapt an existing upstream solution (ipywidgets). Basically, my @interact for Jupyter is a thin wrapper over what is provided by ipywidgets. That makes it harder to add new features out of the blue.

Let me also mention that ipywidgets is mainly about the widgets (which are called "controls" in SageNB-speak) and not so much about interacts. For them, interacts is just one use case of widgets. But it's perfectly possible to do stuff with widgets without using @interact. I think this is a bit of a difference in philosophy between Sage interacts and ipywidgets interacts: with ipywidgets, the idea is to use @interact for simple stuff but directly use widgets for more advanced stuff.

[jdemeyer]

comment:12

The documentation of layout in sagenb says this:

        - ``layout`` - a dictionary with keys
          'top','bottom','left','right' and values lists of rows of
          control variable names.  If a dictionary is not passed in,
          then the value of layout is set to the 'top' value.  If
          ``None``, then all control names are put on separate rows in
          the 'top' value.

I don't understand what this is saying. If somebody can explain me how exactly the layout parameter works, then I might consider working on this.

In Sage Cell, the layout parameter is actually undocumented.

[kcrisman]

comment:13

It's easier to see in action. Try this in a Sage notebook (not Sage cell, as it indeed doesn't work right). I'll try to upload pictures shortly.

@interact(layout={'top': [['a', 'b']], 'left': [['c']], 'bottom': [['d']], 'right':[['e'],['f']]})
def _(a=x^2, b=[0..20], c=100, d=x+1, e=3, f=5):
    print(a+b+c+d+e+f)

[jdemeyer]

comment:14

Replying to @kcrisman:

not Sage cell, as it indeed doesn't work right

Given that it doesn't work in Sage Cell nor in Jupyter and given that it's barely used, is it really worth supporting?

[kcrisman]

comment:15

Well, it does work in Sage cell, just not correctly. The 'top parameter does work, I should point out. Maybe that would be a start. Whether it's "barely used" is very difficult to ascertain, but that discussion is in previous comments on this ticket. I also mentioned this in a thread on the [ sage-cell list], though obliquely. I'll upload pictures now.

[kcrisman]

Attachment: Screen Shot 2018-03-29 at 10.02.23 AM.png

CoCalc more or less works

[kcrisman]

Attachment: Screen Shot 2018-03-29 at 9.58.43 AM.png

sagenb version of layout

[novoselt]

comment:16

Regarding "barely used": over 16 months period out of 2.5M evaluations in SageMathCell 250K had "interact" in them. And I've mentioned above from personal experience, I never used interacts for research, but heavily for teaching.

As for different support/interface/documentation etc: it is indeed very frustrating but that's how I've inherited things and there were more pressing issues. Deprecating anything from SageNB is certainly possible, but having a working (and the same) alternative in !Jupyter/CoCalc is highly desirable. If it is done, I'll do my best to converge as well over the next year or two. My hope is that Jupyter support via ipywidgets will be relatively easy to utilize in SageMathCell.

[jdemeyer]

comment:17

Replying to @novoselt:

Regarding "barely used": over 16 months period out of 2.5M evaluations in SageMathCell 250K had "interact" in them.

I'm not saying that interacts are barely used, I'm saying that the layout keyword of interact is barely used.

[novoselt]

comment:18

Replying to @jdemeyer:

I'm not saying that interacts are barely used, I'm saying that the layout keyword of interact is barely used.

Fair enough:

$ wc /var/log/sagecell.stats.log 
   1446034  112102774 1427723122 /var/log/sagecell.stats.log
$ grep "interact" /var/log/sagecell.stats.log|wc
 139924 25490159 300694167
$ grep "interact" /var/log/sagecell.stats.log |grep "layout" |wc
  15287 6480767 75148560

So 10% of requests are interacts and 10% of interacts do use layout. Of course, that's just 1% of the total number.

[kcrisman]

comment:19

That's actually definitely nontrivial - more than I was expecting. So perhaps reasonable to support at least the top row in Jupyter, especially since CoCalc doesn't quite get it right beyond that (though better than Sage cell).

[embray]

comment:20

See https://ask.sagemath.org/question/47120/interact-layout-in-jupyter-notebook/?answer=47125#post-id-47125 for some thoughts on this.

[embray]

comment:21

After playing around with the old SageNB @interacts layout parameter, I see now that it's not really all that sophisticated, and could pretty easily be emulated if we supplied our own wrapper around ipywdigets' interact. Even better if we could update to the latest ipywidgets and use features like its GridLayout, though one can get by without it too.

Longer-term, it might be nice to simultaneously provide backwards compat for Sage's old layout= parameter, while also providing a way to map more sophisticated ipywidgets layouts into it. Of course, one can forgo the decorator interface entirely and build compound widgets with different layouts in an OOP fashion, as documented in the ipywidgets docs. But I believe for some simple cases you could also provide layout hints on a per-control basis to the @interact decorator in a declarative fashion. So in addition to supporting the legacy syntax of {'top': [...], 'bottom': [...], ...}, but also maybe with an approach that allows providing additional layout hints for each control, by name.