| 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>
|
| |
|
|
|
|
|
|
|
| |
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>
|
| |
|
|
|
|
|
|
| |
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>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
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>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
As part of the refactoring of the setSpacing logic, we are encoraging
the analogy between the references to QGraphicsLayoutItem and to
QGraphicsAnchor, from the AnchorData point of view.
It happens that leaf anchors (ie, those that were not created by the
simplification) either represent an item or an user-created anchor.
This means that they should fetch their size information either from
a QGraphicsLayoutItem (member AnchorData->item) or from a QGraphicsAnchor
(member AnchorData->graphicsAnchor).
Thus, I'm organizing the header to make it more consistent to
the new concept.
Signed-off-by: Eduardo M. Fleury <eduardo.fleury@openbossa.org>
Reviewed-by: Caio Marcelo de Oliveira Filho <caio.oliveira@openbossa.org>
|
| | |
|
| |
|
|
|
|
|
|
| |
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>
|
| |
|
|
|
|
|
|
|
|
|
|
| |
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>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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 '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>
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
We used to look for this information in the anchor's from and to
vertices, but to enable simplification of vertices, we have to store
this information in the anchor.
Signed-off-by: Caio Marcelo de Oliveira Filho <caio.oliveira@openbossa.org>
Reviewed-by: Eduardo M. Fleury <eduardo.fleury@openbossa.org>
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
The calculate graphs now can return early due to unfeasible anchor
setups found out during simplification. This allows finding out
problems in parallel anchors, when one anchor has maximum size smaller
than the minimum size of the other anchor.
The order for simplification and refreshing size hints also has been swaped:
- First, refresh size hints for all anchors in the graph. If the graph is
simplified, the refreshSizeHints() call will reach the children anchors.
- Then, if the simplificated graph is invalid, rebuild it. During this
rebuild, refreshSizeHints_helper() will be called for all levels.
So in both situations we can identify an unfeasible setup. Note that
this test alone is not enough to classify the graph as feasible, depending
on the graph, it will still need to go through the Simplex.
A test case was added and the function that traverse the graph
refreshing now is called refreshAllSizeHints(). The old name was not
so clear since the function will not fill only the anchors that have
items associated.
Last but not least, the lastCalculationUsedSimplex variable is cleared
when starting calculateGraphs(), since we now can leave the function
earlier, without reaching calculateTrunk(), which is the function that
sets it.
Signed-off-by: Caio Marcelo de Oliveira Filho <caio.oliveira@openbossa.org>
Reviewed-by: Eduardo M. Fleury <eduardo.fleury@openbossa.org>
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Now the refreshSizeHints() returns a boolean, and the parallel anchor
will return false in unfeasible cases, e.g. one anchor has maximum
size smaller than other minimum size.
Signed-off-by: Caio Marcelo de Oliveira Filho <caio.oliveira@openbossa.org>
Reviewed-by: Eduardo M. Fleury <eduardo.fleury@openbossa.org>
|
| | |/
| |
| |
| |
| |
| |
| |
| |
| |
| | |
We move the QLayoutStyleInfo class out of the gridlayout engine to a
common header file so that anchor layout also can utilize it.
Due to that we now can have a per-item spacing we have to change the
'effectiveSpacing' argument of refreshSizeHints to just take a
QLayoutStyleInfo pointer that we will later query for the actual
spacing used.
|
| |/
|
|
| |
Reviewed-by: tom
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
After this commit, when you modify the spacing of an anchor you are
effectively modifying the preferred size of the anchor, since all
anchors (except internal ones) have their minimumSizeHint to 0 and
maximumSizeHint to QWIDGETSIZE_MAX.
I also changed the sizeHintsFromItem to be more generic so that I could
use it for anchors. (Thus, it was renamed to "internalSizeHints"). It
now only takes care of setting the min/pref/exp/maxSize of AnchorData
based on the anchor/item size hint and their size policies.
As a consequence of all of this, setFixedSize changed behaviour and
became setPreferredSize (since setSpacing is basically setPreferredSize).
The implementation of that now only sets the prefSize.
The patch also has an unrelated fix for IgnoreFlag, where it will
(again) return the minimumSize for sizeHint(Qt::PreferredSize) instead
of the maximumSize. This was to be more consistent with
qgridlayoutengine.cpp. The docs are not very clear on this behaviour
unfortunately.
This API change has been discussed.
Reviewed-by: alexis
|
| |
|
|
|
|
|
| |
The problem was that lastCalculationUsedSimplex was only compiled in
debug mode. The autotests run in release, so it did not compile.
Reviewed-by: alexis
|
| |\
| |
| |
| |
| |
| |
| | |
git://gitorious.org/~fleury/qt/fleury-openbossa-clone into openbossa-fleury-fixes
Conflicts:
src/gui/graphicsview/qgraphicsanchorlayout_p.cpp
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Create calculateTrunk() and calculateNonTrunk() methods, that
calculate sizes for anchors in different parts of the simplified graph
(using simplex when needed).
Also fixes a minor leak when the nontrunk part is non-feasible. The
old code left the loop leaving the contents of 'sizeHintConstraints'
not allocated.
Signed-off-by: Caio Marcelo de Oliveira Filho <caio.oliveira@openbossa.org>
Reviewed-by: Artur Duque de Souza <artur.souza@openbossa.org>
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
After calculations, update the size of all anchors in the simplified
graph. Those updates were happening locally after each calculation
(trunk and semifloats), however some anchors that were not involved in
simplex calculation were missing.
One concrete consequence of the previous behaviour is that semifloat
parts that were simplified into just one anchor, didn't have the chance
to set their sizeAt* values. One consequence of the new behaviour is
one more test passing.
Signed-off-by: Caio Marcelo de Oliveira Filho <caio.oliveira@openbossa.org>
Reviewed-by: Artur Duque de Souza <artur.souza@openbossa.org>
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Change the functions solvePreferred() and solveExpanding() to take a
list of variables, so they don't need to calculate them based on the
list of constraints. That way, the trunk variables are calculated only
once.
This commit also reduce the scope of 'sizeHintConstraints' variable
instead of clearing and reusing it.
Signed-off-by: Caio Marcelo de Oliveira Filho <caio.oliveira@openbossa.org>
Reviewed-by: Artur Duque de Souza <artur.souza@openbossa.org>
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This is one good way to track whether simplification is doing all its
job or not. However it can only track cases where the graph simplify
to only one anchor. For more complex cases the graph dumps are the way
to go.
Signed-off-by: Caio Marcelo de Oliveira Filho <caio.oliveira@openbossa.org>
Reviewed-by: Artur Duque de Souza <artur.souza@openbossa.org>
|
| | |
| |
| |
| |
| |
| |
| |
| |
| | |
The graph dumper function take a name, and added debug code (that need
to be enabled manually) to generate dumps from the graph before and
after calculation. This is useful to debug simplification.
Signed-off-by: Caio Marcelo de Oliveira Filho <caio.oliveira@openbossa.org>
Reviewed-by: Artur Duque de Souza <artur.souza@openbossa.org>
|
| | |
| |
| |
| | |
We changed the behaviour of that, so the name should reflect that.
|
| |/
|
|
|
| |
Makes the code a bit easier to read and speeds up setItemsGeometries()
in the normal use-case.
|
| |
|
|
|
|
| |
There is only one change in the actual code here, and it simply removes
an unnecessary initialization of hasSize in the ctors of the composite
anchors.
|
| |
|
|
|
|
|
|
|
|
|
| |
situation
We make use of the anchor visited on findPaths() to keep track of how many items are visited when
walking on the graph. We can use this information of how many items are reachable (non-float) in order to check
if we have floating items (not reachable from any graph vertex). If so, we have a situation not supported by now.
Signed-off-by: Jesus Sanchez-Palencia <jesus.palencia@openbossa.org>
Reviewed-by: Caio Marcelo de Oliveira Filho <caio.oliveira@openbossa.org>
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
Updating "refreshSizeHints" and "updateChildrenSizes" methods for standard,
parallel and sequential anchors, in order to support the expanding SizePolicy
flag.
This adds the logic required to calculate equivalent expected/nominal expanding
size (AnchorData::expSize) as well as the logic to propagate the effective
size when in the expanding state (AnchorData::sizeAtExpected).
Signed-off-by: Caio Marcelo de Oliveira Filho <caio.oliveira@openbossa.org>
Reviewed-by: Eduardo M. Fleury <eduardo.fleury@openbossa.org>
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
Now we can use refreshSizeHints_helper() to initialize complex
anchors (parallel and sequential). This avoids duplication of
code in the function simplifySequentialChunk().
This commit also 'disable' ExpandFlag temporarily, stabilizing the
tests for the simplification. The next commit should re-enable it
implementing the necessary code for simplification as well.
Signed-off-by: Caio Marcelo de Oliveira Filho <caio.oliveira@openbossa.org>
Reviewed-by: Eduardo M. Fleury <eduardo.fleury@openbossa.org>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Use just one constructor for AnchorData and tweak the struct when
necessary. Also use the function refreshSizeHints() for Normal anchors
to get the item information instead of passing to the constructor.
This has the advantage that we don't need to replicate the code for
checking and updating the size hint and size policies. Note that the
code before only considered the size policies after the first
refreshSizeHints() -- which we know will be called after the
simplification, so the assumption seems to be correct, but we don't
depend on that anymore..
Signed-off-by: Caio Marcelo de Oliveira Filho <caio.oliveira@openbossa.org>
Reviewed-by: Eduardo M. Fleury <eduardo.fleury@openbossa.org>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
To support the expanding size policy we had to change the way the setup
process work. Previously we used to calculate three key-frames using
the simplex solver:
- sizeAtMinimum: the value an anchor should be in when the layout is
at its minimum size. Calculated using simplex solver
to minimize the layout size.
- sizeAtPreferred: the value an anchor should be in when the layout is
at its preferred size. Calculated using simplex solver
to minimize the deviation from the items preferred
sizes.
- sizeAtMaximum: the value an anchor should be in when the layout is
at its maximum size. Calculated using simplex solver
to maximize the layout size.
That worked fine but didn't diferentiate standard items from the
"expanding" ones. In other words, all items would grow from their
sizeAtPreferred to their sizeAtMaximum at the same rate.
To support the idea of "expanding" items, ie. items that should grow
faster than the others, we added a fourth state, between preferred
and maximum.
Now we have the following interpolation order:
sizeAtMinimum -> sizeAtPreferred -> sizeAtExpanding -> sizeAtMaximum.
The definition of the "expanding" state is that all "expanding" items
should have grown all the way to their "sizeAtMaximum" values whereas
non expanding items should have kept their preferred sizes. The only
exception is that non-expanding items are allowed to grow if that is
necessary to allow the "expanding" items to reach their sizeAtMaximum.
So, the visual result is that if the layout is resized from its
preferred size to its maximum size, the expanding items will grow
first and then, in a second phase, the other items will grow.
This commit adds QGALPrivate::solveExpanding() and calls it from
calculateGraphs().
Signed-off-by: Eduardo M. Fleury <eduardo.fleury@openbossa.org>
Reviewed-by: Artur Duque de Souza <artur.souza@openbossa.org>
|
| |
|
|
|
|
|
|
|
|
| |
Adding required members for the upcoming support of the
QSizePolicy::Expand flag.
In this state, running with simplification will probably not work.
Signed-off-by: Eduardo M. Fleury <eduardo.fleury@openbossa.org>
Reviewed-by: Artur Duque de Souza <artur.souza@openbossa.org>
|
| |
|
|
|
|
|
|
| |
hasConflicts() does only make sense for a tool/editor of the layout,
and how this function would help the tool is only guesswork at the
moment.
We keep the private API though, in order to let the autotests we
inherited from Orbit pass.
|
| | |
|
