Re: [zvtm-devel] ZVTM architecture and concepts understanding questions

[Emmanuel P. <pie...@lr...>]

Jean Guillaume LALANNE wrote:
> Hi,
>=20
> Thanks a lot for your detailed explanations.
> I have run your sources against DOXYGEN and everything is getting much
> clearer now.
>=20
> Actually, ZVTM is acting just after the DOT/NEATO graph processing that
> transforms a brute graph file to an "attributed graph" (i.e: a graph wi=
th
> graphical information like positions). If I understand the "attributed
> graph" can be dot or svg.

Not exactly. The output of GraphViz can be attributed DOT or SVG. But in=20
the case of SVG, you loose all information about the graph's logical=20
structure (you only have a bunch of graphical objects, but you don't=20
know they form a graph).



> After parsing via ANTLR, the "attributed graph"
> that has an in-memory structure in your framework, is set to a VirtualS=
pace
> object via the famous "load()" method of the ZgrReader class.

ZGRReader reads the in-memory structure and creates, for each node and=20
edge it finds, one (or more) ZVTM glyphs that it puts in one=20
VirtualSpace. The geometrical/graphical information about glyphs is=20
found in this in-memory structure (it comes from the attributed DOT data)=
.



> This
> VirualSpace is managed by a VirtualSpaceManager that take care of all t=
he
> 2.5D display features you are talking in your thesis; I mean glyphs
> associated to the nodes and the edges, cameras, zooming, constraints, l=
ayers
> and so on...

Yes, the VirtualSpace is just the infinite surface area that "contains"=20
the glyphs, and that is observed through cameras.



> The ZGRViewer acts as the container in charge of all the animation, eve=
nt
> handling, configuration, Tooltip mechanism surrounding the VirtalSpaces=
 and
> their views.

ZGRViewer is just an application dedicated to visualizing DOT graphs,=20
based on the ZVTM toolkit. There are several other applications based on=20
ZVTM which have nothing to do with GraphViz/ZGRViewer/etc...




> Moreover, the framework provides way to serialize to SVG (for example) =
the
> VirtualSpace object.

ZVTM provides an SVG package that can parse and serialize SVG documents.=20
The serializer can export all ZVTM glyphs. The parser only supports a=20
very limited subset of the SVG specification, mostly what can be=20
produced by GraphViz programs. It is not the VirtualSpace by itself=20
which is serialized; more exactly, it is the content of this virtual=20
space (i.e. all the glyphs inside it).




> What I don't understand is the difference in between the SVG file expor=
ted
> from ZVTM and a SVG file that would have been created with graphviz dir=
ectly
> from the first graph dot file. Is there more information?

ZGRViewer does not rely on the SVG serializer at all when parsing DOT=20
files, no matter the pipeline. The only time when ZGRViewer calls ZVTM's=20
SVG serializer (SVGWriter) is when the user asks for an SVG export of=20
the document (in which case is does not go at all through GraphViz).



> For my project, a simple svg file is sufficient because the documentati=
on
> will have to be accessible from anywhere via a simple browser.
> But later on,
> the 2.5D features will be very interesting for software architecture
> understanding. Do you think that your framework could be integrated in =
an
> eclipse plug-in?

You are not the 1st person to ask for integration in Eclipse. I agree=20
this would be interesting. Unfortunately, I am not familiar with the=20
Eclipse environment (I'm an emacs + xterm guy) and I've heard the the=20
plugin architecture is quite powerful but also quite complex. As a=20
research scientist I can't afford to spend time on this. So, if somebody=20
is willing to do that work, or if I find a student willing to do that,=20
it might happen. But not otherwise, sorry.


--=20
Emmanuel Pietriga
INRIA Futurs - Projet In Situ    tel : +33 1 69 15 34 66
Bat 490, Universit=E9 Paris-Sud    fax : +33 1 69 15 65 86
91405 ORSAY Cedex FRANCE     http://www.lri.fr/~pietriga