| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
| |
Declarative tripped these (crashes).
Reviewed-by:Aaron Kennedy
|
|
|
|
|
|
| |
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>
|
|/ /
| |
| |
| | |
course!
|
|\ \
| | |
| | |
| | | |
morpheuz-fixes
|
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
The widget has sizePolicy as a property and declaring that properly
helps scripting. Just as it was done with min/pref/max sizes.
Signed-off-by: Artur Duque de Souza <artur.souza@openbossa.org>
|
|\ \ \
| | | |
| | | |
| | | |
| | | | |
Conflicts:
dist/changes-4.6.0
|
| | | |
| | | |
| | | |
| | | | |
Reviewed-by: paul
|
| | | | |
|
|\ \ \ \ |
|
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
We need to make sure the active state is preserved if graphicsview are
dinamically shown/hide while window is active. Or if scene is changed
with setScene.
This fixes KRunner focus regressions
Reviewed-by: Andreas
Task-number: QTBUG-5281
|
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
When scene is not active, returns the item that would get the focus if
the scene became active.
This is more consistant with Qt 4.5 behaviour
Reviewed-by: Andreas
|
| | | | | |
|
|/ / / / |
|
|\ \ \ \ |
|
| |\ \ \ \
| | |/ / / |
|
| | |\ \ \
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
Conflicts:
src/gui/kernel/qevent.cpp
src/gui/kernel/qgesture.cpp
|
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
Reviewed-by: Trust Me
|
| | |\ \ \ \
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
Conflicts:
dist/changes-4.6.0
src/gui/kernel/qevent.h
|
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
Changes to the gesture api after the review.
Reviewed-by: Jasmin Blanchette
|
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
By default if the gesture is ignored, only gestures in the started state
are propagated, and accepting a gesture in the started state adds an
implicit grab meaning all the following events in the gesture sequence
will be delivered to that widget. This is similar to the way QTouchEvent
is propagated.
Also added a hint, which specifies if gestures in any state can be
propagated to the widget which has enabled the hint.
Reviewed-by: Thomas Zander
|
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
Oops, apparently we forgot to add a function for unsubscribing a
graphics object from a gesture. Fixing it now.
Reviewed-by: trustme
|
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
Reviewed-By: Denis
|
|\ \ \ \ \ \ \
| |/ / / / / /
|/| | | | / /
| | |_|_|/ /
| |/| | | | |
morpheuz-fixes
|
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
QGraphicsLayouts and specially QGraphicsAnchorLayout makes large
use of min/pref/max sizes. Making it properties allow QtScript
bindings to take advantage of this and eases the use of Anchor
Layout on this cases.
The first use case for this patch was the use that Plasma makes
of it on it's javascript engine.
Signed-off-by: Artur Duque de Souza <artur.souza@openbossa.org>
|
|\ \ \ \ \ \ |
|
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
This allows items to check painter->clipRegion() to find out what the
imposed clip is, in order to cull elements that don't need to be
painted. This is an alternative approach to getting the same
information from QStyleOptionGraphicsItem::exposedRect. It's better
because it's a pull operation, but it's slightly worse because it
doesn't include the complete system clip, and because QRegion has
integer resolution only (whereas QGraphicsItem's coordinate uses
qreal.
A better approach may be to access QPainter's combined clip region;
this option is open for future versions of Qt.
Original patch by Warwick (which is why he's on reviewed-by), but the
patch was modified to operate in device instead of logical coordinates.
Reviewed-by: jasplin
Reviewed-by: Warwick Allison
|
|\ \ \ \ \ \ \
| |/ / / / / /
|/| | | | | /
| | |_|_|_|/
| |/| | | | |
git://gitorious.org/~fleury/qt/fleury-openbossa-clone into fleury-fixes
|
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
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>
|
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
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>
|
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
This is required by the QtDeclarative module. As an isolated change,
this is just a noop. It takes effect when somebody reimpements the
private virtual function.
Reviewed-by: Alan Alpert
|
|\ \ \ \ \
| | |_|/ /
| |/| | | |
|
| |\ \ \ \
| | |/ / / |
|
| | |\ \ \ |
|
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
Reviewed-by: tom
|
| | | |/ /
| | |/| |
| | | | |
| | | | |
| | | | |
| | | | | |
However, compiling with QT_NO_ICON will still not work :(
Reviewed-by: tom
|
| | |_|/
| |/| |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Due to the rendering model in XRender ((src IN mask) OP dest) we can't
support the PorterDuff composition modes natively under X11. They
just behave differently than what we've defined them to do in QPainter,
and there is no apparent workaround.
Task-number: QTBUG-4829
Reviewed-by: Gunnar
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
QGraphicsItem::ItemScenePositionHasChanged
Merge-Request: 1945
Reviewed-By: Andreas
|