on Jul 10th, 2009A Zesty Summer
On Canada’s west coast we have been having an unbelievable summer.
While the sunshine (and the beach) have a tendency to lure me away from my computer, there has been so much Eclipse activity this summer that it’s challenging to get away. One of the things I’m most excited about is the Google Summer of Code work going on in Zest. Zest is my small graph widget toolkit. Up to now it has been something I’ve worked on in the evenings and weekends. However, this all changed when not one… but two students signed up to work on Zest.
Mateusz Matela, has ventured into the world of Zest layouts. I wouldn’t ask my worse enemy to look at the layouts, but Mateusz managed to refactor the entire package, removing much of the dead (and error prone code) and he came out with a much cleaner (and simpler) design. Mateusz even managed to fix some bugs along the way. For the rest of the summer, Mateusz will be adding some new widgets to our library, allowing you to expand and explore complex graphs.
Fabian Steeg has be working on a GraphViz to Zest transformation toolkit. Using this toolkit you can write GraphViz and generate Zest diagrams.
This is done by using a GraphViz DSL (thanks to the oAW team for this great work) and set of Java Emitting Templates. Fabian also has full text editor for GraphViz and custom builder that will generate the equivalent Zest code.
Fabian has also been working on the reverse transformation (Zest to GraphViz).
I’m not sure how Zest ended up with two of the best Summer of Code students, but I’m very excited about the future of the project.
Great work guys!
Thanks for the very kind review Ian. Wanted to add a small clarification: the DOT editor is not part of my own work but came as part of the Graphviz support in oAW. And thanks to the oAW team for that work from me too, it has been an awesome basis to start from.
Wow, this sounds awesome and just like the stuff that i’d like to use since i am already a heavy user of dot for my research stuff. Two questions though: why are you mixing the oaw stuff (that is now part of Galileo) with JET? Wouldn’t it more sense to use Xtext in combination with Xpand/Xtend instead of JET?
The other thing i was wondering about whether the Zest diagrams are displayed dynamically in a dot-zest-view when a dot file is opened or whether you use JET to generate static Java code from the dot files. While both uses are somehow legitimate, i think the first use, dynamically displaying Dot files with the Zest engine would have more immediate use. The article kind of sounds like each change in a dot file triggers a builder that generates equivalent java code. Diagrams described with Dot are almost never static, but created using some kind of tool and are subject to frequent change. Therefore, i don’t see much point in a focus on generating Java code, but i would rather walk the ecore model instatiated by xtext and dynamically create the diagram in a separate zest-based dot viewer.
Just a few thoughts
I’d be happy to give this a try when it is ready.
Is the re-orged code base of Zest part of 3.5 or only in cvs?
Fabian, are you using Xtext 0.7?
Peter, not yet. In particular because I’m not directly using Xtext myself. I use Xpand with the existing Xtext grammar for Graphviz DOT in the org.openarchitectureware.graphviz package. It would be great if we could get all of this updated to the new versions. See also bug 277397 (http://bugs.eclipse.org/277397).
Ben, I actually use both Xpand and JET for different things: with Xpand I generate the Zest graph from a DOT file, while with JET I export a Zest graph to DOT. The idea here was that with JET I’m able to implement the export without any new dependency (once JET generated the template class). Also, this approach allows export of any Zest graph, even without an Xtext-based DOT model (i.e. for Zest graphs not imported from DOT).
On the viewing topic, what’s currently there is compilation from DOT to Zest files. The main goal was to provide a way to easily author Zest graphs using DOT as a DSL, which can then be used in applications idependently of their DOT origin. However, I do plan to add support for the Zest view in the EMF model visualizer project (http://code.google.com/p/emfmodelvisualizer/). This hopefully will allow exactly what you describe: writing DOT and viewing it dynamically using Zest.
And about giving it a try when it’s ready: if you feel adventurous you can check it out any time, details can be found on the project’s wiki page (http://wiki.eclipse.org/Graphviz_DOT_as_a_DSL_for_Zest). I’d be happy about any kind of feedback.
Lars,
The re-organization is not even in CVS yet
. It’s coming as patches right now, and I will be integrating it throughout the summer. I will blog about the changes as the summer goes in, and we will be looking for advice as we harden the Zest API.
Thanks for the explanations Fabian. I’ll give this a try when the emfmodelvisualizer is ready. I’m sorry to say that this is unfortunately all that i am interested in, but in any case this is what i am extremely looking forward to
hi,
its good to hear that Graphviz and Zest are getting closer together. Are there any plans to port layout-algorithms from Graphviz to Zest? I’m amazed by what Graphviz can do in terms of layout, but its just nasty that it is only available as a native binary (and not as java library).
This is a great idea Moritz! Mateusz has done a really good job updating the Zest layouts and adding a new layout (like graphviz) is entirely feasible. The problem is now a legal one (not a technical one). I’m pretty sure graphviz is CPL, but we have to look at the legal ramifications of porting their algorithms to Zest.
Another possibility to use the dot executable for the layouting stuff. I think a few third party dot viewers like the zgvrviewer (http://zvtm.sourceforge.net/zgrviewer.html) do it that way. They use some feature of graphviz that just outputs the layouted coordinates. So all that would be needed is somekind of layout-adapter that calls the dot executable.
Oh another thing to consider might be to somehow write a JNI interface to the graphviz libraries. I don’t know to what degree the layout algrithms have a proper interface, but at least the OmniGraffle guys (http://www.omnigroup.com/applications/OmniGraffle/) also managed to integrate just the graphviz layout algorithms into their product while their rendering engine is still their own.