| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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 "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>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
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>
|
| |
|
|
|
|
|
|
|
|
|
| |
Some tests and the example were leaking memory what made it
harder to investigate leaks on the layout itself.
Those were simple errors like not deleting the layout at the
end of the test and were corrected.
Signed-off-by: Eduardo M. Fleury <eduardo.fleury@openbossa.org>
Reviewed-by: Artur Duque de Souza <artur.souza@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>
|
| |
|
|
|
|
|
|
|
| |
This test ensures that internal anchors are not exposed through the
QGAL::anchor() API and also that the QGraphicsAnchors are deleted
when the associated anchors are deleted internally.
Signed-off-by: Eduardo M. Fleury <eduardo.fleury@openbossa.org>
Reviewed-by: Artur Duque de Souza <artur.souza@openbossa.org>
|
| |
|
|
|
|
|
|
|
|
|
| |
After a default spacing is set through QGAL::setSpacing() family
of methods, the user must be able to unset it.
To avoid adding another public method, we enabled this feature
by allowing a negative value to be passed to those methods.
Signed-off-by: Eduardo M. Fleury <eduardo.fleury@openbossa.org>
Reviewed-by: Anselmo Lacerda S. de Melo <anselmo.melo@openbossa.org>
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
After initial fix, 99% of widgets draw temselves properly after
orientation switch. However, QScrollAreas lose their palette hash,
which causes scrollarea background to re-start from theme background
top-left.
As a correction, we re-set the theme palette hash after calling
QApplication::setPalette, since that clears palette hash.
Task-number: QTBUG-6125
Reviewed-by: Alessandro Portale
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Fixing previous fixes of QS60StylePrivate::setBackgroundTexture with
commit SHAs a80e58335e69c8ce96d1596e0ed2d14e424a0d5e and
d4089399a3ab7548a864d5a399e08df85c444783
Now, the palette gets the updated background brush and the palette is
actually set as application palette.
Also making sure that QS60StylePrivate::handleDynamicLayoutVariantSwitch
does the right things in the right order. So that Table headers are not
broken after orientaion switch.
Task-number: QTBUG-6125
Task-number: QT-1478
Reviewed-by: Shane Kearns
|
| |
|
|
|
|
|
|
| |
Early push of this fix which should be overwritten by the fix
upstreamed in WebKit trunk later.
Reviewed-by: Simon Hausmann
(cherry picked from commit dddd3e5fc9658ebbb5f94b343e7c7c0cd27eb7f2)
|
| |\ |
|
| | |
| |
| |
| |
| |
| |
| |
| | |
Qt is using the same window message as Flash plugin. We need to check
the window handle before we treat this as Qt internal message.
Reviewed-by: Bradley T. Hughes
(cherry picked from commit 48e56643f1b7daf7c255a1e58f0e213b06e15f65)
|
| | |\ |
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
The problem is that the ChildIndicatorPolicy change the hasChildren
in the model. But this is cached in the QTreeView layout.
We must do a relayout to clear the cache.
Reviewed-by: Thierry
Task-number: QTBUG-3071
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | | |
The problem was that the images added to the PDF were not clipped to the expected area.
Task-number: QTBUG-3412
Reviewed-by: Trond Kjernaasen
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | | |
On the undo/redo stack, it needs to be treated as a separate command
Task-number: QTBUG-5786
Reviewed-by: ogoffart
|
| | | |\
| | | |
| | | |
| | | | |
4.6-staging2
|
| | | | |
| | | |
| | | |
| | | | |
RevBy: Trust me
|
| | | |\ \ |
|
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
Problem was that pending updates were not dispatched properly on the
Mac, which is strongly required in order to get correct behavior wrt
QGraphicsItem::update().
Task-number: QTBUG-4160
Reviewed-by: bnilsen
|
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
The problem was the QMacStyle didn't handle the pixel metric for
PM_TitleBarHeight correctly when passing a style option containing
an unitialized rect (empty rect). It already had special logic for
invalid rects, so the fix is simply to extend the check to also handle
empty rects.
Auto-test included.
Task-number: QTBUG-4160
Reviewed-by: msorvig
|
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
Task-number: QTBUG-1717
Reviewed-by: Thierry
|
| | | | |/
| | |/|
| | | |
| | | |
| | | |
| | | |
| | | | |
On 64bit, qint64(size_t(-1)) = -1
Reviewed-by: Joao
Reviewed-by: Thiago
|
| | | |\ \
| | | | |
| | | | |
| | | | | |
4.6-staging2
|
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
The window activation hack is not needed anynmore since
AppUi()->RemoveFromStack() ensures the next visible window will get
the keyboard focus.
Hack removal also required change to window title setting logic.
Since window title (and icon) are associated to top-level windows,
the logical place to set them is the same place where active window is
changed i.e. QApplication::setActiveWindow is called.
At the same time also window icon setting from show_sys was move to
focusChanged to make icon/title setting more consistent.
When changing orientation or switching to different statuspane
mode we receive KInternalStatusPaneChange events for each window in
QSymbianControl::HandleResourceChange. When receiving such event
we only need to reset the icon for focused/visible window. If we don't
handle it like this, it might happen that invisible widget added to
control stack resets the global icon/title.
Task-number: QTBUG-5780
Reviewed-by: Axis
|
| | | |\ \ \ |
|
| | | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
If the user enters a valid page range, which lies outside of the actual
number of printable pages, we can't detect that until the document
has been paginated.
Task-number: QTBUG-6051
Reviewed-by: Kim
|
| | | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
Task-number: QTBUG-4965
Reviewed-by: gabi
|
| | | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
The Intel Compiler inlined the destructor of QObjectPrivate too
agressively, causing it to generate a call to ~QObjectData for QtGui.
~QObjectData is not exported from QtCore, so it failed linking.
Task-number: QTBUG-5145
Reviewed-by: Alexis Menard
|
| | | | |\ \ \ |
|
| | | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
Reviewed-by: ogoffart
|
| | | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
Task-number: QTBUG-3521
Reviewed-by: prasanth
|
| | | | | |\ \ \ |
|
| | | | | | |/ /
| | | | |/| |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
The logicalIndices and visualIndices array where not clean of the
old sections, resulting in corrupted header.
Task-number: QTBUG-6058
Reviewed-by: Thierry
|
| | | | |\ \ \ \
| | | | |/ / /
| | | |/| | |
| | | | | | | |
git://gitorious.org/~fleury/qt/fleury-openbossa-clone into fleury-fixes2
|
| | | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
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>
|
| | | | |\ \ \ \
| | | | | | | |
| | | | | | | |
| | | | | | | | |
4.6-staging2
|
| | | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | | |
Requested by Nokia Dallas/Helix team. Patch supplied by Fu Liz
EXT-DextraTech/Dallas, minor changes by me.
Task-number: QTBUG-4882
Reviewed-by: Gareth Stockwell
|
| | | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | | |
Reviewed-by: Gareth Stockwell
|
| | | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | | |
From discussions with Helix team.
Reviewed-by: Gareth Stockwell
|
| | | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | | |
Task-number: QTBUG-4745
Reviewed-by: Miikka Heikkinen
|
| | | |/ / / / /
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
Since .otf fonts are not considered truetype fonts, they take the
code paths intended for non-outline fonts. When calculating the bounding
box of a glyph, this would mean we'd find the largest possible bounding
rect of any glyph in the font, while the other metrics, such as the GPOS
tables used to position diacritics in relation to base glyphs, are
positioning the actual outline of the glyph. The result was that certain
diacritics that depended on the opentype positioning would not be shown on
Windows at all, as they would be positioned based on the wrong left bearing
and height when drawn into the glyph cache.
The fix is to find the tight bounding rect of the outline whenever
possible and fall back to the old code when this fails. I've also added
the left bearing of the glyph to the bounding box in the fallback case,
as we did not respect this before and would misplace glyphs that has
a bearing.
Task-number: QTBUG-5860
Reviewed-by: Trond
|
