QGAL: Add AnchorData::minPrefSize and maxPrefSize

With the addition of out-of-order sequential simplification,
the calculation of preferred sizes became more complicated.

In the past, when parallel anchors or the simplex solver had to
decide between conflicting preferred sizes, they could assume that
increasing the size of an anchor was better than decreasing it.

That assumption comes from early discussions with Jan-Arve
regarding the preferred size calculation algorithm.

However, when ooo-sequential anchors exist, we can have a situation
where increasing the size of an anchor can actually reduce the size
of a simplified anchor inside it. To solve that, we need to expose
some information regarding the internal anchors to the decision
makers outside, ie. the simplex solver and parallel anchors.

This information is now being provided in terms of two additional
values present in each anchor, as follows:

 - minPrefSize: Always in the interval [minSize, prefSize].
                Denotes the minimum size an anchor can assume
                as to avoid shrinking anchors below their
                preferred sizes.

 - maxPrefSize: Always in the interval [prefSize, maxSize].
                Similar to the value above, but refering to
                the maximum size the anchor should assume.

Some examples:

 1) Standard anchor:

            10 / 50 / 500
    o---------------------------->

    Becomes:

       10 / 50 / 50 / 500 / 500
    o---------------------------->

    We'd rather grow than shrink, so we say that our preferred size
    is 50, but if we need to grow up to 500, that's OK.
    Note that we are still able to shrink all the way to 10, but
    it will hurt us more.

 2) Two anchors:

       100 / 200 / 500          10 / 20 / 40
    o--------------------> <-------------------o

    Resulting sequential anchor:

            60 / 160 / 180 / 480 / 490
    o------------------------------------------>

    The resulting anchor have a preferred size of 180 but it can
    "easily" grow to 480 (only the first half grows). If it had
    to go all the way to 490 the second half would have to shrink
    below its preferred size.

    OTOH, if it had to shrink, it could go to 160 if the second
    half grew. However, shrinking even more, towards 60, would
    require the first half to shrink below its preferred size.

With this information parallel and simplex are now able to choose
the best solutions when solving conflicts.

Signed-off-by: Eduardo M. Fleury <eduardo.fleury@openbossa.org>
Reviewed-by: Caio Marcelo de Oliveira Filho <caio.oliveira@openbossa.org>

1 files changed, 3 insertions, 1 deletions

diff --git a/src/gui/graphicsview/qgraph_p.h b/src/gui/graphicsview/qgraph_p.h
index d429714..076b8fa 100644
--- a/src/gui/graphicsview/qgraph_p.h
+++ b/src/gui/graphicsview/qgraph_p.h
@@ -236,11 +236,13 @@ public:
                 EdgeData *data = edgeData(v, v1);
                 bool forward = data->from == v;
                 if (forward) {
-                    edges += QString::fromAscii("\"%1\"->\"%2\" [label=\"[%3,%4,%5]\" color=\"#000000\"] \n")
+                    edges += QString::fromAscii("\"%1\"->\"%2\" [label=\"[%3,%4,%5,%6,%7]\" color=\"#000000\"] \n")
                         .arg(v->toString())
                         .arg(v1->toString())
                         .arg(data->minSize)
+                        .arg(data->minPrefSize)
                         .arg(data->prefSize)
+                        .arg(data->maxPrefSize)
                         .arg(data->maxSize)
                         ;
                 }