| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
| |
Reviewed-by: Trust Me
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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>
|
| |
|
|
|
|
|
|
|
|
|
| |
Modify the "dot" format graph to use a single arrow between each
pair of vertices.
Previously we would use two anchors (a black forward one and a
gray backwards). With a single arrow the graph loooks cleaner.
Signed-off-by: Eduardo M. Fleury <eduardo.fleury@openbossa.org>
Reviewed-by: Caio Marcelo de Oliveira Filho <caio.oliveira@openbossa.org>
|
| |
|
|
|
| |
Signed-off-by: Caio Marcelo de Oliveira Filho <caio.oliveira@openbossa.org>
Reviewed-by: Eduardo M. Fleury <eduardo.fleury@openbossa.org>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We used to keep a reference just to the first vertex of the layout
(corresponding to the left/top anchor point) inside the Graph class,
as "root vertex". Since the notion of rootVertex isn't used by the
Graph itself, now this is stored outside the graph, and we also store
the central and last vertices.
This avoids using internalVertex() function to find out the vertices
based on the item (in the case, the 'q'). This will be useful when we
do simplify vertices, since the original layout vertice might not be
the "layout vertice" in the graph.
Signed-off-by: Caio Marcelo de Oliveira Filho <caio.oliveira@openbossa.org>
Reviewed-by: Eduardo M. Fleury <eduardo.fleury@openbossa.org>
|
| |
|
|
| |
Reviewed-by: Trust Me
|
| |
|
|
| |
Reviewed-by: Trust Me
|
| | |
|
| |
|
|
| |
Reviewed-by: Trust Me
|
| | |
|
| |
|
|
|
| |
Also, only include the "name" member to AnchorData if we are compiling
in debug mode.
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
Make AnchorData aware of both vertices instead only one (the
origin). This information is useful for many functions when working in
simplified mode. Changed the name "origin" to "from", and add an "to" field.
Also change setAnchorSizeHintsFromItems() and its helpers to make use
of this information. In a later commit we will rollback to using
recursion for initializing the size hint information.
Signed-off-by: Caio Marcelo de Oliveira Filho <caio.oliveira@openbossa.org>
Reviewed-by: Artur Duque de Souza <artur.souza@openbossa.org>
|
| |
|
|
|
|
| |
Useful for verifying whether Simplex is being triggered or not.
Signed-off-by: Caio Marcelo de Oliveira Filho <caio.oliveira@openbossa.org>
|
| |
|
|
|
|
|
| |
This gives a list of all "edges" in the graph, but each edge is
specified as a pair of vertices, since you cannot easily know the
two AnchorVertex'es of an EdgeData.
Added some debug stuff.
|
| |
|
|
|
|
|
|
| |
Replacing two IF tests for Q_ASSERT statements instead. These tests
are sanity checks that should never be false.
Signed-off-by: Eduardo M. Fleury <eduardo.fleury@openbossa.org>
Reviewed-by: Anselmo Lacerda S. de Melo <anselmo.melo@openbossa.org>
|
| |
|
|
|
|
|
|
|
|
| |
Currently, the code is not in effect for the simplex solver kicks in
(it crashes), but it is in effect for each layout to check that
simplification and restoring the simplification back again works.
This is currently done in calculateGraphs()
Parts of the code does not read well, especially the detection of the
sequential chunks.
|
| |
|
|
|
| |
The black arrow shows the principal direction based on the "origin"
member of AnchorData.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The previous dumper relied on traversal of the graph, which meant that
it would not output the nodes that were not connected to the "main"
graph. Due to this, we cannot rely on traversal, so instead we must
iterate through all the vertices of the graph. As an added bonus the
code gets simpler :-)
There was also a problem with the previous dumper, since it dumped
two "digraph" elements into one file. Graphwiz (win32) did not handle
that. Instead just dump all the nodes and all the connections, both
horizontal and vertical ones. The horizontal and vertical connections
are never connected anyway, so the result will be two separate graphs
when it is rendered by graphwiz.
Also renamed firstVertex to rootVertex and simplified it.
|
| |
|
|
|
|
| |
Applying the patch sent by email.
Signed-off-by: Eduardo M. Fleury <eduardo.fleury@openbossa.org>
|
|
|
This file was originally included by Alexis Menard <alexis.menard@nokia.com>
but now it has been fully updated to the new QGraphicsAnchorLayout needs.
Signed-off-by: Anselmo Lacerda S. de Melo <anselmo.melo@openbossa.org>
Signed-off-by: Caio Marcelo de Oliveira Filho <caio.oliveira@openbossa.org>
Signed-off-by: Eduardo M. Fleury <eduardo.fleury@openbossa.org>
Signed-off-by: Jesus Sanchez-Palencia <jesus.palencia@openbossa.org>
|
