| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
| |
Reviewed-by: Trust Me
|
| |
|
|
| |
Reviewed-by: Trust Me
|
| |
|
|
| |
Reviewed-by: Alexis
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We cannot delete the parallel anchors before we do the actual vertex
restoration, since the parallel anchors created by vertex simplification
will always be connected to some of the AnchorVertexPair found in
simplifiedVertices that we iterate over later.
Thus, we must delete the parallel anchors created by vertex
simplification after we have done the restoration of the vertices. (the
parallel anchor will be properly dealt with (i.e. taken out of the
graph as we do the restoration)), so not deleting it won't cause it to
be revisited later if that is a worry.
Reviewed-by: Eduardo M. Fleury
|
| |
|
|
|
| |
It is both a limit and an offset (the offset is dictated by the limit),
but in the code is it interpreted as an offset.
|
| |
|
|
|
|
|
|
|
| |
These assert messages are no longer valid since some anchors can have
their size not respected if they are in parallel with the layout and
have size equal to "QWIDGETSIZE_MAX".
Signed-off-by: Eduardo M. Fleury <eduardo.fleury@openbossa.org>
Reviewed-by: Caio Marcelo de Oliveira Filho <caio.oliveira@openbossa.org>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
With the addition of min and maxPrefSizeHints, the logic used in the
preferred simplex had to be changed. The concept behind it is still
the same, we minimize the deviation from each item's preferred size.
Previously we would make an special effort to avoid items being shrunk,
that's why the "shinker" simplex variables had larger multipliers in
the objective function.
Now we still have variables with large multipliers and others with
small mutlipliers, but rather than differentiating between shrinker
and/or grower variables, we classify them as "soft" or "hard".
"Soft" variables, or slacks, are those that allow the anchor to change
its value up to the minPref or maxPref boundaries, OTOH, "hard" slacks
are those that allow the item to go all the way to its minimum or
maximum sizes. Naturally, the "hard" slacks get large coeficients
in the objective function while the "soft" ones get small ones.
Now all the slack variables are restricted in size as to respect
the boundaries of each interval:
- Minimum to MinimumPreferred,
- MinimumPreferred to Preferred,
- Preferred to MaximumPreferred and
- MaximumPreferred to Maximum
With such limits, the SizeHint constraints became redundant in the
calculation of preferred sizes so they are no longer used.
Additionally, as an optimization, if a given interval is NULL
(for instance, MinimumPreferred is equal to Preferred), then
the associated slack variable would have its size restricted to
zero, therefore it is not created at all.
Signed-off-by: Eduardo M. Fleury <eduardo.fleury@openbossa.org>
Reviewed-by: Caio Marcelo de Oliveira Filho <caio.oliveira@openbossa.org>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
For an out-of-order parallel anchor, i.e. when the second child is
backwards in relation to the parallel anchor, we need to fix the
constraints that used to have the second child.
The parallel anchor will replace its child, but we must change the
multiplier signal, so the constraint remain valid.
This commit also changes the order of restoration steps, since now we
depend on correct vertex information to fix back the constraints, we do
it before the restoring of pair vertices.
Signed-off-by: Caio Marcelo de Oliveira Filho <caio.oliveira@openbossa.org>
Reviewed-by: Eduardo M. Fleury <eduardo.fleury@openbossa.org>
|
| |
|
|
|
|
|
|
|
| |
In a parallel anchor, the second child anchor may be forward or
backwards in relation to the parallel itself. Moves the directionality
check to a function. It'll be useful in the next commit.
Signed-off-by: Caio Marcelo de Oliveira Filho <caio.oliveira@openbossa.org>
Reviewed-by: Eduardo M. Fleury <eduardo.fleury@openbossa.org>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Modify the simplification code to allow the creation of out-of-order
sequential anchors.
Basically the "changedDirection" end-of-sequence condition was removed,
also note that createSequence no longer bothers to revert the direction
of anchors if the order it receives is not standard.
Removing expect-fail clause from test since now we pass :-)
Signed-off-by: Eduardo M. Fleury <eduardo.fleury@openbossa.org>
Reviewed-by: Caio Marcelo de Oliveira Filho <caio.oliveira@openbossa.org>
|
| |
|
|
|
|
|
|
|
|
|
| |
Now sequential anchors account for the fact they may be composed of
anchors with different directions.
Both refreshSizeHints and updateChildrenSizes have been updated
to support this situation.
Signed-off-by: Eduardo M. Fleury <eduardo.fleury@openbossa.org>
Reviewed-by: Caio Marcelo de Oliveira Filho <caio.oliveira@openbossa.org>
|
| |
|
|
|
|
|
|
| |
Since we now support anchors with size less then zero, we no longer
need to revert anchors with negative spacing.
Signed-off-by: Eduardo M. Fleury <eduardo.fleury@openbossa.org>
Reviewed-by: Caio Marcelo de Oliveira Filho <caio.oliveira@openbossa.org>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This commit is groundwork for the support of negative-sized anchors
by the simplex solver.
The idea is to add to all variables an offset large enough to ensure
they are never negative. The implementation limits all variable
sizes in the range [-limit, limit] and feed them into the simplex
with an offset of "limit". Subtracting this offset later to find out
the real values.
"limit" is defined as QWIDGETSIZE_MAX for platforms where qreal is
double and as QWIDGETSIZE_MAX / 32 when it is float. This is to
avoid numerical errors in the simplex solver.
This commit also modifies the ASSERT clause inside QSimplex so it
becomes less prone to false positives due to numerical errors.
Signed-off-by: Eduardo M. Fleury <eduardo.fleury@openbossa.org>
Signed-off-by: Caio Marcelo de Oliveira Filho <caio.oliveira@openbossa.org>
|
| |
|
|
|
|
|
| |
Former name did not reflect actual work done by the function.
Signed-off-by: Eduardo M. Fleury <eduardo.fleury@openbossa.org>
Reviewed-by: Caio Marcelo de Oliveira Filho <caio.oliveira@openbossa.org>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Fixing QGraphicsAnchor memory leak and access to free'd region.
-- Leak:
User-created anchors have two representations in QGAL, one
visible externally (QGraphicsAnchor) and other internal (AnchorData).
When such anchors are removed externally (QGraphicsAnchor is deleted),
the former implementation ensured that the internal representation
would be deleted too. However the opposite was not true. In cases
where the anchors are deleted internally (in the layout destructor,
for instance, or when an item is removed through the removeAt API),
the public QGraphicsAnchor object would leak.
This commit ensures the deletion will happen in both directions
and adds protection to avoid a deletion loop.
-- Invalid read:
In QGAL::removeAnchor(vertex1, vertex2), we read vertex information
after calling removeAnchor_helper(vertex1, vertex2).
The problem is that in cases where the removed anchor is the last
anchor to connect to a center vertex, its removal will cause also
the removal of such vertex. Thus, accessing the vertices after
the removeAnchor_helper() call is unsafe.
To solve that we cache the information we need and then clear the
vertex pointers to avoid errors in the future.
Signed-off-by: Eduardo M. Fleury <eduardo.fleury@openbossa.org>
Reviewed-by: Artur Duque de Souza <artur.souza@openbossa.org>
|
| |
|
|
|
|
|
|
|
|
|
| |
Adding check to prevent the structural layout anchors as well as
those internal to items, from being exposed through the public API.
These checks also ensure no QGraphicsAnchor instances will be
created for those anchors.
Signed-off-by: Eduardo M. Fleury <eduardo.fleury@openbossa.org>
Reviewed-by: Artur Duque de Souza <artur.souza@openbossa.org>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The method "constraintsFromSizeHints" does not create constraints for
anchors between the layout vertices _only if_ these anchors have
infinite maximum sizes. However, this test was not being done for
half-anchors, ie. those created when the layout center anchorage
point is used.
That was OK when there was no chance that the center anchors had
been simplified by a parallel anchor. Nowadays there's a chance
that happens, so the test was extended.
Commit also adds a test to avoid regressions.
Signed-off-by: Eduardo M. Fleury <eduardo.fleury@openbossa.org>
Reviewed-by: Caio Marcelo de Oliveira Filho <caio.oliveira@openbossa.org>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In the preferred size calculation, we should not add 'layout anchors'
(either one or the two halves) into the objective function, since the
layout doesn't impose or prefer any size at all.
This already worked for cases when the layout anchor is one, but not
when we have two halves. The mechanism was a 'skipInPreferred' flag
that were not being set.
The flag is pretty much redundant right now, since we can get this
information from the 'isLayoutAnchor' flag. So, the flag was removed
and a test was added for both a parallel case with the entire layout
and other with half of the layout (which wasn't passing before).
Signed-off-by: Caio Marcelo de Oliveira Filho <caio.oliveira@openbossa.org>
Reviewed-by: Eduardo M. Fleury <eduardo.fleury@openbossa.org>
|
| |\
| |
| |
| | |
git://gitorious.org/~fleury/qt/fleury-openbossa-clone into fleury-fixes
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
The code for refreshing size hints of items / user-created anchors now
happens with a graph in full (not simplified). So we don't need to now how
to refresh size hints for complex anchors.
The code for refreshing complex anchors was used also to initialize
the complex anchors (the '_helper' functions). Those were changed to
calculateSizeHints() and refreshSizeHints() doesn't need to be virtual
anymore.
Signed-off-by: Caio Marcelo de Oliveira Filho <caio.oliveira@openbossa.org>
Reviewed-by: Eduardo M. Fleury <eduardo.fleury@openbossa.org>
|
| | |
| |
| |
| |
| |
| |
| |
| |
| | |
Now the interpolation doesn't need to know how to traverse complex
anchors, since when it runs, the graph is not simplified anymore.
This commit removes unnecessary code for dealing with that.
Signed-off-by: Caio Marcelo de Oliveira Filho <caio.oliveira@openbossa.org>
Reviewed-by: Eduardo M. Fleury <eduardo.fleury@openbossa.org>
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
After discussion with Jan-Arve, we decided to remove for good the
caching of simplified graph. This avoided recalculating the
simplification (but not the simplex) in some situations. Since vertex
simplification, this was temporarily disabled already.
To know whether if we could the cached version or not, we needed to
track individual anchors to see whether they reached size 0 or they
were 0 and changed the size. This is because the vertex simplification
depend on that fact.
Now the simplified version of the graph exists only during the
execution of calculateGraphs() function. This and next commits clear up
the code to take advantage of that fact.
Signed-off-by: Caio Marcelo de Oliveira Filho <caio.oliveira@openbossa.org>
Reviewed-by: Eduardo M. Fleury <eduardo.fleury@openbossa.org>
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
When filling sizeAt* values for parallel anchors, we have to identify
the case when the second anchor in the parallel doesn't have the same
direction as the parallel itself. However, relying on the parallel group
vertices to identify this case is not safe, because after a parallel
group a new vertex simplification can happen.
So, the comparing the 'from' with the first edge is the correct way to
verify whether the second is backwards. Code was fixed to follow that.
Note that, without negative spacing the case "out-of-order" for parallels
is only the trivial case (size == 0).
Signed-off-by: Caio Marcelo de Oliveira Filho <caio.oliveira@openbossa.org>
Reviewed-by: Eduardo M. Fleury <eduardo.fleury@openbossa.org>
|
| | |
| |
| |
| |
| | |
Signed-off-by: Eduardo M. Fleury <eduardo.fleury@openbossa.org>
Reviewed-by: Caio Marcelo de Oliveira Filho <caio.oliveira@openbossa.org>
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
To solve the spacing persistency bug, this commit saves the
preferredSize (spacing) information inside QGraphicsAnchorPrivate.
The problem started when we could not rely on "AnchorData->prefSize"
to keep the spacing information for user-defined anchors. This happens
because that member can be overriden if the spacing is negative
(anchor is inverted) or its sizePolicy is of type "Ignored" (it is
overriden by minSize).
Then, to decide where to store it, we aimed to make something similar
to what happens with item-internal anchors. Those can rely on their
items to get fresh information regarding their size, so we decided
that user-anchors (that don't have items, but do have QGraphicsAnchors)
could read such information from there.
This refactory also reduced the deep indirection that existed
in the "QGraphicsAnchor->setSpacing" call. Previously it would
call internal layout methods to do some black magic, that's now gone.
As the spacing information is now stored in the anchor itself, it
can do pretty much all the work and, after that, just invalidate the
layout.
Also, moved information like "AnchorData->hasSize" to QGAnchor as
its pretty much related to the preferredSize information itself.
Signed-off-by: Eduardo M. Fleury <eduardo.fleury@openbossa.org>
Reviewed-by: Caio Marcelo de Oliveira Filho <caio.oliveira@openbossa.org>
|
| |/
|
|
| |
Reviewed-by: Trust Me
|
| |
|
|
|
|
| |
Using operator[] can cause a deep copy if the container is not const.
Some of the containers were const, but I changed all of them to use at() since
its more Qt-style.
|
| |\
| |
| |
| | |
git://gitorious.org/~cmarcelo/qt/cmarcelos-clone into cmarcelo-vertexsimplification
|
| | |
| |
| |
| |
| |
| |
| |
| | |
Not all of the interpolation functions needed the orientation information,
and the one that needs can look at the orientation of the anchor in the
parameter. This simplified a little bit the function calls.
Signed-off-by: Caio Marcelo de Oliveira Filho <caio.oliveira@openbossa.org>
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Some vertices are connected by anchors with size 0, which means that
in practice, they represent the same point when positioning items,
i.e. their distance value is the same. In those cases, we can merge the two
anchors in one, that's what vertex simplification do.
The algorithm is walking in the graph, merging vertices in pairs (this could be enhanced to allow groups with arbitrary number of children vertices)
The vertex simplification stage happens before the anchor
simplification, so it'll make less passes. Also, in some situations of
redudant anchors it will allow more anchors to be simplified.
This commit creates a new type of AnchorVertex, add the algorithm
for vertex simplification and restoration, make sure that distribution also
works with simplified vertices.
Consequences:
- the assert after creating a sequence might not be true anymore, it
was a structural assumption that vertex simplification may destroy;
- we assumed that a center anchor could appear only in the beginning
or end of the candidates, because the "center vertex" always would
have 3 adjacents. A mix of parallel+center and vertex
simplification break that assumption.
The commit deal with those consequences.
We still have one limitation: vertex simplification needs to restore
the graph in every invalidation (which might be caused by some child's
updateGeometyry()), since a change in the sizeHint might cause a new
anchor to have size 0 or a 0-sized anchor to have a different size. In
the future we can track the 0 sized anchors and only
restore/re-simplify when the set changes.
Signed-off-by: Caio Marcelo de Oliveira Filho <caio.oliveira@openbossa.org>
Reviewed-by: Eduardo M. Fleury <eduardo.fleury@openbossa.org>
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This commit make possible to parallelize anchors that are center
anchors, i.e. that have extra constraints (stored in
itemCenterConstraints).
This is trivial to support since the parallel anchor will have the same
size as its children, so it can just "take the place" of its children in
the constraints. Restore function was added as well.
To manipulate internal structures, relevant static functions were
promoted to methods.
Signed-off-by: Caio Marcelo de Oliveira Filho <caio.oliveira@openbossa.org>
Reviewed-by: Eduardo M. Fleury <eduardo.fleury@openbossa.org>
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
The restore algorithm had a leak, so we did not delete all the sequences
and parallel anchors that were not part of the simplified graph, i.e.
that were nested inside other anchors.
This commit fix the leak and clean the restore function a little bit, so
the recursive function is called even for Normal anchors (which are
dealt accordingly). Note that the before/after information is exactly the
->from/->to information available in the anchor being looked on.
Also added an assertion to document the fact that at this point
(restoring anchor simplification), one of the two anchors inside a parallel
anchor must be a sequence. The algorithm depends on that because you
can't have two anchors with the same start and end points.
Signed-off-by: Caio Marcelo de Oliveira Filho <caio.oliveira@openbossa.org>
Reviewed-by: Eduardo M. Fleury <eduardo.fleury@openbossa.org>
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Simplify the code of interpolateSequentialAnchor to use the distance
values of the sequential anchor itself as base for the children
distances. So the 'base' parameter was removed.
This also allowed out-of-order parallel anchors to be interpolated, and
the 'base' parameter also to be removed from interpolateParallelAnchor.
Signed-off-by: Eduardo M. Fleury <eduardo.fleury@openbossa.org>
Reviewed-by: Caio Marcelo de Oliveira Filho <caio.oliveira@openbossa.org>
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Now parallel anchors account for the fact they may be composed of
anchors with different directions. We arbitrarily set the direction
of the parallel anchor to be the same direction as the first child.
The methods refreshSizeHints and updateChildren were updated to
support this situation.
Signed-off-by: Eduardo M. Fleury <eduardo.fleury@openbossa.org>
Reviewed-by: Caio Marcelo de Oliveira Filho <caio.oliveira@openbossa.org>
|
| |/ |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
After meeting with Jan-Arve, we are removing the support for
the expanding size hint flag.
The reason for that is that such feature adds too much complexity
to the existing code and makes it harder for us to implement
planned changes, like the support for out-of-order simplification.
As these changes are consireded more important than the support
for the expanding sizeHint, we are dropping expanding support
for now. Once the QGAL is more stable and we have more time
available, we can consider bringing it back.
Signed-off-by: Eduardo M. Fleury <eduardo.fleury@openbossa.org>
Reviewed-by: Caio Marcelo de Oliveira Filho <caio.oliveira@openbossa.org>
|
| |
|
|
|
| |
Signed-off-by: Eduardo M. Fleury <eduardo.fleury@openbossa.org>
Reviewed-by: Caio Marcelo de Oliveira Filho <caio.oliveira@openbossa.org>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Some anchors have their sizes linked directly to the size of
others. That is the case for instance with center anchors where
one half must have exactly the same size as the other.
To make that more clear, adding "dependency" info to AnchorData
and setting it accordingly. This is future proof in the sense
that if someday we are allowed to anchor to other items in terms
of percentages, like, anchor to 70% of an items' width, we would
also need this notion.
Knowing that, we no longer need to create size hint constraints for
the slave anchors, only for the master ones. The size of slave anchors
is enforced by the dependency constraint (sizeSlave = X * sizeMaster).
Signed-off-by: Eduardo M. Fleury <eduardo.fleury@openbossa.org>
Reviewed-by: Caio Marcelo de Oliveira Filho <caio.oliveira@openbossa.org>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This commit improves the way QGAL handles setups where most anchors
or items do not have explicit maximum sizes.
By default the internal layout anchors and others, have maximum size
of QWIDGETSIZE_MAX. It happens though that this value is rather arbitrary
but yet, can restrict the size of other paths in the layout.
For instance, in the setup below, where the maximum sizes of A and B is
not set:
________ ________
| | item A | | item B | |
o---o--------o---o--------o---o
| |________| |________| |
| |
| (layout structural anchor) |
o-----------------------------o
| |
the bottom path, of maximum size QWIDGETSIZE_MAX, restricts the lenght
of the path at the top, of maximum size of 2 x QWIDGETSIZE_MAX.
This introduces the need of fair distribution in the path A-B. While
that's not an issue when the path is simplified to a single anchor,
it may lead to unbalanced distributions if such simplification is
not possible. As this case may arise when we have center anchors
in the top path, it may appear in real-world cases.
To work around that, we do not limit the maximum width of the layout
anchor or parallel anchors that may have taken its place. The practical
result in the example above is that the sizeAtMaximum will be set at
2 x QWIDGETSIZE_MAX, with a good distribution of A and B.
On the other hand, this oversized layout is not a problem because the
effectiveSizeHint code enforces the respect of QWIDGETSIZE_MAX. That
means the layout will interpolate only between zero and QWIDGETSIZE_MAX
even though its internal maximum size is twice that value.
Signed-off-by: Eduardo M. Fleury <eduardo.fleury@openbossa.org>
Reviewed-by: Caio Marcelo de Oliveira Filho <caio.oliveira@openbossa.org>
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
Our helper function addAnchorMaybeParallel() returned 0 to indicate an
unfeasible setup, so we ended up without the pointer to the new parallel
anchor (which was created regardless the feasibility).
While we don't make use of this information right now, vertex
simplification will need to store those new parallel anchors even when
they are not feasible.
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>
|
| |\ |
|
| | |\
| | |
| | |
| | | |
into cmarcelo-fixes
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Sets the orientation bit for complex anchors. This is being done in the
constructor, and I did a minor refactor to make the constructor of
SequentialAnchor take the list of vertices and anchors that it is
simplifying. Before that we set one of those directly in the structure
and the other via a setter function.
The tests were passing because right now, complex anchors do not use the
orientation bit, while some Normal anchors use in the refreshSizeHints()
function (to get either the width() or height() of an item).
Signed-off-by: Caio Marcelo de Oliveira Filho <caio.oliveira@openbossa.org>
|
| | |\ \
| | |/
| | |
| | |
| | |
| | |
| | |
| | | |
git://gitorious.org/~fleury/qt/fleury-openbossa-clone into openbossa-fleury-fixes3
Conflicts:
src/gui/graphicsview/qgraphicsanchorlayout_p.cpp
src/gui/graphicsview/qgraphicsanchorlayout_p.h
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
The idea is to allow QSimplex solver to modify the constraints
without breaking other parts of the code that rely on the original
ones.
Signed-off-by: Eduardo M. Fleury <eduardo.fleury@openbossa.org>
Reviewed-by: Caio Marcelo de Oliveira Filho <caio.oliveira@openbossa.org>
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
We usually create two restrictions for each item, one to tell its
size should be more than its minimum size and other enforcing it to
be at most its maximum size.
Now, for items that have fixed size, ie. minSize == maxSize, we create
a single constraint telling its size should be equal its min/maxSize.
The immediate advantage is to have one less constraint for each of
these items. The indirect advantage is that the simplex solver can
take advantage of such information.
Signed-off-by: Eduardo M. Fleury <eduardo.fleury@openbossa.org>
Reviewed-by: Caio Marcelo de Oliveira Filho <caio.oliveira@openbossa.org>
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
The 'isLayoutAnchor' is necessary only as a way to flag Layout
internal anchors, i.e. anchors with the Layout as 'item' in the
AnchorData structure.
We don't need to propagate this bit when composing anchors.
Signed-off-by: Caio Marcelo de Oliveira Filho <caio.oliveira@openbossa.org>
Reviewed-by: Eduardo M. Fleury <eduardo.fleury@openbossa.org>
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Use a free bit in the anchor struct to save the orientation
information. That way we do not depend on looking for this information
in the vertices (by looking the orientation of its edge).
Signed-off-by: Caio Marcelo de Oliveira Filho <caio.oliveira@openbossa.org>
Reviewed-by: Eduardo M. Fleury <eduardo.fleury@openbossa.org>
|
