interactive widgets in the notebook
Jason Grout
Hi everyone,
I've been thinking about how to implement interactive widgets in the
notebook. Things like sliders, buttons, etc., that allow interactivity
like Maplets in Maple or the Manipulate command in Mathematica 6.
Here's an example of an interface:
sage: a=Slider(1,10)
sage: plot(sin(a()*x),-3,3)
and in the notebook would appear a slider labeled "a" and the graph
would appear below it. As the slider is moved between 1 and 10, the
plot updates dynamically, showing the frequency-scaling aspect of
different values of a.
Here's a brainstorm idea of how to do this. I don't know that much
about the notebook code or how evaluation works, so I don't know if this
is the way to do things, but here goes:
* There is a widget class hierarchy. Widget is the parent class and
under it are classes for different controls, like sliders, dials, 2-d
location pickers, etc. Each widget class has a __call__ method that
returns a value, so we just use a() like above to get the value of the
widget.
* Before an expression is evaluated in the notebook, an empty widget
list is created.
* In the evaluation, if any widget is encountered (i.e., asked for its
value), then it puts a copy of itself in the widget list. It returns
some default value.
* Before displaying the result of the expression, the notebook creates
javascript widgets corresponding to the widgets in the list. We could,
for example, use the jquery ui library or some other widget library.
* Anytime a widget is updated (e.g., a slider is moved), the widget
value is updated and the expression is reevaluated.
For comparison, here would be the Mathematica 6 syntax for something
like the above example:
Manipulate[Plot[Sin[a*x],{x,-3,3}], {a,1,10}]
or
Plot[Sin[a*x], {x,-3,3}] // Manipulate[#, {a,1,10}] &
Thoughts or ideas? I have no clue how to actually implement this in the
framework that we have for evaluating expressions.
I think something like this would go a long way to making Sage useful in
the classroom.
Performance might be a problem. In that case, we could eventually have
some command that would cache the output of the expression for different
widget values so the update would be faster.
Thanks,
Jason
William Stein
I'm pretty excited about this! I think it would be extremely amazingly
useful if you could make up some more examples like this one
sage: a = Slider(1,10)
sage: plot(sin(a()*x),-3,3)
and explain what they would do. Also, if we could make it more like
sage: a = Slider([1..10])
i.e., have a discrete range as input, then doing caching would be easier.
> I think something like this would go a long way to making Sage useful in
> the classroom.
Definitely.
> Performance might be a problem. In that case, we could eventually have
> some command that would cache the output of the expression for different
> widget values so the update would be faster.
Performance without caching would be a major problem. Performance with
caching could be excellent. E.g., in the above example we could autoload
all 10 images, so that no communication with sage at all would be required,
and scrolling would be instant.
Please please post several examples of what you imagine doing with this,
which is the perfect first step. Try to include examples that involve
all the different controls that mathematica supports.
-- William
David Harvey
On Nov 17, 2007, at 7:41 PM, William Stein wrote:
> I'm pretty excited about this! I think it would be extremely
> amazingly
> useful if you could make up some more examples like this one
>
> sage: a = Slider(1,10)
> sage: plot(sin(a()*x),-3,3)
Why not just
> plot(sin(a*x),-3,3)
instead of
> plot(sin(a()*x),-3,3)
?
david
Jason Grout
Your first example is what I was originally thinking. It would be
simpler. I wasn't sure how it would work to have a slider object
multiplied by something, etc. I figured in the end that rather than
rewrite all the multiplication, addition, subtraction, etc., it'd be
easier to have the __call__ method in "a" return whatever the current
value of "a" was, and then let Sage take care of how to use that value
in the expression.
Can we have "a" be a Slider object and have a*something (or a+something,
etc.) make sense without rewriting a bunch of code to have operations
work with Widget objects?
Can we just attach a "widget" property to any object in Sage? That way
"a" could be, say, a number, but it would have a "a.widget" which would
encapsulate the necessary widget functionality? I think this would be
much more complicated.
-Jason
Jason Grout
> On Sat, 17 Nov 2007 09:29:27 -0800, Jason Grout <jason...@creativetrax.com> wrote:
>
> I'm pretty excited about this! I think it would be extremely amazingly
> useful if you could make up some more examples like this one
>
> sage: a = Slider(1,10)
> sage: plot(sin(a()*x),-3,3)
>
> and explain what they would do. Also, if we could make it more like
>
> sage: a = Slider([1..10])
>
> i.e., have a discrete range as input, then doing caching would be easier.
Here are a few more examples. You can look at the Manipulate help page
at http://reference.wolfram.com/mathematica/ref/Manipulate.html for
examples of the Mathematica command.
Slider(list) creates a slider on the list. For example,
Slider([1..10,step=.01]) creates a slider that goes from 1 to 10 on the
list.
Slider([0,pi/3,pi/2,2*pi/3,pi]) creates a slider that takes on values of
pi (note that these are symbolic values, rather than numeric values).
Slider([sin,cos,tan]) creates a slider that changes the function
Examples:
sage: a=Slider([1..10,step=.01])
sage: sin(a()) # outputs the sin of the slider.
sage: a=Slider([0,pi/3,pi/2,2*pi/3,pi])
sage: sin(a()) # outputs the sin of various fractions of pi.
sage: b=Slider([sin,cos,tan])
sage: (b())(a()) # Two sliders, the first selects the function and the
second selects the fraction of pi.
sage: a=Slider([1..10])
sage: a()! # Compute the factorial of the selected number.
PlaneSlider(list,list) selects from the cartesian product of the lists.
This can be used to select a point on a plane. The control presents a
small rectangle with a dot in it. You drag the dot to select a
different point.
sage: a=PlaneSlider([1..10],[1,10]) # a grid
sage: some_function_that_takes_a_point(a()) # what function would take a
list of two elements?
Checkbox() returns true or false.
sage: showtangent = Checkbox()
sage: point=Slider([0..3,step=.1])
sage: p=plot(sin(x),0,3)
# the following command shows the tangent line at the x-value given by
the point slider if the tangent checkbox is checked.
sage: if(showtangent):
(p+plot(sin(point())+cos(point())*(x-point()),0,3)).show()
else:
p.show()
Buttons(list) makes a list of buttons, only one of which can be
selected. We could also make a RadioButton(list) widget.
sage: a=Buttons([sin,cos,tan])
sage: plot((a())(x),0,3).show() # Shows the selected function
Textbox() makes a user textbox. Hmmm, we should probably make an
optional validation function for this one!
sage: a=Textbox(default="sin")
sage: plot(eval(a())(x),0,3).show() # plots the function entered into
the text box.
ColorChooser() makes a color chooser.
sage: a=ColorChooser(default="blue")
sage: plot(sin(x),0,3,color=a()).show() # I don't know how to set the
color of a plot!
>> Performance might be a problem. In that case, we could eventually have
>> some command that would cache the output of the expression for different
>> widget values so the update would be faster.
>
> Performance without caching would be a major problem. Performance with
> caching could be excellent. E.g., in the above example we could autoload
> all 10 images, so that no communication with sage at all would be required,
> and scrolling would be instant.
>
> Please please post several examples of what you imagine doing with this,
> which is the perfect first step. Try to include examples that involve
> all the different controls that mathematica supports.
These aren't all of the controls in Mathematica (I think there's a menu
control, for example). It also doesn't touch on the "Dynamic" command
which is much more powerful.
Here are some more references from Mathematica:
http://reference.wolfram.com/mathematica/tutorial/IntroductionToManipulate.html
http://reference.wolfram.com/mathematica/tutorial/IntroductionToDynamic.html
to be continued...
-Jason
William Stein
\> >> I'm pretty excited about this! I think it would be extremely
> >> amazingly
> >> useful if you could make up some more examples like this one
> >>
> >> sage: a = Slider(1,10)
> >> sage: plot(sin(a()*x),-3,3)
> >
> > Why not just
> >
> >> plot(sin(a*x),-3,3)
> >
> > instead of
> >
> >> plot(sin(a()*x),-3,3)
>
>
> Your first example is what I was originally thinking. It would be
> simpler. I wasn't sure how it would work to have a slider object
> multiplied by something, etc. I figured in the end that rather than
> rewrite all the multiplication, addition, subtraction, etc., it'd be
> easier to have the __call__ method in "a" return whatever the current
> value of "a" was, and then let Sage take care of how to use that value
> in the expression.
>
> Can we have "a" be a Slider object and have a*something (or a+something,
> etc.) make sense without rewriting a bunch of code to have operations
> work with Widget objects?
I think the simplest thing to implement would be something like this (which
would be in the notebook):
<arbitrary html form named "foo" with widgets, sliders, etc., that
anybody who knows
html could layout and create. various form objects are named>
{{{
%form foo
a = %dom['slider']
b = %dom['button']
// Arbitrary Sage code that might use a and b to draw things, etc.
}}}
When the page is rendered to html, a cell starting with "%form foo" would
be tied to some even for the foo form. The lines a = %dom['slider'], etc.,
would be preparsed in javascript to set the variables a and b to the values
of the corresponding DOM elements (where DOM = Document Object
Model). Then the remaining aribitrary Sage code would be executed
and the output box be displayed.
This doesn't account at all for caching.
It's really just the first stupid naive idea I have about how to
actually implement
something dynamic in the notebook. I look forward to somebody suggesting
a much better idea. :-) Hey Tom Boothby, shouldn't you chime up about now?
William
> Can we just attach a "widget" property to any object in Sage? That way
> "a" could be, say, a number, but it would have a "a.widget" which would
> encapsulate the necessary widget functionality? I think this would be
> much more complicated.
>
> -Jason
>
>
>
> >
>
--
William Stein
Associate Professor of Mathematics
University of Washington
http://wstein.org
Ondrej Certik
>
>
> Hi everyone,
>
> I've been thinking about how to implement interactive widgets in the
> notebook. Things like sliders, buttons, etc., that allow interactivity
> like Maplets in Maple or the Manipulate command in Mathematica 6.
This functionality will be very useful indeed.
Ondrej
Jason Grout
Doing things this way (keeping the widgets and associated variables in
the notebook on a per-cell basis instead of making them definable and
accessible from the Sage command line) avoids the following issue.
If, for example, we have
sage: x=Slider([1..10])
sage: x()
Then what I said originally should mean that the output of the second
command contains a slider for x and underneath that the value of x. As
you change the slider, the value of x changes.
However, what if you then say:
sage: x.value = 3
Should the slider representing x and the value above automatically
change to 3? It seems that they should, but my implementation won't do
this since the first two lines are not re-examined and changed.
Also, if you then do another
sage: x()
and change the slider, can the notebook know to evaluate all the
expressions with x() in them and update them if we change the slider?
I read a bit more of the docs behind the Manipulate function and the
dynamic features in Mathematica 6. I'll try to summarize what I understand.
In Mathematica, the basic new functionality we are discussing is
contained in the Dynamic and DynamicModule commands. Typing
"Dynamic[x]" will output the current value of x and the output is
changed as x changes throughout the program. Mathematica is smart about
this, though, and doesn't update things that are not visible, so you
don't see a performance penalty for a complex graphic based on x that is
not in view, for example. Also, the output is updated only every 0.2
seconds (and is configurable), so outputting Dynamic[x] while x is being
reset in a tight loop, for example, will not update x for every run
through the loop. The updating happens on a different, higher-priorty
thread than the main computation. Thus, even while a computation is
running, the frontend can ask for the value of a variable or the value
of a dynamic computation and the kernel will put things on hold, do the
frontend computation, and then pick up where it left off. Also, you can
have Mathematica return a short computation while a variable is being
continuously updated (like a slider being dragged) and a final longer
computation once the variable has settled down. Mathematica uses this
in the plots---computing an approximate plot with just a few triangles
while a slider is being dragged, but then the full plot when a slider is
released.
Of course, having Dynamic[x] can be awfully confusing if you then use x
for something else in the program (all your previous results using
Dynamic[x] will change!). The DynamicModule command lets you create
local variables that are used in the Dynamic command. That means that
executing DynamicModule[{x},Dynamic[Sin[x]]] twice will use different
local variables (these are generated using a gensym functionality from
the frontend). These two commands, for example, are translated (behind
the user's back) to:
Dynamic[Sin[x$1]] and Dynamic[Sin[x$2]], where x$1 and x$2 are the names
of the local variables.
Thus the Manipulate command Manipulate[Sin[x],{x,1,10}] is (greatly
simplified to) DynamicModule[{x},f[x]]] where f[x] is a function that
creates a Slider with value x (Slider[Dynamic[x]]) and an output cell
containing Dynamic[Sin[x]]. In other words, the variable is not the
slider, but the slider is just another function that provides a
graphical way to view the value of a variable and to set the variable
(and in this case, the slider is the only way to access and set the
variable). All the heavy lifting is done with the Dynamic command.
So, all in all, having the Manipulate functionality is just scratching
the surface of the much more general and powerful Dynamic command.
However, the functionality of Manipulate will probably get used much
more often in classrooms than the full power of the Dynamic command.
So what can we do? I think the heavy lifting of the Dynamic command is
beyond our reach with our current interface. Is there enough smarts in
the javascript to be able to optimize which outputs to update and how
often to update them, even while another computation is running? I
don't think so. However, we can implement something like the Manipulate
command. I think William's idea is the way to go: make the variable
equal to a slider in the front end and make that variable local to one
input cell. The only way to change the variable would be to move the
slider in the front end. You could use the variable (read only) in SAGE
commands. When a command is typed into the notebook, the notebook first
substitutes in any widget variables, and then passes the computation
back to Sage to compute. Doing things this way (keeping the widget
variables only in the interface) avoids the much more difficult task of
basically implementing the Dynamic command using our current setup.
Thoughts?
-Jason
Jason Grout
some more brainstorming.
Jason Grout wrote:
> command. I think William's idea is the way to go: make the variable
> equal to a slider in the front end and make that variable local to one
> input cell. The only way to change the variable would be to move the
> slider in the front end. You could use the variable (read only) in SAGE
> commands. When a command is typed into the notebook, the notebook first
> substitutes in any widget variables, and then passes the computation
> back to Sage to compute. Doing things this way (keeping the widget
> variables only in the interface) avoids the much more difficult task of
> basically implementing the Dynamic command using our current setup.
First, I think that any variable bound to an interactive widget ought to
be local to the cell and should be treated as read-only in the cell
code. This avoids the problem of updating the menu to reflect the
current value of the variable if it is changed in the code or in another
cell. Would it be easy to make a variable local to a cell?
Here is another example of another syntax and the steps that should happen.
{{{
Menu("func",[sin,cos,tan])
plot(func(x)).show()
}}}
would:
1. Create a variable (local to the cell) named func and somehow store
the list [sin,cos,tan] (we'll call the list "values" here) and do:
sage: func=values[0]
2. Output the HTML needed to render a dropdown menu with the items of
values as the choices (sin, cos, tan). The HTML code would include the
necessary AJAX stuff to execute "func=values[i]" and reevaluate the cell
if the selection was changed to the ith option.
3. Evaluate the rest of the cell.
Thoughts? Is this "easy" to implement?
-Jason
Ted Kosan
> I've been thinking about how to implement interactive widgets in the
> notebook. Things like sliders, buttons, etc., that allow interactivity
> like Maplets in Maple or the Manipulate command in Mathematica 6.
What do you think about adding capabilities like the following to SAGE?:
Ted
Jason Grout
I think something like this was the goal of the work done by Robert with
the 3d graph viewer in Java that is (or at least, was) included in Sage.
I think JavaView was looked at before and had some licensing
restrictions (so couldn't be included in Sage), but others more
knowledgeable than me can give better responses.
-Jason
Ted Kosan
> I think something like this was the goal of the work done by Robert with
> the 3d graph viewer in Java that is (or at least, was) included in Sage.
> I think JavaView was looked at before and had some licensing
> restrictions (so couldn't be included in Sage), but others more
> knowledgeable than me can give better responses.
I wasn't thinking about using JavaView (due to its licensing issues).
I was interested in the level of excellence it was able to achieve
with the approach it took. I can't help but think that programs like
JavaView have set the benchmark for interactive mathematics graphics
capabilities so high that approaches using JavaScript in a browser are
unable to even come close to them.
So, if the goal is to add excellent interactive GUI widget
capabilities to SAGE, why not use a technology that has been proven to
work extremely well with this type of application? :-)
Ted
Robert Bradshaw
That is the (lofty!) goal. Take a look at sage/plot/plot3d/* to see a
start, though much remains to be done. (I am speaking in terms of
emulating JavaView, not the interactive stuff, though it could
eventually go there too.)
- Robert
Ted Kosan
> That is the (lofty!) goal. Take a look at sage/plot/plot3d/* to see a
> start, though much remains to be done. (I am speaking in terms of
> emulating JavaView, not the interactive stuff, though it could
> eventually go there too.)
As a step towards something like JavaView, I have been experimenting
with JMathTools:
http://jmathtools.sourceforge.net
It is not as sophisticated as JavaView, but it has fairly nice 2D and
3D viewing capabilities and the 3D is lighter weight than Java3D.
I have JMathTools running in SAGEIDE and I have SAGEIDE communicating
with SAGE using text and pickled objects (via Jython). I am not able
to send SAGE types to the client at this point (only Python types) but
perhaps in the future parts of SAGE can be loaded into the client's
Jython environment to enable this.
I really like the technique of using Jython in the client because its
like having a subset of SAGE on the client. Users can easily create
GUI widgets with just a few lines of "SAGE" code. Jython can be
included in an applet too.
Anyway, I have studied sage/plot/plot3d/* in the past but now I think
I will study it again to see what kind of SAGE/client communications
mechanism it uses.
Ted
Robert Bradshaw
> Robert wrote:
>
>> That is the (lofty!) goal. Take a look at sage/plot/plot3d/* to see a
>> start, though much remains to be done. (I am speaking in terms of
>> emulating JavaView, not the interactive stuff, though it could
>> eventually go there too.)
>
> As a step towards something like JavaView, I have been experimenting
> with JMathTools:
>
> http://jmathtools.sourceforge.net
>
> It is not as sophisticated as JavaView, but it has fairly nice 2D and
> 3D viewing capabilities and the 3D is lighter weight than Java3D.
Never seen that before, it looks pretty nice, and is BSD licensed. We
looked around a lot about a year ago for open-source 3d applets but I
never saw this. Can it graph arbitrary 3d shapes/polygons? It doesn't
feel OpenGL accelerated, but I could be wrong.
> I have JMathTools running in SAGEIDE and I have SAGEIDE communicating
> with SAGE using text and pickled objects (via Jython). I am not able
> to send SAGE types to the client at this point (only Python types) but
> perhaps in the future parts of SAGE can be loaded into the client's
> Jython environment to enable this.
>
> I really like the technique of using Jython in the client because its
> like having a subset of SAGE on the client. Users can easily create
> GUI widgets with just a few lines of "SAGE" code. Jython can be
> included in an applet too.
That is a good point. How big is Jython? I wouldn't be surprised if
extension types were incompatible with Jython, which would rule out
almost all Sage objects.
> Anyway, I have studied sage/plot/plot3d/* in the past but now I think
> I will study it again to see what kind of SAGE/client communications
> mechanism it uses.
There is virtually no sage/client communication in this code. Sage
spits out a 3d object (in a standard .obj file) and the applet reads
it in via a URL.
- Robert
Jason Grout
> Robert wrote:
>
>> That is the (lofty!) goal. Take a look at sage/plot/plot3d/* to see a
>> start, though much remains to be done. (I am speaking in terms of
>> emulating JavaView, not the interactive stuff, though it could
>> eventually go there too.)
>
> As a step towards something like JavaView, I have been experimenting
> with JMathTools:
>
> http://jmathtools.sourceforge.net
>
> It is not as sophisticated as JavaView, but it has fairly nice 2D and
> 3D viewing capabilities and the 3D is lighter weight than Java3D.
>
> I have JMathTools running in SAGEIDE and I have SAGEIDE communicating
> with SAGE using text and pickled objects (via Jython). I am not able
> to send SAGE types to the client at this point (only Python types) but
> perhaps in the future parts of SAGE can be loaded into the client's
> Jython environment to enable this.
>
> I really like the technique of using Jython in the client because its
> like having a subset of SAGE on the client. Users can easily create
> GUI widgets with just a few lines of "SAGE" code. Jython can be
> included in an applet too.
This is interesting. Can you expand on how you see Jython being used in
the client (or how you already are using it), with maybe some
hypothetical examples of creating GUI widgets or other things?
-Jason
Ted Kosan
> Never seen that before, it looks pretty nice, and is BSD licensed. We
> looked around a lot about a year ago for open-source 3d applets but I
> never saw this. Can it graph arbitrary 3d shapes/polygons? It doesn't
> feel OpenGL accelerated, but I could be wrong.
I think it can plot arbitrary 3d shapes and polygons but it does not
appear to be OpenGL accelerated.
>> I really like the technique of using Jython in the client because its
>> like having a subset of SAGE on the client. Users can easily create
>> GUI widgets with just a few lines of "SAGE" code. Jython can be
>> included in an applet too.
>
>That is a good point. How big is Jython.
The size of the jython.jar file is 1204789 bytes.
>I wouldn't be surprised if
> extension types were incompatible with Jython, which would rule out
> almost all Sage objects.
Correct, C-based extension types do not work with Jython.
> There is virtually no sage/client communication in this code. Sage
> spits out a 3d object (in a standard .obj file) and the applet reads
> it in via a URL.
This gives me the idea of making pickled Python objects available to
the client via a URL.
Ted
Jason Grout
>
> Hi everyone,
>
> I've been thinking about how to implement interactive widgets in the
> notebook. Things like sliders, buttons, etc., that allow interactivity
> like Maplets in Maple or the Manipulate command in Mathematica 6.
> Here's an example of an interface:
>
> sage: a=Slider(1,10)
> sage: plot(sin(a()*x),-3,3)
>
> and in the notebook would appear a slider labeled "a" and the graph
> would appear below it. As the slider is moved between 1 and 10, the
> plot updates dynamically, showing the frequency-scaling aspect of
> different values of a.
Yeah! It works!! :)
I've put a very alpha patch (against 2.8.13) up on trac #1322 that
implements the following:
sage: from sage.server.notebook.widgets.menu import menu
sage: menu('f', [sin, cos, tan] ).show()
(a select box menu is shown with sin, cos, and tan as options. Pick a
value for f. And that means that at this point, you really do need to
pick a value for f that is different from the initial value.)
sage: plot(f(x),0,2*pi).show()
(the plot of f(x) (with the selected f) is shown.)
There is a huge list of disclaimers/todo things in the comments of
#1322. However, this initial alpha-quality patch gives an idea of the
functionality and an idea of how to do it.
Have a great day,
-Jason
Ted Kosan
> Yeah! It works!! :)
>
> I've put a very alpha patch (against 2.8.13) up on trac #1322 that
> implements the following:
I got it to work and I must admit its pretty cool!
I'm going to have to think about the possibilities you have opened up
with this approach.
Ted
Jason Grout
Well, it was a big hack and it's not very pretty the way things work,
but the end result is sort of the idea of what I was going for. I've
spent a lot more time thinking about this and I think it's going to be a
hard thing to do nicely. William and others pointed out some of the
difficulties (and impossibilities!) in at least the way I was wanting to
approach things. I'm definitely going to have to think about things
more too.
At least now we have something of a starting point :). I think this is
going to end up being a rather long-term project (at least to do nicely).
-Jason
Ted Kosan
> > I really like the technique of using Jython in the client because its
> > like having a subset of SAGE on the client. Users can easily create
> > GUI widgets with just a few lines of "SAGE" code. Jython can be
> > included in an applet too.
>
> This is interesting. Can you expand on how you see Jython being used in
> the client (or how you already are using it), with maybe some
> hypothetical examples of creating GUI widgets or other things?
After further research I discovered that a Jython Applet loaded from a
remote server is unable to execute code entered by the user because of
security restrictions. I am going to have to study this issue
further.
As for examples of how to use GUI widgets in the client, the 3D Applet
demo I posted a little bit ago shows some of what I am thinking about.
Perhaps the user wants a slider for changing the zoom level instead
of a drawn rectangle. They could create a slider, hook it to the zoom
object, and add the slider to the GUI with a few lines of code.
Another applet I have been thinking about is a SAGE "dashboard" that
would show in realtime all the objects a user has created in the
current worksheet, all symbolic variables, the state of all executing
cells, etc. The user could then add custom widgets and logic to this
applet to suit their needs.
Anyway, I think coming up with concrete examples will be easier after
the communications mechanism between applets and the SAGE server has
been determined.
Ted
Jason Grout
> Jason wrote:
>
>>> I really like the technique of using Jython in the client because its
>>> like having a subset of SAGE on the client. Users can easily create
>>> GUI widgets with just a few lines of "SAGE" code. Jython can be
>>> included in an applet too.
>> This is interesting. Can you expand on how you see Jython being used in
>> the client (or how you already are using it), with maybe some
>> hypothetical examples of creating GUI widgets or other things?
>
> After further research I discovered that a Jython Applet loaded from a
> remote server is unable to execute code entered by the user because of
> security restrictions. I am going to have to study this issue
> further.
>
> As for examples of how to use GUI widgets in the client, the 3D Applet
> demo I posted a little bit ago shows some of what I am thinking about.
> Perhaps the user wants a slider for changing the zoom level instead
> of a drawn rectangle. They could create a slider, hook it to the zoom
> object, and add the slider to the GUI with a few lines of code.
>
> Another applet I have been thinking about is a SAGE "dashboard" that
> would show in realtime all the objects a user has created in the
> current worksheet, all symbolic variables, the state of all executing
> cells, etc. The user could then add custom widgets and logic to this
> applet to suit their needs.
>
Didn't the old version of the notebook do at least some of this? See
the screenshot at:
http://sagemath.org/screen_shots/.html/factor-bigdeg.html
and some of the other screenshots at:
http://sagemath.org/screen_shots/
It appears that current variables and other objects were listed. It's
been a while, though, so I don't remember exactly what was in the left
column.
Why don't we have the old functionality now, maybe in a collabsible
sidebar or something. (or is it there and I just missed it?)
> Anyway, I think coming up with concrete examples will be easier after
> the communications mechanism between applets and the SAGE server has
> been determined.
I agree that a communication mechanism is one of the first steps in all
of this.
-Jason
William Stein
> > As for examples of how to use GUI widgets in the client, the 3D Applet
> > demo I posted a little bit ago shows some of what I am thinking about.
> > Perhaps the user wants a slider for changing the zoom level instead
> > of a drawn rectangle. They could create a slider, hook it to the zoom
> > object, and add the slider to the GUI with a few lines of code.
> >
> > Another applet I have been thinking about is a SAGE "dashboard" that
> > would show in realtime all the objects a user has created in the
> > current worksheet, all symbolic variables, the state of all executing
> > cells, etc. The user could then add custom widgets and logic to this
> > applet to suit their needs.
> >
>
> Didn't the old version of the notebook do at least some of this? See
> the screenshot at:
>
> http://sagemath.org/screen_shots/.html/factor-bigdeg.html
>
> and some of the other screenshots at:
>
> http://sagemath.org/screen_shots/
>
> It appears that current variables and other objects were listed. It's
> been a while, though, so I don't remember exactly what was in the left
> column.
Yes, the original version of the notebook did that. Nobody really liked
it very much, and it greatly reduced the general "snappiness" of the
notebook. It was a feature that I had implemented, then removed, and
there wasn't much in the way of complaint when it vanished (especially
since things were much snappier afterwards).
> Why don't we have the old functionality now, maybe in a collabsible
> sidebar or something. (or is it there and I just missed it?)
Because it is slow and cumbersome and error prone.
William