new version of the graph editor
Rado
major improvements to the graph editor. Take it for spin at
http://www.math.uiuc.edu/~rkirov2/js-graph-editor/ (a Sage patch will
follow soon). I have only tested it in Firefox on Linux so interested
to hear if anybody has some problems with it.
improvements:
- repulsion between vertices and dynamic zooming (so vertices never
fly off stage).
- circular layout
- vertex numbering
- one-step undo
- loops
- communication b/n Sage and JS is done in proper JSON
- and many more (make sure you click the tweak button)
I have to change the UI to accommodate some of the new features. There
is no more dragging out of the screen to erase vertices. While it was
cool, it required tweaks to the processing.js library. Since the
library is still in active development, it is best to be able to drop
the newest version and have the graph editor work. The new way of
deleting vertices is right-click. Double-click now toggles a loop at
the vertex.
To spur further development I have created a separate repo for the
project at http://bitbucket.org/radokirov/js-graph-editor/ .
Compatibility with Sage is the number one priority, so the graph
editor will always be compatible with the way Sage calls it.
Next step is labels for edges and vertices and directed graphs.
Processing.js seems to be doing well at displaying text and with JSON
data transfer this should relatively easy to implement.
Rado
Dan Drake
> Thanks to Kevin (one of William's undergrad students), we have some
> major improvements to the graph editor. Take it for spin at
> http://www.math.uiuc.edu/~rkirov2/js-graph-editor/ (a Sage patch will
> follow soon). I have only tested it in Firefox on Linux so interested
> to hear if anybody has some problems with it.
I tried it with Chromium (from the Ubuntu PPA) and it seemed to work,
but after clicking to create some vertices, I tried to drag a vertex out
of the graph area, and the tab died -- it's taking up my CPU, but not
rendering anything. Chromium on Linux is buggy enough so that maybe
that's not a big problem.
I opened a new tab and the "live" layout with spring-electric is totally
super cool. It's amazing to create a new vertex and watch everything
jiggle around. The physics model is really good! It feels real and
tangible, almost like watching living amoebas through a microscope.
Awesome work, Kevin and Rado!
Dan
--
--- Dan Drake
----- http://mathsci.kaist.ac.kr/~drake
-------
Rob Beezer
Very nice! With the vertex numbers turned on, it takes me back. But
we never dared do the dynamic layout (which is both fun and useful).
Some goofyness with loops. Add a loop or two, then adjust vertex size
with sliders and the loops seem to go away. This is reproducible for
me. Before I was able to figure out how to reproduce this much, I was
getting an extra concentric circle around some vertices (I think
instead of loops), and as I adjusted vertex size, at some threshold
they would jump to some totally different location (and back again on
the other side of the threshold). I did this several times (in new
windows) but I can't reproduce it now. Firefox 3.5.6 on Kubuntu 9.10.
Nice improvements and great work!
Rob
On Mar 22, 4:44 pm, Rado <rki...@gmail.com> wrote:
> Thanks to Kevin (one of William's undergrad students), we have some
> major improvements to the graph editor. Take it for spin athttp://www.math.uiuc.edu/~rkirov2/js-graph-editor/(a Sage patch will
Rado
think i have the daily build. The deletion maneuver (along with double-
click erase) is turned off, right click is the new deletion of
vertices.
Nice catch Rob. It should be fixed now. Tell me how it looks.
I posted a big patch with all the modifications (Kevin's and mine) at
http://trac.sagemath.org/sage_trac/ticket/8222 (there are two parts
8222-sage.patch and 8222-sagenb.patch to be applied to Sage and SageNB
corespondingly). In foresight maybe that was a bad idea to bulk
everything together in one patch (I got excited when I saw Kevin's
spring-electric algo and finished my additions). I will try to do
proper software development in the future :)
Rado
On Mar 22, 10:53 pm, Rob Beezer <goo...@beezer.cotse.net> wrote:
> Rado and Kevin,
>
> Very nice! With the vertex numbers turned on, it takes me back. But
> we never dared do the dynamic layout (which is both fun and useful).
>
> Some goofyness with loops. Add a loop or two, then adjust vertex size
> with sliders and the loops seem to go away. This is reproducible for
> me. Before I was able to figure out how to reproduce this much, I was
> getting an extra concentric circle around some vertices (I think
> instead of loops), and as I adjusted vertex size, at some threshold
> they would jump to some totally different location (and back again on
> the other side of the threshold). I did this several times (in new
> windows) but I can't reproduce it now. Firefox 3.5.6 on Kubuntu 9.10.
>
> Nice improvements and great work!
>
> Rob
>
> On Mar 22, 4:44 pm, Rado <rki...@gmail.com> wrote:
>
> > Thanks to Kevin (one of William's undergrad students), we have some
> > major improvements to the graph editor. Take it for spin athttp://www.math.uiuc.edu/~rkirov2/js-graph-editor/(aSage patch will
Pablo Angulo
I'd like to review this patch, but I don't know how to apply patches
to sagenb: can you give me a link? Thanks
Pablo Angulo
Pablo Angulo
the system is using. I'd appreciate your help for applying the patch
Rado
1) unzip sagenb in spkg/standard
2) go to the subfolder containing setup.py
3) SAGEPATH\sage -python setup.py develop
4) hg patch *patchname*
hope that helps.
Rado
Pablo Angulo
similar errors, with a final "abort: patch failed to apply"
Thanks for your help, but it looks like I need to learn more about this
mercurial before I proceed.
Ondrej Certik
On Mon, Mar 22, 2010 at 4:44 PM, Rado <rki...@gmail.com> wrote:
> Thanks to Kevin (one of William's undergrad students), we have some
> major improvements to the graph editor. Take it for spin at
> http://www.math.uiuc.edu/~rkirov2/js-graph-editor/ (a Sage patch will
> follow soon). I have only tested it in Firefox on Linux so interested
> to hear if anybody has some problems with it.
this is awesome! We are working on a finite element mesh editor, which
is in principle very similar to what you are doing --- we want some
python function to generate it, etc. etc. E.g. just like your graph
editor, only it would be a FEM mesh, so it needs some elements, and
boundary edges etc. Aauysh (a student in our group in Reno) knows
flex, so he's using flash for this, but I'll try to learn how you
integrated that with the notebook and do the same.
I'll try to study your code with him and see if we could maybe use it,
because it works on my phone (Nexus One) just fine (unlike the flex
stuff).
Ondrej
Rado
code outputs a bunch of html tag - an iframe with the editor and
hidden input tag with the data. The iframe takes it from there and
reads in the data. Send me an email if you need help with it.
Glad it works with Nexus One. On the iphone there is no dragging for
some reason but everything else seems to work.
Rado
On Mar 23, 6:07 pm, Ondrej Certik <ond...@certik.cz> wrote:
> Hi Rado,
>
> On Mon, Mar 22, 2010 at 4:44 PM, Rado <rki...@gmail.com> wrote:
> > Thanks to Kevin (one of William's undergrad students), we have some
> > major improvements to the graph editor. Take it for spin at
> >http://www.math.uiuc.edu/~rkirov2/js-graph-editor/(a Sage patch will
Pablo Angulo
> We are working on a finite element mesh editor, which
> is in principle very similar to what you are doing
This weekend I wrote a triangulation editor, based on the previous code
for the graph editor. I'm afraid your mesh editor will be better adapted
to the job, as I'm no expert in the FEM, but I'd gladly offer my help to
port it to javascript.
To avoid confusion, I'll post another message to this list with details,
called: "triangulation editor based on the graph editor"
Rob Beezer
> Nice catch Rob. It should be fixed now. Tell me how it looks.
Loops are behaving much better. Is there a natural way to make them
rotate in the live layout (maybe add a fake invisible vertex on the
loop opposite the attachment point to force it to adjust itself?).
Some real minor stuff with the live layouts that probably isn't that
important.
- Turn on "live" turn off "auto-maximize", add a vertex and say good-
bye as it flies off-screen. ;-) Turn off auto-maximize and it comes
back. No such effect if the strength slider is far-left.
- K_4, live on, auto-maximize off, length to zero, then it never
settles down.
- K_3, live on, auto-maximize off, drag length slider to zero, but
jiggle it down close to zero and you can make all the vertices fly
away if you do it right.
When a vertex moves outside the frame, incident edges turn red.
Probably a hangover from the now-gone deletion-by-dropping-outside
feature. Or maybe still this way on-purpose? It is easy to get red
edges with live on, and if I really abuse throwing vertices into the
edge of the frame I can make it happen once in a while with live off.
Drag a vertex outside the frame, release mouse button, bring mouse
back into the frame and jumps onto the vertex and starts dragging it
around again, even though the button is not held down. Its a bit
distracting, but maybe this is the library?
A "clear" button (with a warning, like the circular layout has) would
be a nice convenience.
Is the "spring-electric" layout coming from Sage itself? If not, it
should be. It's great.
Can you interface it with planarity.net so I don't have to play by
hand anymore? ;-)
Very nice work. Once I get back to the graph/latex/tikz routines
(May?) we could get some nice output from the latex code box results.
Rob
Rado
On Mar 24, 3:00 pm, Rob Beezer <goo...@beezer.cotse.net> wrote:
> On Mar 22, 11:09 pm, Rado <rki...@gmail.com> wrote:
>
> > Nice catch Rob. It should be fixed now. Tell me how it looks.
>
> Loops are behaving much better. Is there a natural way to make them
> rotate in the live layout (maybe add a fake invisible vertex on the
> loop opposite the attachment point to force it to adjust itself?).
>
Good idea, I was thinking about finding the biggest gap between edges
coming out and put the loop there. My only concert then is that the
loop might jump in a very non-continuous fashion.
> Some real minor stuff with the live layouts that probably isn't that
> important.
>
> - Turn on "live" turn off "auto-maximize", add a vertex and say good-
> bye as it flies off-screen. ;-) Turn off auto-maximize and it comes
> back. No such effect if the strength slider is far-left.
>
> - K_4, live on, auto-maximize off, length to zero, then it never
> settles down.
>
> - K_3, live on, auto-maximize off, drag length slider to zero, but
> jiggle it down close to zero and you can make all the vertices fly
> away if you do it right.
>
I am thinking about throwing away "auto-maximize off" as it nothing
but headaches. Don't see any reason why anyone would want vertices off
the screen.
> When a vertex moves outside the frame, incident edges turn red.
> Probably a hangover from the now-gone deletion-by-dropping-outside
> feature. Or maybe still this way on-purpose? It is easy to get red
> edges with live on, and if I really abuse throwing vertices into the
> edge of the frame I can make it happen once in a while with live off.
>
Yeah, a bit of left-over code. My idea is to make it impossible to
drag vertices off the screen.
> Drag a vertex outside the frame, release mouse button, bring mouse
> back into the frame and jumps onto the vertex and starts dragging it
> around again, even though the button is not held down. Its a bit
> distracting, but maybe this is the library?
>
yeah, i was thinking about that. It is easy to make it forget the
dragged vertex when you leave the frame. But then imagine you never
release the button. Then you come in the frame and nothing is moving.
So there is no escaping some "weirdness". Anyways i will try that fix
and see how it feels.
> A "clear" button (with a warning, like the circular layout has) would
> be a nice convenience.
>
If it was in Sage, one can call new "graph_editor()" in another cell
thats one less button to clutter up and forces the user to keep one
graph_editor per cell, which will save her/him headaches in the long
run.
> Is the "spring-electric" layout coming from Sage itself? If not, it
> should be. It's great.
>
No, all computations are done in JS. I haven't even thought about
making sage do the computation and use JS just for pretty graphics.
That would be cool, but not sure if it would work fast enough if the
server and client are communicating through the internet.
> Can you interface it with planarity.net so I don't have to play by
> hand anymore? ;-)
>
hahaha, I was thinking about that. Adding one function and the graph-
editor would be the planarity game (but in JS instead of closed-source
flash).
Once you apply the patch try G=graphs.GridGraph((10,10));
graph_editor(G) in Sage. For some reason the standard embedding of
grid graph is not a grid, but with spring-electric it settles into a
grid. Its kinda cool.
Rob Beezer
> I am thinking about throwing away "auto-maximize off" as it nothing
> but headaches. Don't see any reason why anyone would want vertices off
> the screen.
Yes, that'd be a quick fix. ;-)
> So there is no escaping some "weirdness".
I suspected as much.
> If it was in Sage, one can call new "graph_editor()" in another cell
> thats one less button to clutter up and forces the user to keep one
> graph_editor per cell, which will save her/him headaches in the long
> run.
Ah yes, that makes good sense.
> > Is the "spring-electric" layout coming from Sage itself? If not, it
> > should be. It's great.
See below.
> Adding one function and the graph-
> editor would be the planarity game (but in JS instead of closed-source
> flash).
Definitely. No Flash. ;-)
> Once you apply the patch try G=graphs.GridGraph((10,10));
> graph_editor(G) in Sage. For some reason the standard embedding of
> grid graph is not a grid, but with spring-electric it settles into a
> grid. Its kinda cool.
Yes, I bet. I'm impressed by the quality of the embeddings.
My suggestion above was not to have Sage do the computations for the
editor - the suggestion was to have the algorithm now in the editor
duplicated as a standard layout algorithm for the graph theory code in
Sage, it seems it would be a good option for creating "static"
layouts.
Thanks,
Rob
Pablo Angulo
Should this behaviour be disabled?
William Stein
> I've noticed that the graph editor is viewable in published worksheets.
> Should this behaviour be disabled?
Why?
William
Pablo Angulo
> > Should this behaviour be disabled?
>
> Why?
can't. It'd better if the javascript were disabled. But wait, interacts
are also alive on published worksheets. No big deal, anyway.
Ondrej Certik
It's confusing to me too, but maybe the solution could be to make the
published sheets editable (of course your local changes will be lost
when you leave the page, unless you login).
Ondrej
Rado
http://trac.sagemath.org/sage_trac/ticket/8222#comment:7 and try the
new patch.
Btw, great work on the triangulation editor, I just tied it on your
server. I don't know anything about FEM to comment on that, but happy
the graph_editor came in useful as a stepping stone. Send me an email
if you have any comments on improving the JS code.
Rado
Rob Beezer
Very nice work on this. I've been putting it through its paces this
weekend and it works quite well. Fed it the Higman-Sims graph (100
vertices, regular of degree 7, interesting automorphism group) and let
the spring-electric algorithm work on it overnight. It never
converged, but was fun to watch, and didn't crash anything after
chasing its tail for 12 hours. ;-)
One broad thought. A right-click can be a useful way to bring up a
context menu for assigning properties to vertices and edges (labels,
colors, bipartite sets, weights, etc). Right now this is being used
for deleting a vertex. I'm not arguing to bring back drag-n-drop
outside-the-frame but did you consider any other ways to indicate
vertex deletion quickly and easily? Long term, it might be very
beneficial to have right-clicking available for a more general
purpose.
Rob
Rado
> Hi Rado and Kevin,
>
> Very nice work on this. I've been putting it through its paces this
> weekend and it works quite well. Fed it the Higman-Sims graph (100
> vertices, regular of degree 7, interesting automorphism group) and let
> the spring-electric algorithm work on it overnight. It never
> converged, but was fun to watch, and didn't crash anything after
> chasing its tail for 12 hours. ;-)
>
Haha, wasted cpu/hours :) From my experience with the grid 10x10
graph, it might settle down if you decrease the edge(spring) length
(in tweaks). Otherwise it just can't fit so many vertices if the edges
push too far apart. A smarter graph_editor should initialize with edge
length inversely proportional to the number of vertices on the screen.
> One broad thought. A right-click can be a useful way to bring up a
> context menu for assigning properties to vertices and edges (labels,
> colors, bipartite sets, weights, etc). Right now this is being used
> for deleting a vertex. I'm not arguing to bring back drag-n-drop
> outside-the-frame but did you consider any other ways to indicate
> vertex deletion quickly and easily? Long term, it might be very
> beneficial to have right-clicking available for a more general
> purpose.
True. I made right-click as the first thing that came to mind, once I
removed the drag-n-drop capability. What about hitting 'd' (with the
canvas in focus of course) erases the selected vertex?
Rob Beezer
> True. I made right-click as the first thing that came to mind, once I
> removed the drag-n-drop capability. What about hitting 'd' (with the
> canvas in focus of course) erases the selected vertex?
I think that would be a good choice. Documented via the "Help" button
it should be easy enough for somebody to find and remember.