| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
| |
...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>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Parts of the code assumed that if q_minimumDescent or q_minimumAscent
was valid, it would reserve enough space in each case for the combined
ascents and descents of all items in a row.
The extreme case was when one item had a baseline at its bottom edge,
and the next item had the baseline at its top edge, the layouts minimum
height tried to reserve space for such a case even though baseline
alignment was not desired.
The last case in the test demonstrates such a (valid) case. The problem
was that the same logic was applied to the first case.
Change-Id: Ie24503b1a5f7333f16ed84ebe01ab8d48becb4e2
Reviewed-by: Jens Bache-Wiig <jens.bache-wiig@digia.com>
|
| |
|
|
|
| |
Change-Id: Ie36dcf158f5901ef84ce8b3c06ea9e6069f9c294
Reviewed-by: J-P Nurmi <jpnurmi@digia.com>
|
| |
|
|
|
| |
Change-Id: Ieb5f1a2c9fa81bdb6ff587ef84e97b2233f2e289
Reviewed-by: J-P Nurmi <jpnurmi@digia.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
If no stretch factors were specified, we used the preferred size as a
stretch factor. Obviously, that didn't work if the preferred size was
actually 0.
This patch works around this by actually setting the stretch factor to
1.0 if this is the case.
This should work fine in most cases, except for the case where there
are also other items with a preferred size close to 0.
In this case, the item with preferred size 0 will just grow
faster than an item with e.g. preferred size 0.1.
Task-number: QTBUG-31217
Change-Id: Id5a3e19c9cd756860fc4052daee3eb5582f39d0c
Reviewed-by: Paul Olav Tvete <paul.tvete@digia.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
This was spotted while tracking down a similar bug related to spans.
The problem was only for the maximum size, since the size of an ignored
row/column was min: 0, pref: 0, max: FLT_MAX (the default constructed
values for a QGridLayoutBox).
Reviewed-by: Paul Olav Tvete <paul.tvete@digia.com>
(cherry picked from qtbase/9d7ae6dfbe25fb70a362a4cf955c187cd24cb007)
Change-Id: Ic0f3cf12639fbb6ab85c4946d9e8cc1d8d68e753
Reviewed-by: Jan Arve Sæther <jan-arve.saether@digia.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
If a row/column is only used only because of the spanning of an item,
the cell should be treated as it didn't exist. We keep track of this
with the "ignore" bit array.
The old code would always start from the row/column at position 1.
In the attached testcase this made the effectiveRowSpan become larger
than actually needed.
Task-number: QTBUG-30255
Reviewed-by: Paul Olav Tvete <paul.tvete@digia.com>
Change-Id: I410ed373f408014333d3964e2ddbcfeb25bec3a6
(cherry picked from qtbase/4f072e2d3d7e429359ff15a615d02712bff7ee51)
Reviewed-by: Jan Arve Sæther <jan-arve.saether@digia.com>
|
| |
|
|
|
|
|
|
| |
Only the vertical alignment will be centered. (This should probably
change to baseline once we support that).
Change-Id: I1993821ff2d63f4bcc9408b54d20c9b353693df3
Reviewed-by: Jens Bache-Wiig <jens.bache-wiig@digia.com>
|
| |
|
|
|
| |
Change-Id: Ie803af39d142a7c16f5bde2d70613d006c61eaa6
Reviewed-by: Jens Bache-Wiig <jens.bache-wiig@digia.com>
|
| |
|
|
|
| |
Change-Id: Ia6dab83628142363cdbcb6d98562ac7d9f9cfe9f
Reviewed-by: Jan Arve Sæther <jan-arve.saether@digia.com>
|
|
|
It now uses the gridlayoutengine from graphicsview, which
also gives us a well tested grid layout engine almost for
free.
Change-Id: I939ae4d2b321c8079935ff3374e8e5d10d02384b
Reviewed-by: Jens Bache-Wiig <jens.bache-wiig@digia.com>
|
