[Lemon-devel] Naming question again

[Alpár Jüttner]

Hi,

> I agree that it could be two methods with some different behaviors
> (or the same behavior in some case).
> For sample, edgeColor() could act as two reverse acrColor() with
> the same color?
> Also addEdge could be added in DiGraphs class for adding two symetrical
> addArc?

Currently graphToEps() works in the following way.

      * Both directed and undirected graphs can be drawn in both
        directed and undirected mode using the undirected(bool)
        parameter. The default value matches with the graph-type, of
        course. 
      * In fact, it always consider the graph as a directed one, the
        only difference is the default value of the undirected()
        parameter.  Note, that  an undirected graph works perfectly as a
        directed graph, in that case each (undirected) edge appears as a
        pair of oppositely directed arcs. 
      * Each map given as an attribute will be considered as an Arc map.
        Edge maps convert to it, of course. 
      * In directed mode, all the arcs will be drawn, while in
        undirected mode an arc is drawn only if the ID of its source is
        less than the ID of its target. 
      * There are a couple of other parameters that affect the rendering
        of the arcs.
              * drawArrows(). It sets whether an arrow head is drawn at
                the target node of the arc. It is turned off by default
                even in directed mode. The reason is that the default
                size of the arrow heads may look very badly depending on
                the node coordinated, arc widths etc, thus the
                drawArrows() cannot be turned on safely without
                adjusting the size of the arrow heads. 
              * enableParallel(). 
                      * If it is turned off, the the arcs will be
                        straight lines between the source and the target
                        nodes and they are drawn in the same order as
                        they are listed by the ArcIt. Each arc
                        overprints the previous ones. 
                      * If turned on, the arcs are bended using a Bezier
                        curve. The distance between the parallel arcs
                        are controlled using parEdgeDist() parameter. 

In this way the behavior is more or less what we want for both directed
and undirected graphs. The code for the drawing is very-very complex,
because of the various scaling operators and other options and also
because of the huge amount of other things that must be taken into
account.
For example when you turn on the arrowheads, the head of the arrow
should exactly touch the shape of the node (which is a circle, square,
triangle etc of different size), and it should be "in line" with the
curve of the arc, thus even the computation of the arrow endpoint
co-ordinate and its direction is a quite complex code.

This whole drawing is a fairly unstructured big junk of code. This isn't
beautiful at all, but I don't see a straightforward way to do that in a
significantly more structured way. Therefore I don't the know how the
GraphToEps()/DigraphToEps() separation could be done without a more or
less full duplication of the code.

This is one point. The other thing is that graphToEps() uses a massive
number of template named parameters, which is probably the dirtiest C++
hacking. (In fact, the graphToEps() was originally written to test if
the idea of template named parameter implementation is working in
practice.) If we want to separate DigraphToEps() from GraphToEps() this
whole stuff should also be duplicated. And this is something I really
want to avoid.

The bottom line is that I'm not fully satisfied the current architecture
and implementation of graphToEps(), but I don't know how to make is
significantly better. Any idea is very welcome.

Best regards,
Alpar


> 
> -- Maurice Diamantini
> 
> 
> _______________________________________________
> Lemon-devel mailing list
> Lemon-devel at lemon.cs.elte.hu
> http://lemon.cs.elte.hu/mailman/listinfo/lemon-devel