ahnitz / jrfonseca

Automatically exported from code.google.com/p/jrfonseca
0 stars 0 forks source link

[xdot] Parse into an intermediate dict/array structure before rendering. #14

Open GoogleCodeExporter opened 9 years ago

GoogleCodeExporter commented 9 years ago
I'm using http://raphaeljs.com/ to render digraphs to svg/vml and needed an
xdot parser for parsing xdot into a JSON structure.
The first one I tried was dot_parser.py which uses pyparsing and was very slow.
Then I tried yours and found it to be impressive fast even for large graphs.
But your cairo drawing operations are hardwired to the parser so I had to
hack in some changes to construct a dict/array structure which I feed
through minjson.
I basically replaced XDotAttrParser with some regular expressions to get
polygon points for the edges and arrow heads from attrs.
To get rid of the gtk dependance I resolve the color names with a dict.
This is all very hackish at the moment but is ok for my project.
You can see a very early proof of concept at:
http://atomar.de/graphael/test01.php

Maybe you can separate the parsing from the drawing in a future version so
xdot.py can also be used as a xdot parser library? :)

best regards

Thomas

Original issue reported on code.google.com by Vindo...@gmail.com on 29 Mar 2009 at 7:43

GoogleCodeExporter commented 9 years ago
Thomas,

I want to keep xdot.py as a single file, but I wouldn't mind having it working 
also
as a parser library.

I did a start at this, and commited to svn. The main problem left is that the 
xdot
parsing is actually scattered in two classes (XDotParser, and XDotAttrParser) 
which
makes it difficult to reuse. That will require more refactoring of the code, 
but I
don't have time for that at the moment.

Jose

Original comment by Jose.R.F...@gmail.com on 29 Mar 2009 at 11:05

GoogleCodeExporter commented 9 years ago
Oh, forgot to mention: the demo page you referred above is preatty neat!

Original comment by Jose.R.F...@gmail.com on 29 Mar 2009 at 11:08

GoogleCodeExporter commented 9 years ago
I would be interested in this as well - let me know if I can help.

I've looking at extending xdot to create a diagram editor - so have events from 
the
widget modify the underlying graphviz input and render the result. If there 
were an
intermediate representation between the parser and the widget I think the right 
way
to go would be to apply changes at that level and implement a dumper to save the
intermediate representation back to a .dot file.

Probably I come back to this idea in a couple of months, so no hurry :) But 
having a
layer separating the parser and the widget would really neat ..

Original comment by jaap.kar...@gmail.com on 16 Jul 2009 at 9:56

GoogleCodeExporter commented 9 years ago
jaap.kar...@gmail.com: Doing the same stuff as you (issue #79), and doing it in 
the same way - adhoc intermediate representation to make it easily to modify 
graph, and then re-gen dot. One problem with this is that I'm reinventing the 
wheel for dot parsing and graph manipulation - there're existing libs for that!

Jose: Any reasons to stick to a single file? I understand benefits of having 
simple 50-lines util in a single file, but xdot at 5000 lines is already too 
complex and powerful already to ignore modularity, and can be made much more 
powerful if modularized.

Original comment by pmis...@gmail.com on 14 Feb 2013 at 8:25

GoogleCodeExporter commented 9 years ago

Original comment by Jose.R.F...@gmail.com on 8 Apr 2013 at 5:47