| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
| |
items
Now every item starts with its geometry on ((0,0), preferredSize()).
By doing this we guarantee that every item will have a known initial value, which
can be specially useful on float cases for instance.
Signed-off-by: Jesus Sanchez-Palencia <jesus.palencia@openbossa.org>
Reviewed-by: Caio Marcelo de Oliveira Filho <caio.oliveira@openbossa.org>
|
|
|
|
|
|
|
|
|
|
|
| |
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>
|
|
|
|
|
|
|
|
|
|
|
|
| |
Since the AnchorData cleanup commit (c974aca8) all anchor initialization
is being done by refreshSizeHints. However that method was not able
to properly initialize the internal layout anchors.
This commit refactors that method both to add the functionality and
improve readability.
Signed-off-by: Eduardo M. Fleury <eduardo.fleury@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>
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This assertion started failing after the addition of expanding
state. After some investigation we felt that the assertion itself
was too strong and would fail in some valid cases.
The new assertion is formally right as it tests whether the
simplex solver was able to satisfy the simplex constraints,
_exactly_ what it is expected to do.
Signed-off-by: Eduardo M. Fleury <eduardo.fleury@openbossa.org>
Reviewed-by: Caio Marcelo de Oliveira Filho <caio.oliveira@openbossa.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The previous implementation of solveExpanding would assume that anchors
were either completely expanding (would grow to their sizeAtMaximum) or
non-expanding (would try to remain at their sizeAtPreferred).
What happens however is that with simplification enabled, we may have
anchors that are "partially" expanding. An example is a sequential
anchor that groups together two leaf anchors where only one of them
is expanding.
In this case, the expected size of that group anchor would be the sum
of the max size of the expanding child plus the preferred size of the
non-expanding child.
To handle the above case we added the "expSize" variable. It holds
the expected value at Expanding for each anchor. Based on this, and
the already calculated values of sizeAtMaximum and sizeAtPreferred,
the solver calculates the actual sizeAtExpanding for them.
Signed-off-by: Eduardo M. Fleury <eduardo.fleury@openbossa.org>
Reviewed-by: Caio Marcelo de Oliveira Filho <caio.oliveira@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>
|
|
|
|
|
|
|
| |
The font size was not respected because it is taken from the
request which could only contains the pixel size.
Reviewed-by: Richard
|
|
|
|
|
|
|
|
|
|
| |
If you reused a printer to paint to several different files, the
results would sometimes be different, as the subsequent runs would have
redundant setPen commands in its output. This was because the simplePen
flag was not reset to its initial value when reusing the print engine.
Task-number: QTBUG-4479
Reviewed-by: Trond
|
|
|
|
|
|
|
|
|
|
|
|
| |
QGraphicsWidget used to called setPosHelper where all the logic was.
But since the new flag itemSendsGeometryChanges some part of the code
inside setPosHelper move back to setPos. QGraphicsWidget was not updated
after this change. It doesn't matter as it is but for QGraphicsProxyWidget
which activate the flag itemSendsGeometryChanges it matters. ItemChange
was never called so the proxy was never really moved.
Task-number:QT-672
Reviewed-by:andreas
|
|
|
|
| |
Reviewed-by: Trond
|
|
|
|
|
|
|
|
|
| |
HAL::Get(HALData::EPen, TInt& result) may set 'result' to 1
on some 3.1 systems (e.g. N95). But we know that S60 systems
below 5.0 did not support touch. Let's use tahth knowledge
and work-around that N95 HAL bug.
Rev-By: Jani Hautakangas
|
|
|
|
|
|
|
|
|
|
|
| |
In some cases the QImage, returned by QS60PixmapData::toImage()
image an invalid pointer. That led to reproducable crashes on 3.1
Device and Emulator when starting a drag in the FridgeMagnets
demo. Jani Hautakangas created this fix and I tested it on
3.1 Device and Emulator confirming that the crash is gone.
Rev-By: Jani Hautakangas
Rev-By: Alessandro Portale
|
|
|
|
|
|
|
|
|
| |
QTextControl has two independent interaction flags
TextEditable and TextSelectableByKeyboard, i.e. the latter can also
apply in read-only mode. This used to be handled incorrectly
in QTextEdit.
Reviewed-by: con
|
|
|
|
|
|
|
|
|
| |
QTextControl has two independent interaction flags
TextEditable and TextSelectableByKeyboard, i.e. the latter can also
apply in read-only mode. This used to be handled incorrectly
in QPlainTextEdit.
Reviewed-by: con
|
|
|
|
| |
The variable updatesEnabled is not used on Mac OS X.
|
|
|
|
|
|
|
|
| |
Setting a pixmap brush when painting to a 32-bit target might cause the
source pixmap to be converted to 32-bit. We should detach the pixmap if
we need to convert it.
Reviewed-by: Trond
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The reason for the crash was the following: When we make menu entries
in Qt, we assign each item an arbitrary command ID. This is because
Symbian usually puts the items in a resource file and refers to them
by ID, but we need to be dynamic. These command IDs are also assigned
to cascading menu items (sub menus). When we then get a callback in
RestoreMenuL with one of submenu IDs, we used to ask Symbian to
construct the menu items for them, but Symbian doesn't know about
them.
Fixed by avoiding call into S60 code if the ID belongs to Qt.
Also put a cap on the number of menu items. It's very unlikely that
anyone will reach it, but it's better to have an actual check.
Task: QT-646
AutoTest: Manual testing went fine
RevBy: mread
|
| |
|
| |
|
|
|
|
| |
RevBy: Trust me
|
|
|
|
|
|
|
|
|
| |
QTextControl showed inconsistent behaviour with DeleteEndOfWord and
DeleteStartOfWord when the cursor had a selection. With this patch,
the commands will simply delete the existing selection, which is
consistent behaviour with in other IDEs.
Reviewed-by: Simon Hausmann
|
|
|
|
|
|
|
| |
The test tst_QListView::task254449_draggingItemToNegativeCoordinates was failing
in cocoa because of this. (on, cocoa, the call to show was doing the first paintEvent)
Reviewed-by: Thierry
|
|
|
|
| |
Reviewed-by: Bjoern Erik Nilsen
|
|
|
|
|
|
|
|
|
|
|
|
| |
When setting a large font using style sheets, the whats this
popup size calculation would be incorrect resulting in
half visible lables. By calling ensurePolished before showing the
label, we ensure that this will be properly handled.
We also added a new test case for whatsThis in tst_qtooltip
Task-number: QTBUG-2416
Reviewed-by: ogoffart
|
|
|
|
|
|
|
|
| |
Greatly improves performance in flush() for the non-MITSHM case on
16-bit displays. Instead of converting the whole image to a pixmap only
convert the sub-rect that's needed.
Reviewed-by: Gunnar
|
|
|
|
| |
Reviewed-by: Gunnar
|
|
|
|
| |
Reviewed-by: Gunnar
|
|
|
|
|
| |
Merge-request: 1541
Reviewed-by: Thiago Macieira <thiago.macieira@nokia.com>
|
|
|
|
|
|
|
|
| |
Change authored by Rhys.
Bug introduced by the change to allow user-specific cache and pipe
directories.
Reviewed-by: Jeremy
|
|
|
|
| |
Reviewed-by:TrustMe
|
|
|
|
|
|
|
|
|
| |
We reuse tooltip whenever we can. But we forget to check if
the format of the text changes inbetween (from html to plain).
This causes the word wrap to fail sometimes. This change will
fix that.
Rev-By:MortenS
|
|
|
|
|
|
|
|
|
|
|
| |
QStateMachine framework installs QObject event filters to catch events
in order to triggers the proper transition. But installing a QObject event
filter on a QGraphicsObject gives nothing because QGraphicsView events
filters works differently. In order to make this works we now post
events using QApplication::postEvent in addition to the QGraphicsView
events.
Reviewed-by:andreas
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When rendering etched text on disabled rich text labels
we would previously draw distorted links.
This is basically because anything that
did not render with the text foreground role would
be drawn twice as a shadow. Since there is no way to properly
render this text etched we will rather disable it completely
when the label uses rich text.
Task-number: QTBUG-4543
Reviewed-by: Simon Hausmann
|
|
|
|
|
|
|
|
|
|
|
|
| |
It wasn't possible for the paint engine to override the drop
shadow filter because QPixmapDropShadowFilter::draw() was not
asking for an engine-specific filter object.
Also, change the OpenVG filter to use vgGaussianBlur() instead of
vgConvolve(), and draw the original image on top of the shadow.
Task-number: QTBUG-4583
Reviewed-by: trustme
|
| |
|
|
|
|
| |
Not sure why the migration classes should be are \obsolete.
|
|
|
|
|
| |
Mark QGraphicsAnchor::unsetSpacing as reset function of the spacing
property.
|
| |
|
|
|
|
| |
Reviewed-by: Trond
|
|
|
|
|
|
|
|
|
| |
This is internal API.
It's possible to specify a horizontal and vertical scale, rotation,
opacity and source rectangle for each pixmap item.
Useful for particle effects.
Reviewed-by: Trond
|
|
|
|
| |
New API will most likely not be in the Beta release.
|
|
|
|
|
|
| |
Seems like I forgot to handle page scrolls.
Also did a small optimization
(see also 45f095b8970dc3c1b6f6e97fa2323654ba848288)
|
|\ |
|
| | |
|
| |
| |
| |
| |
| |
| |
| |
| | |
It turns out that we need to let singleStep keep its value
in qtextedit so that pushing the up/down buttons on the slider
works as they should. Moreover, overriding the behaviour in
abstract slider also makes QGraphicsView work out of the box.
Also added in the test fix suggested by Olivier.
|
| |
| |
| |
| |
| |
| |
| | |
Stretch, Repeat and Round are too generic. Renamed to StretchTile,
RepeatTile and RoundTile.
Reviewed-by: Gunnar
|