Hi all,
sorry for kind of flooding this group, but I'm very eager to learn.
I'd like to understand how to add another javascript script to the
notebook. In particular, I'd like to test FLOT for interactive
plotting.
The problem is that I am unable to call another script from the
notebook, because I cannot find a suitable version of the source to
work with.
My intention is doing something similar to what jsMath (as far as I
understood the code) does: launch a function which returns even a
simple text string, that should become the argument of the script
launcher.
I'd like to avoid passing through file saving and html() command (that
was the first try, but doesn't seem so polite).
Is there another way to do it? I mean, a way that could allow us to
make an spkg at the end, so something that doesn't need to modify the
notebook code?
Maurizio wrote: > Hi all, > sorry for kind of flooding this group, but I'm very eager to learn.
> I'd like to understand how to add another javascript script to the > notebook. In particular, I'd like to test FLOT for interactive > plotting.
> The problem is that I am unable to call another script from the > notebook, because I cannot find a suitable version of the source to > work with.
> My intention is doing something similar to what jsMath (as far as I > understood the code) does: launch a function which returns even a > simple text string, that should become the argument of the script > launcher.
> I'd like to avoid passing through file saving and html() command (that > was the first try, but doesn't seem so polite).
> Is there another way to do it? I mean, a way that could allow us to > make an spkg at the end, so something that doesn't need to modify the > notebook code?
You could do something like the tinymce plugin, or the jsmath_imagefonts spkg. Basically, test for the existence of the spkg, and then do the FLOT plotting if the spkg exists. You can see an example in the code for jsmath_imagefonts, I believe, in the top of notebook.py.
Sometimes the plotting function in Sage are quite annoying , I've just
looked at the FLOT package and it seems very promising. Hope to
find soon a package to easily include flot into sage notebook!
Would be nice to have a pop-up windows that include the graphic and
be able to interact with it from the notebook with some commands
similar to the ones used in matlab.
I know this not an answer to your question but... keep working it will
be
helpful for a lot of people!
On Feb 23, 12:11 pm, Maurizio <maurizio.gran...@gmail.com> wrote:
> Hi all,
> sorry for kind of flooding this group, but I'm very eager to learn.
> I'd like to understand how to add another javascript script to the
> notebook. In particular, I'd like to test FLOT for interactive
> plotting.
> The problem is that I am unable to call another script from the
> notebook, because I cannot find a suitable version of the source to
> work with.
> My intention is doing something similar to what jsMath (as far as I
> understood the code) does: launch a function which returns even a
> simple text string, that should become the argument of the script
> launcher.
> I'd like to avoid passing through file saving and html() command (that
> was the first try, but doesn't seem so polite).
> Is there another way to do it? I mean, a way that could allow us to
> make an spkg at the end, so something that doesn't need to modify the
> notebook code?
Actually, I can't check for any spkg existence, since there isn't any
(still...). What I want, is to plugin another javascript (flot) in my
notebook basically, and then make it load from the notebook itself,
passing some data (vectors of point, for 2d plotting) without having
to use intemediate html() function (I think that would make too much
overhead, isn't it?)
Could you please be a little bit more precise to show me where to look
at for an example?
I would be very grateful for that!
Once I get a readable example, I think I could go along by myself.
thanks
Maurizio
On Feb 23, 12:31 pm, Jason Grout <jason-s...@creativetrax.com> wrote:
> Maurizio wrote:
> > Hi all,
> > sorry for kind of flooding this group, but I'm very eager to learn.
> > I'd like to understand how to add another javascript script to the
> > notebook. In particular, I'd like to test FLOT for interactive
> > plotting.
> > The problem is that I am unable to call another script from the
> > notebook, because I cannot find a suitable version of the source to
> > work with.
> > My intention is doing something similar to what jsMath (as far as I
> > understood the code) does: launch a function which returns even a
> > simple text string, that should become the argument of the script
> > launcher.
> > I'd like to avoid passing through file saving and html() command (that
> > was the first try, but doesn't seem so polite).
> > Is there another way to do it? I mean, a way that could allow us to
> > make an spkg at the end, so something that doesn't need to modify the
> > notebook code?
> You could do something like the tinymce plugin, or the jsmath_imagefonts
> spkg. Basically, test for the existence of the spkg, and then do the
> FLOT plotting if the spkg exists. You can see an example in the code
> for jsmath_imagefonts, I believe, in the top of notebook.py.
Kenny wrote:
> Is there any good reason for using flotr, protochart or any other
> instead of flot??
I don't know. In order to standardize on flot or anything else, though, someone needs to post a message to sage-devel calling for a vote and explaining why the proposed package is better than anything else, etc. Having a prototype of something working would be advantageous for letting people try it out before voting.
On Feb 23, 9:00 am, Jason Grout <jason-s...@creativetrax.com> wrote:
> Kenny wrote:
> > Is there any good reason for using flotr, protochart or any other
> > instead of flot??
> I don't know. In order to standardize on flot or anything else, though,
> someone needs to post a message to sage-devel calling for a vote and
> explaining why the proposed package is better than anything else, etc.
> Having a prototype of something working would be advantageous for
> letting people try it out before voting.
I don't think we are quite there yet. It seems that all the javascript
based plotting code seems to require canvas support (or at least takes
advantage of it), so IE support might be an issue here. I also fail to
see yet why this is significantly better and/or not achievable with
MPL and/or jmol. I am all for experimenting to see what is possible,
but I would not be in favor of adding another 2D plotting library to
Sage while we have MPL.
That is obviously taking about standard Sage. A hook into the notebook
code to check if some of the above libraries is installed via some
optional library seems more than reasonable.
Maurizio wrote: > Jason, > thank you for your quick response.
> Actually, I can't check for any spkg existence, since there isn't any > (still...). What I want, is to plugin another javascript (flot) in my > notebook basically, and then make it load from the notebook itself, > passing some data (vectors of point, for 2d plotting) without having > to use intemediate html() function (I think that would make too much > overhead, isn't it?)
> Could you please be a little bit more precise to show me where to look > at for an example? > I would be very grateful for that!
> Once I get a readable example, I think I could go along by myself.
Maurizio,
I think that I would start out by getting a working example using html(), so that other people could easily try it. Here's what I would do:
* upgrade to sage 3.3, since a lot of the locations of javascript things changed in 3.3.
* Put the javascript library into $SAGE_ROOT/local/notebook/javascript (you can see the other javascript libraries are in that directory too).
(/javascript_local is mapped to $SAGE_ROOT/local/notebook/javascript)
* Do an example using html() to load the javascript library and call the necessary javascript functions. This keeps everything in the notebook so people get a feel for how to interact with the library, and it saves you from having to dig into the internals of how Sage Graphics objects are displayed.
> On Feb 23, 9:00 am, Jason Grout <jason-s...@creativetrax.com> wrote: >> Kenny wrote: >>> Is there any good reason for using flotr, protochart or any other >>> instead of flot?? >> I don't know. In order to standardize on flot or anything else, though, >> someone needs to post a message to sage-devel calling for a vote and >> explaining why the proposed package is better than anything else, etc. >> Having a prototype of something working would be advantageous for >> letting people try it out before voting.
> I don't think we are quite there yet. It seems that all the javascript > based plotting code seems to require canvas support (or at least takes > advantage of it), so IE support might be an issue here. I also fail to > see yet why this is significantly better and/or not achievable with > MPL and/or jmol. I am all for experimenting to see what is possible, > but I would not be in favor of adding another 2D plotting library to > Sage while we have MPL.
> That is obviously taking about standard Sage. A hook into the notebook > code to check if some of the above libraries is installed via some > optional library seems more than reasonable.
Right now, I think the best solution for us would be some sort of html canvas backend for matplotlib. However, I haven't looked closely at the javascript plotters (just played with them for a bit).
Michael,
I understand your comments, but my desire to include something like
Flot comes from the need of having dynamic zooming and panning, and
tooltips and something else like that. Is this possible with
matplotlib? I didn't find the way to do it.
On the contrary, even the simplest javascript plot library allows for
these features, but they obviously lack in other areas.
For example, my first intention was to have the bode plots
implemented, to make them easily browsable, but I discovered that none
of these js plotting packages have the semilog or loglog option, and
making it work was quite a pain...
Today we (Kenny and me) have a working alpha. It is unfinished, but we
think that these added capabilities show the possible advantages, if
someone wants to work a little bit on that. In this case, in my
opinion, we are not talking about doing the same thing with two
overlapping packages. On the contrary, we are addressing two
completely different issues. Infact, we will probably stay with MPL as
far as saving PNG are concerned (probably the best way to incorporate
plots in the notebook), but certainly go with this FLOT when working
within the browser.
We hope to send you some example ASAP, so that you can judge yourself
and the decide what to do.
Regards
Maurizio
On Feb 23, 6:32 pm, mabshoff <mabsh...@googlemail.com> wrote:
> On Feb 23, 9:00 am, Jason Grout <jason-s...@creativetrax.com> wrote:
> > Kenny wrote:
> > > Is there any good reason for using flotr, protochart or any other
> > > instead of flot??
> > I don't know. In order to standardize on flot or anything else, though,
> > someone needs to post a message to sage-devel calling for a vote and
> > explaining why the proposed package is better than anything else, etc.
> > Having a prototype of something working would be advantageous for
> > letting people try it out before voting.
> I don't think we are quite there yet. It seems that all the javascript
> based plotting code seems to require canvas support (or at least takes
> advantage of it), so IE support might be an issue here. I also fail to
> see yet why this is significantly better and/or not achievable with
> MPL and/or jmol. I am all for experimenting to see what is possible,
> but I would not be in favor of adding another 2D plotting library to
> Sage while we have MPL.
> That is obviously taking about standard Sage. A hook into the notebook
> code to check if some of the above libraries is installed via some
> optional library seems more than reasonable.
Maurizio wrote: > Michael, > I understand your comments, but my desire to include something like > Flot comes from the need of having dynamic zooming and panning, and > tooltips and something else like that. Is this possible with > matplotlib? I didn't find the way to do it.
As I understand it, matplotlib can do those sorts of things with an interactive backend (i.e., wxwindows, gtk, qt, etc.). However, none of those work with the web-based notebook, but the pieces are there. It would be *cool* if someone would write the necessary javascript/canvas/html code to make those tools available in a "canvas" backend. Again, something like the gnuplot canvas backend. You might be able to even reuse code from the gnuplot canvas backend.
That said, it may be less effort to make an optional flot spkg. However, for advanced plotting and deep integration with Sage, as you are seeing, leveraging the power of matplotlib by just writing another backend may be the best way to go in the end.
I've looked at writing a matplotlib backend, and it didn't look extremely difficult. There are examples in the backends/ directory, and it looks like you can get a minimal backend up and running by just writing a few functions.
You're doing some great work on getting Flot working too! I think exploring the options is what is most valuable at this point. I just think that the matplotlib backend is one of the most valuable options that can be explored.
> Today we (Kenny and me) have a working alpha. It is unfinished, but we > think that these added capabilities show the possible advantages, if [snip]
> We hope to send you some example ASAP, so that you can judge yourself > and the decide what to do.
On Mon, Feb 23, 2009 at 8:55 AM, Kenny <masso.ke...@gmail.com> wrote:
> Is there any good reason for using flotr, protochart or any other > instead of flot??
Just wanted to point out some other libraries available. I was under the impression you just started looking at some way of doing this, but I see in emails from Maurizio in this thread that you have some code already with Flot. These are some of the libraries I have looked at before (some with 3D capabilities) to do some plotting for Axiom, but did not get to decide on one (including Flot). Good luck on your work.
Thank you very much for your encouragement.
Honestly, I totally second your idea that using the same matplotlib
would have probably been the best choice from the very first moment.
Please also keep in mind that I am not a software developer, and that
the time spent on this should be like an investment to speed up my
future work, but unfortunately I can't really work on this all day ;)
Before starting to write down some lines of code, we had a look at the
gnuplot Canvas page (http://skuld.bmsc.washington.edu/~merritt/gnuplot/ canvas_demos/ ) , and I was disappointed by not seeing a single
example (there are more than 20, I certainly not looked at them all),
about fast and useful interaction with the plots. I mean, apart from
enabling a grid, what's the big deal (from my point of view, as a
user) in having such a Canvas thing, if the result is having a static
image? What do I know that the interaction is still possible, if they
don't show in any way its possibilities? Panning, zooming, turning 3d
objects, and other stuff should be the real target in my opinion!
Have a look at the FLOT example page: http://people.iola.dk/olau/flot/examples/ . Apart from the very basic ones, the selection tool, zooming tool,
online enabling of series, etc, looks very attractive to my eyes!
Moreover, if it hadn't been for the fact of semilog or loglog plots,
the work of including the plot in the sage notebook was done by this
morning!!
So at the end of this long day, my thoughts are:
- FLOT is not so powerful, and the other derivatives (FLOTR,
Protochart, etc) don't seem to be any better ( I can hardly recognize
the differences), but still it is very fast to develop with in simple
cases
- matplotlib is obviously the most powerful and well integrated (my
previous bode plot function relied on matplotlib), but I have some
doubts about whether the rendering time would be small enough to
provide a sufficiently satisfying user experience
> As I understand it, matplotlib can do those sorts of things with an
> interactive backend (i.e., wxwindows, gtk, qt, etc.). However, none of
> those work with the web-based notebook, but the pieces are there. It
> would be *cool* if someone would write the necessary
> javascript/canvas/html code to make those tools available in a "canvas"
> backend. Again, something like the gnuplot canvas backend. You might
> be able to even reuse code from the gnuplot canvas backend.
> That said, it may be less effort to make an optional flot spkg.
> However, for advanced plotting and deep integration with Sage, as you
> are seeing, leveraging the power of matplotlib by just writing another
> backend may be the best way to go in the end.
> I've looked at writing a matplotlib backend, and it didn't look
> extremely difficult. There are examples in the backends/ directory, and
> it looks like you can get a minimal backend up and running by just
> writing a few functions.
> You're doing some great work on getting Flot working too! I think
> exploring the options is what is most valuable at this point. I just
> think that the matplotlib backend is one of the most valuable options
> that can be explored.
> > Today we (Kenny and me) have a working alpha. It is unfinished, but we
> > think that these added capabilities show the possible advantages, if
> [snip]
> > We hope to send you some example ASAP, so that you can judge yourself
> > and the decide what to do.
Maurizio wrote: > Thank you very much for your encouragement. > Honestly, I totally second your idea that using the same matplotlib > would have probably been the best choice from the very first moment. > Please also keep in mind that I am not a software developer, and that > the time spent on this should be like an investment to speed up my > future work, but unfortunately I can't really work on this all day ;)
I know. We all face constraints on our time. We *really* appreciate you looking at all of this!
> Before starting to write down some lines of code, we had a look at the > gnuplot Canvas page (http://skuld.bmsc.washington.edu/~merritt/gnuplot/ > canvas_demos/ ) , and I was disappointed by not seeing a single > example (there are more than 20, I certainly not looked at them all), > about fast and useful interaction with the plots. I mean, apart from > enabling a grid, what's the big deal (from my point of view, as a > user) in having such a Canvas thing, if the result is having a static > image? What do I know that the interaction is still possible, if they > don't show in any way its possibilities? Panning, zooming, turning 3d > objects, and other stuff should be the real target in my opinion!
I agree. The grid and the clicking is a start (i.e., it's getting input from the browser and using that to change something, the mouse coordinates displayed). I hope my comments helped us realize that, with other interactive backends, matplotlib does do panning, zooming, etc. I hope that a canvas backend for matplotlib would implement the exact same sort of features. I saw the gnuplot demo as just a proof-of-concept demo showing that it was possible to automatically generate an interactive graph for a web browser.
> Have a look at the FLOT example page: http://people.iola.dk/olau/flot/examples/ > .. Apart from the very basic ones, the selection tool, zooming tool, > online enabling of series, etc, looks very attractive to my eyes! > Moreover, if it hadn't been for the fact of semilog or loglog plots, > the work of including the plot in the sage notebook was done by this > morning!!
> So at the end of this long day, my thoughts are: > - FLOT is not so powerful, and the other derivatives (FLOTR, > Protochart, etc) don't seem to be any better ( I can hardly recognize > the differences), but still it is very fast to develop with in simple > cases
I agree that FLOT isn't that powerful compared to matplotlib, but the functionality is much, much easier to access. I look forward to seeing a demo of what you've done.
> - matplotlib is obviously the most powerful and well integrated (my > previous bode plot function relied on matplotlib), but I have some > doubts about whether the rendering time would be small enough to > provide a sufficiently satisfying user experience
I see the "canvas" backend to matplotlib being just like the FLOT tool (indeed, maybe one could even use the FLOT library to do it!). The matplotlib backend just needs to be able to draw some basic shapes (like lines and text) and provide some sort of interface for interaction. All of this should be documented in the matplotlib docs and/or code, and help is available on the matplotlib list.
That said, I haven't actually developed a matplotlib backend. If one were interested in working on a canvas (or even a FLOT) backend to matplotlib, it would probably be best to take things to the matplotlib list.
We really, really appreciate the work you've done in getting FLOT to work. I think it's a great thing to have available, and FLOT certainly looks nice. My comments were just to point out that, with more work than FLOT entails, we could have maybe the best of both worlds (functionality and javascript/canvas goodness).
Anyways, I look forward to seeing what you have with FLOT.
We can work out log plots in the future. Hell, the FLOT people might
even do that for us if we ask really nice and show them how awesome
Sage looks with FLOT vs. how sad I look when I have to wait for
matplotlib to render an image.
On Mon, Feb 23, 2009 at 1:30 PM, Maurizio <maurizio.gran...@gmail.com> wrote:
> Thank you very much for your encouragement.
> Honestly, I totally second your idea that using the same matplotlib
> would have probably been the best choice from the very first moment.
> Please also keep in mind that I am not a software developer, and that
> the time spent on this should be like an investment to speed up my
> future work, but unfortunately I can't really work on this all day ;)
> Before starting to write down some lines of code, we had a look at the
> gnuplot Canvas page (http://skuld.bmsc.washington.edu/~merritt/gnuplot/ > canvas_demos/ ) , and I was disappointed by not seeing a single
> example (there are more than 20, I certainly not looked at them all),
> about fast and useful interaction with the plots. I mean, apart from
> enabling a grid, what's the big deal (from my point of view, as a
> user) in having such a Canvas thing, if the result is having a static
> image? What do I know that the interaction is still possible, if they
> don't show in any way its possibilities? Panning, zooming, turning 3d
> objects, and other stuff should be the real target in my opinion!
> Have a look at the FLOT example page: http://people.iola.dk/olau/flot/examples/ > . Apart from the very basic ones, the selection tool, zooming tool,
> online enabling of series, etc, looks very attractive to my eyes!
> Moreover, if it hadn't been for the fact of semilog or loglog plots,
> the work of including the plot in the sage notebook was done by this
> morning!!
> So at the end of this long day, my thoughts are:
> - FLOT is not so powerful, and the other derivatives (FLOTR,
> Protochart, etc) don't seem to be any better ( I can hardly recognize
> the differences), but still it is very fast to develop with in simple
> cases
> - matplotlib is obviously the most powerful and well integrated (my
> previous bode plot function relied on matplotlib), but I have some
> doubts about whether the rendering time would be small enough to
> provide a sufficiently satisfying user experience
> I hope you will hear from us pretty soon
> Regards
> Maurizio
>> As I understand it, matplotlib can do those sorts of things with an
>> interactive backend (i.e., wxwindows, gtk, qt, etc.). However, none of
>> those work with the web-based notebook, but the pieces are there. It
>> would be *cool* if someone would write the necessary
>> javascript/canvas/html code to make those tools available in a "canvas"
>> backend. Again, something like the gnuplot canvas backend. You might
>> be able to even reuse code from the gnuplot canvas backend.
>> That said, it may be less effort to make an optional flot spkg.
>> However, for advanced plotting and deep integration with Sage, as you
>> are seeing, leveraging the power of matplotlib by just writing another
>> backend may be the best way to go in the end.
>> I've looked at writing a matplotlib backend, and it didn't look
>> extremely difficult. There are examples in the backends/ directory, and
>> it looks like you can get a minimal backend up and running by just
>> writing a few functions.
>> You're doing some great work on getting Flot working too! I think
>> exploring the options is what is most valuable at this point. I just
>> think that the matplotlib backend is one of the most valuable options
>> that can be explored.
>> > Today we (Kenny and me) have a working alpha. It is unfinished, but we
>> > think that these added capabilities show the possible advantages, if
>> [snip]
>> > We hope to send you some example ASAP, so that you can judge yourself
>> > and the decide what to do.
On Mon, Feb 23, 2009 at 5:15 PM, Tom Boothby <tomas.boot...@gmail.com> wrote:
> +100 to FLOT. It looks and smells very nice.
> We can work out log plots in the future. Hell, the FLOT people might
> even do that for us if we ask really nice and show them how awesome
> Sage looks with FLOT vs. how sad I look when I have to wait for
> matplotlib to render an image.
> --tom
> On Mon, Feb 23, 2009 at 1:30 PM, Maurizio <maurizio.gran...@gmail.com> wrote:
>> Thank you very much for your encouragement.
>> Honestly, I totally second your idea that using the same matplotlib
>> would have probably been the best choice from the very first moment.
>> Please also keep in mind that I am not a software developer, and that
>> the time spent on this should be like an investment to speed up my
>> future work, but unfortunately I can't really work on this all day ;)
>> Before starting to write down some lines of code, we had a look at the
>> gnuplot Canvas page (http://skuld.bmsc.washington.edu/~merritt/gnuplot/ >> canvas_demos/ ) , and I was disappointed by not seeing a single
>> example (there are more than 20, I certainly not looked at them all),
>> about fast and useful interaction with the plots. I mean, apart from
>> enabling a grid, what's the big deal (from my point of view, as a
>> user) in having such a Canvas thing, if the result is having a static
>> image? What do I know that the interaction is still possible, if they
>> don't show in any way its possibilities? Panning, zooming, turning 3d
>> objects, and other stuff should be the real target in my opinion!
>> Have a look at the FLOT example page: http://people.iola.dk/olau/flot/examples/ >> . Apart from the very basic ones, the selection tool, zooming tool,
>> online enabling of series, etc, looks very attractive to my eyes!
>> Moreover, if it hadn't been for the fact of semilog or loglog plots,
>> the work of including the plot in the sage notebook was done by this
>> morning!!
>> So at the end of this long day, my thoughts are:
>> - FLOT is not so powerful, and the other derivatives (FLOTR,
>> Protochart, etc) don't seem to be any better ( I can hardly recognize
>> the differences), but still it is very fast to develop with in simple
>> cases
>> - matplotlib is obviously the most powerful and well integrated (my
>> previous bode plot function relied on matplotlib), but I have some
>> doubts about whether the rendering time would be small enough to
>> provide a sufficiently satisfying user experience
>> I hope you will hear from us pretty soon
>> Regards
>> Maurizio
>>> As I understand it, matplotlib can do those sorts of things with an
>>> interactive backend (i.e., wxwindows, gtk, qt, etc.). However, none of
>>> those work with the web-based notebook, but the pieces are there. It
>>> would be *cool* if someone would write the necessary
>>> javascript/canvas/html code to make those tools available in a "canvas"
>>> backend. Again, something like the gnuplot canvas backend. You might
>>> be able to even reuse code from the gnuplot canvas backend.
>>> That said, it may be less effort to make an optional flot spkg.
>>> However, for advanced plotting and deep integration with Sage, as you
>>> are seeing, leveraging the power of matplotlib by just writing another
>>> backend may be the best way to go in the end.
>>> I've looked at writing a matplotlib backend, and it didn't look
>>> extremely difficult. There are examples in the backends/ directory, and
>>> it looks like you can get a minimal backend up and running by just
>>> writing a few functions.
>>> You're doing some great work on getting Flot working too! I think
>>> exploring the options is what is most valuable at this point. I just
>>> think that the matplotlib backend is one of the most valuable options
>>> that can be explored.
>>> > Today we (Kenny and me) have a working alpha. It is unfinished, but we
>>> > think that these added capabilities show the possible advantages, if
>>> [snip]
>>> > We hope to send you some example ASAP, so that you can judge yourself
>>> > and the decide what to do.
The past few days I've had my eye on this wish-list item, an
"interactive graph editor" (meaning graphs as in graph theory, not
graphs as in plots of data).
It'd be great if there was some infrastructure for creating a graph in
the notebook by clicking to make vertices, dragging vertices to
rearrange them, clicking pairs of vertices to add/delete edges, etc.
I think I've seen interest in something similar for use with geometry
objects.
So in choosing a tool that allows interaction with graphics in the
notebook, it'd be nice if it was powerful, or flexible, enough to
support the creation of various data structures by clicking, dragging,
etc on a canvas.
Rob Beezer wrote: > The past few days I've had my eye on this wish-list item, an > "interactive graph editor" (meaning graphs as in graph theory, not > graphs as in plots of data).
> It'd be great if there was some infrastructure for creating a graph in > the notebook by clicking to make vertices, dragging vertices to > rearrange them, clicking pairs of vertices to add/delete edges, etc. > I think I've seen interest in something similar for use with geometry > objects.
> So in choosing a tool that allows interaction with graphics in the > notebook, it'd be nice if it was powerful, or flexible, enough to > support the creation of various data structures by clicking, dragging, > etc on a canvas.
Mike Hansen played with doing graphs in SVG a while back and had a nice little javascript thing that let you drag vertices around. That's something that is immediately usable, but it didn't do graph creation. That seems just a bit harder (i.e., Mike's thing is an output thing that doesn't have to communicate back with Sage, while what you are proposing is an alternative input mechanism to Sage).
I've worked with Maurizio and we came out with a working example of a
bode diagram plotted into a popup. It is good looking and we would
like
to shere this code with the community.
Is anybode there that feels like to help us posting it in a publi
visible server?
We don't have a trac account and I would like to avoid opening ticket.
Thx.. Rob (aka Kenny)
On Feb 23, 12:11 pm, Maurizio <maurizio.gran...@gmail.com> wrote:
> Hi all,
> sorry for kind of flooding this group, but I'm very eager to learn.
> I'd like to understand how to add another javascript script to the
> notebook. In particular, I'd like to test FLOT for interactive
> plotting.
> The problem is that I am unable to call another script from the
> notebook, because I cannot find a suitable version of the source to
> work with.
> My intention is doing something similar to what jsMath (as far as I
> understood the code) does: launch a function which returns even a
> simple text string, that should become the argument of the script
> launcher.
> I'd like to avoid passing through file saving and html() command (that
> was the first try, but doesn't seem so polite).
> Is there another way to do it? I mean, a way that could allow us to
> make an spkg at the end, so something that doesn't need to modify the
> notebook code?
On Feb 24, 5:14 am, Kenny <masso.ke...@gmail.com> wrote:
> I've worked with Maurizio and we came out with a working example of a
> bode diagram plotted into a popup. It is good looking and we would
> like
> to shere this code with the community.
> Is anybode there that feels like to help us posting it in a publi
> visible server?
Use sagenb.org and upload the javascript code to the DATA directory.
Then create a worksheet demoing it and publish it. I am not 100%
certain this will work, but if it does it should be convenient. Once
you verified that is works and the publishing does not break it post a
link here.
> We don't have a trac account and I would like to avoid opening ticket.
Just some clarification - is the idea being discussed to use FLOT for
the notebook and matplotlib for the command line, some combination of
the above, or neither? Also, what are things matplotlib can do that
something like FLOT couldn't (I assume there are a lot of them)? I
ask out of ignorance.
kcrisman wrote: > Just some clarification - is the idea being discussed to use FLOT for > the notebook and matplotlib for the command line, some combination of > the above, or neither? Also, what are things matplotlib can do that > something like FLOT couldn't (I assume there are a lot of them)? I > ask out of ignorance.
I think having a viewer='flot' would work well, so that you would do:
> I think having a viewer='flot' would work well, so that you would do:
> p=plot(x^2, (x,0,10))
> show(p, viewer='flot')
So, again to clarify, this would be *default* in the command line or
notebook or both or neither or just in interacts or... - and what
functionality would be *lost* in that event? I'm just trying to get a
sense of this, because I am not conversant with the technical merits
on either side. Sorry to be pesty about it.
