| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
| |
Change-Id: Ia82322488e804ba40d4c91d0bc7e6431ebe973be
Reviewed-by: J-P Nurmi <jpnurmi@theqtcompany.com>
|
| |
|
|
|
|
|
| |
Update old header.LGPL3 to header.LGPL
Change-Id: I3c851bc24da89f6300b94199387d1adf16ca4f48
Reviewed-by: Lars Knoll <lars.knoll@theqtcompany.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
This should make them available to other types of layouts, such as
StackLayout
* geometryChanged() is now reimplemented in QQuickLayout, and will call
the virtual rearrange()
* As a consequence, isReady() is also moved up to QQuickLayout
* invalidateSenderItem() is moved up
* Moved some of the itemChange() code up
Change-Id: I7388ff648f70ba20a1f944485724a28249524848
Reviewed-by: J-P Nurmi <jpnurmi@theqtcompany.com>
|
| |
|
|
|
| |
Change-Id: I1afa494332cd96d723c1a61250d177c39440beaa
Reviewed-by: Caroline Chao <caroline.chao@theqtcompany.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Currently, the way to achieve this is to make a proxy item in a layout:
RowLayout {
Item {
Text {
anchors.fill: parent
anchors.margins: 9
}
}
}
using Layout margins you can now skip the proxy item and instead write:
RowLayout {
Text {
Layout.margins: 9
}
}
Note that this is not the same as margins in the QLayout world, as this
only controls the margins between the layout container and its items.
This feature adds margins to each individual item inside the layout
The real logic is done by the container classes:
Layouts has the additional logic to adhere to them.
SplitView will be done in a separate commit.
Task-number: QTBUG-39724
Task-number: QTBUG-41559
Change-Id: I9c5c2a1e0ee43c1200b62009216c9f64d2875baf
Reviewed-by: J-P Nurmi <jpnurmi@theqtcompany.com>
|
| |
|
|
|
|
|
|
|
| |
- Renamed LICENSE.LGPL to LICENSE.LGPLv21
- Added LICENSE.LGPLv3 & LICENSE.GPLv2
- Removed LICENSE.GPL
Change-Id: I470909ba0980db33ab551790d619c59a35978590
Reviewed-by: Jani Heikkinen <jani.heikkinen@digia.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Due to the required snapping to pixel grid, there was a high risk of
reducing the size of an item to become smaller than its minimum size.
With the original way of snapping (simply doing qRound) it didn't
happen very often, but with the last change the problem became more
evident:
If an item that covered the full extent of a
cell was snapped it would *always* shrink. Sometimes it could then
shrink to become smaller than its minimum size.
This was easy to see if the item snapped was a Text element with
eliding enabled, since that meant that the text was elided as soon
as the Text element got resized to smaller than its minimum.
The current solution now is to always snap the x,y coordinates
(with qCeil), but keep the width and height that was calculated
by the layout. This means that snapped items will be shifted slightly
to the right. Due to this they might extend almost a pixel outside their
calculated cell (on the right or bottom sides).
Due to this we also have to adjust the size hint result calculation so
that it will also ceil up to the nearest integer.
The only downside now is that row/column spacings might be less
than specified, but they should not reduce by more than 1 pixel.
Task-number: QTBUG-36235
Change-Id: Idca909f2102a1f7c5cb50d2490c7af39d722ff4f
Reviewed-by: Frederik Gladhorn <frederik.gladhorn@digia.com>
|
| |
|
|
|
|
|
| |
...and use the one we recently added to QtGui
Change-Id: I25965d98a7e4a45907f54dae94ba76465dd6ff0f
Reviewed-by: J-P Nurmi <jpnurmi@digia.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
Currently, the gridlayout engine is duplicated in QtQuick.Layouts module
and in QtWidgets module.
The plan is to move the gridlayout engine from QtWidgets to QtGui and
export it privately from there. However, that would produce linkage
errors when linking the QtQuick.Layouts module.
As a temporary solution we put the gridlayout engine in a namespace
until the move has been completed.
Change-Id: I8b43583cadff8846b5ed275f7fb5614737d903ad
Reviewed-by: Jędrzej Nowacki <jedrzej.nowacki@digia.com>
|
| |
|
|
|
|
|
|
| |
Previously it only respected the initial alignment.
Task-number: QTBUG-33773
Change-Id: I1d24209b866babd4bacabaec569f2f7dcc913c02
Reviewed-by: J-P Nurmi <jpnurmi@digia.com>
|
| |
|
|
|
| |
Change-Id: Ieb5f1a2c9fa81bdb6ff587ef84e97b2233f2e289
Reviewed-by: J-P Nurmi <jpnurmi@digia.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Do not bound explicit preferred size with implicit sizes. This
means that if Layout.preferredWidth was *explicitly* set to 50,
and Layout.maximumWidth had the implicit value 20, the effective
maximum width would be expanded to 50 in order to not disregard
the explicitly set preferred width. (covered by the tag
"expandMaxToExplicitPref" in test_sizeHint)
Note that this doesn't break any autotests, but the row layout
autotest was slightly changed to be able to add the new test cases.
This should make the behavior match the behavior of
QGraphicsGridLayout and QGraphicsLinearLayout
Change-Id: Ia23c8ef909827f14349906c003c72bb83689ef9a
Reviewed-by: Caroline Chao <caroline.chao@digia.com>
Reviewed-by: Jens Bache-Wiig <jens.bache-wiig@digia.com>
|
| |
|
|
|
|
|
|
|
|
|
|
| |
This reverts commit 91fc9b1823c0a95190005f3baaa4aa2276290f3a.
This patch got reverted because it broke the basiclayouts example on Mac OS.
However, the bug was in the basiclayouts example, so we can still add
this patch.
Change-Id: I97c3cf30dd5a5c97916b4811d8be0b5b5a7ebb4e
Reviewed-by: Jens Bache-Wiig <jens.bache-wiig@digia.com>
|
| |
|
|
|
|
|
|
|
| |
This reverts commit a4158c97d84d5c76126307213baf22d12babdbc2
This commit breaks the basiclayouts example so I am reverting it until we have a revised ifx.
Change-Id: I901924d292606ffe1e797232ad2f5ff02d8fc2d6
Reviewed-by: Jens Bache-Wiig <jens.bache-wiig@digia.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This was a bit inconsistent, because in the case of a Rectangle its
Layout.maximumWidth would return -1 by default (which was supposed to
be interpreted as infinity) However, since the maximumWidth propagated
up to the layout, the layout.Layout.maximumWidth would return
1000000000. Adding two Rectangles to the layout would make
layout.Layout.maximumWidth return 2000000000, and adding a third item
with Layout.maximumWidth:1 would make layout.Layout.maximumWidth
return 2000000001
With this change, since infinity + number = infinity, everything
that can grow to infinity will just return infinity.
In addition a developer can now more intuitively do comparisons
like this:
if (value > Layout.minimumWidth && value < Layout.maximumWidth)
instead of
if ((value == -1 || value > Layout.minimumWidth) &&
(value != -1 && value < Layout.maximumWidth))
Now, as a bonus, it becomes less consistent to set an attached
(min,max) property to -1 in order to reset it to its implicit value.
This also fixes a documentation issue with regards to the attached
Layout.{min|max}imum{Width|Height} properties. It only told the story
correct if the item was not a layout, and updates the docs for the max
sizes to mention that it returns Number.POSITIVE_INFINITY
Change-Id: Ia638064fd3ed5614d7e496a9b5e4aa8fcb7307f7
Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@digia.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When a layout did not have an implicit size nor any of the
Layout.preferred* properties set, the size hint calculation would
fall back to retrieving the width and the height properties of the
item. It would then store that value in the Layout.preferred*
property. This was wrong.
This could be a problem when an item was later added to the layout,
and consequently the implicit size of the layout got updated.
However, since the layout now had a preferred size set, a parent
layout would ignore the implicit size it had since it would settle
with the Layout.preferred* property (that's the rules the
effectiveSizeHint_helper work with).
The fix is to set the implicit width/height instead of the
Layout.preferred{width|height} property.
The compare in the test was actually by accident wrong, which can be
easily verified.
Change-Id: Ib9110dec7988a547441748698348227d1b8a077f
Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@digia.com>
|
| |
|
|
|
| |
Change-Id: I9312c49f54cd231dd1129e1dbbed93aa959f67f0
Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@digia.com>
|
| |
|
|
|
|
|
|
| |
These static function are only used by effectiveSizeHints_helper.
This broke because of commit 2b205db8514c0d64880edd77404b96460e5226bc
Change-Id: I189a59195d2576f4212b28fff4596bd803f25f49
Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@digia.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The previous code was a bit rough in how it determined if the item
was supposed to be ignored or not.
For instance, it did not ignore items with
Layout.maximumWidth: 0
or
Layout.preferredWidth: 0
Layout.fillWidth: false
The following patch will use
QQuickLayoutItem::effectiveSizeHints_helper. Since that is now shared,
it should make the behavior more consistent.
The patch also fixes a bug where ignored items (e.g. a hidden item)
was not re-added to the layout if it became visible again. (QTBUG-30796)
We use a QSet to keep track of the ignored items, and repopulate the
layout if any of the items in the QSet changed some properties relevant
for the layout.
Task-number: QTBUG-30796
Change-Id: Ia4b0584ed61e1b24efaca322551f6bb1a4228ca6
Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@digia.com>
|
|
|
This enables us to find the effective size hints without allocating a
QQuickGridLayoutItem.
Change-Id: I827e3196c0a3979a2f6f5a0d6f3622cd6d121645
Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@digia.com>
|
