Silenced a false-positive warning about anchor visibility.
It was invisible because we're within a main window show()
It will be checked by the unit-tests and fuzzer anyway. No need to
do it in production.
It doesn't make sense to only grow one side, as sometimes the item
must grow in both sizes, as the right side might now have enough
to acomodate its needs.
This also allows us to not use Anchor::ensureBounded(), as separators
being within their bounds doesn't imply min sizes being respected, while
the inverse is true
fuzzer testcase 10.json now passes
When a separator is following other it becomes invisible. But if the
followee is deleted we weren't detecting that.
Connect to the followee's QObject::destroyed() signal so we stop following
and show this separator
When hidding a dockwidget we shift the left separator 50% and the right one
50%, instead of left 100%, so it's fair. But if the separator has other
visible dock widgets then no shifting should happen.
When adjusting the vertical separators we should only check if
the group has enough width. It's height is adjusted in ensureAnchorsBounded().
(And vice-versa)
Found via fuzzer's test-case 9.json. Passes now.
If the anchorThatMoved actually increased size then we were
calculating the signess wrong and the item would shrink.
Just check if the anchor is a side1 anchor in the group, if yes
then position must decrease so group grows
As they might be running on an incomplete state, during some
operation.
Instead move it to MultiSplitterLayout::checkSanity() which is
run at the end of operations
We don't want to count the size of separators that are following
others, but we might be in the middle of an operation that will
change which separators are following, like when restoring a placeholder.
So query the actual separators that will follow.
Fixes fuzzer 8.json and 2.json
In the above case:
+--------+---+
| 1 | 6 |
| | |
+---+----| |
| 2 | 8 | |
| | | |
+---+----+---+
Supposing 8 is hidden (it's a placeholder), then the separator between 2
and 8 is following the big vertical one between 1 and 6. Now, if the size constraints
of the widget hosted by 2 increases, which might lead to the main window having to increase,
then we have to move that big separator. Problem was it was only honouring the min size of widget 1
because 8 was hidden.
ensureAnchorsBounded() shouldn't be run while in an inconsistent
state. And it's already run at the end of restoring placeholders.
Fixes fuzzer test case 2.json
It wasn't called because the min size decreased, so setSize()
was a no-op, so ensureAnchorsBounded() was skipped.
But the internal widgets constraints can change, so still call ensureAnchorsBounded().
So the layout can grow first and not complain there's not enough
space.
Fixes fuzzer test-case 3.json.
The warning was: "Constraints not honoured" in Item::onLayoutRequest()
It was intersecting with the Item by 1 pixel.
This fixes fuzzer test 1.json.
The warning would look like:
MultiSplitterLayout::checkSanity: Widget <item> with rect <rect> intersects anchor <anchor>
~Frame() triggers MultiSplitterLayout to emit visibleWidgetCountChanged()
which the Frame being destroyed is connected to. So disconnect before
~QWidget runs.
Frame::updateTitleBarVisibility() was bailing out early. That
guard looks like some leftover, m_dropArea isn't even dereferenced
there, so just remove the guard.
