| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
| |
Change-Id: Icc236494f5df382d6bc49092d23a460822c835a1
Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@qt.io>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
If the attached property object was created on an item that SplitView
doesn't manage, then its m_splitView member will be null, so check
for that.
Sometimes, an attached SplitView object will be created on an item
that SplitView _does_ manage, but SplitView's own contentItem hasn't
been created yet (see the comment in the QQuickSplitViewAttached
constructor). In that case the SplitView will see the item added
as a child of its contentItem eventually, and we just have to wait.
While we are waiting, check access to our members in case they are
null.
Fixes: QTBUG-74276
Change-Id: I70b7f017e621e0d15c239b962f0407743eb70b15
Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@qt.io>
|
| |
|
|
|
|
|
|
| |
Work was probably started before 5.12 but the patch ended up getting
merged in time for 5.13. It seems that I forgot to update the versions.
Change-Id: I19edf08158cca0967a7a536b3aee326e3b393d4c
Reviewed-by: Kai Koehne <kai.koehne@qt.io>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
As mentioned in the review of ed87e837, there could be a scenario where the
user sets the preferred size of an item inside the onWidthChanged handler
of another item:
onWidthChanged: if (width < 10) secondItem.SplitView.preferredWidth = 100
Before this patch, this would result in the preferredWidth assignment being
ignored since it happened during a layout.
This patch adds some auto tests to ensure that this works, as the previous
patch (that converted layouts to be done in polish/updatePolish cycles)
already fixed the issue.
It also adds a check to avoid doing too many layouts in the case of
one of the split handles being dragged.
Change-Id: Ide519b33a2fa3bf746ae3793e0671fd1750c70d8
Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@qt.io>
|
| |
|
|
|
|
|
|
| |
This results in less layouts, especially when a bunch of properties change
one after the other.
Change-Id: I8dd76d147bcc20f2ccddb587e59ac3e59f580f21
Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@qt.io>
|
| |
|
|
|
| |
Change-Id: Id81aac71f26ec9cbf643fdc480d76841d1e3be47
Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@qt.io>
|
|
|
SplitView is an important tool for desktop applications that do not
want to use a dock widget-style approach for their user interface.
It allows users to have some degree of control over the sizing of
elements in the UI, as well as the ability to conveniently serialize
those sizes so that they're remembered across sessions.
The main differences between this and the SplitView in
Qt Quick Controls 1 are:
- Has its own SplitView attached properties, rather than relying on
the Layout attached properties (which required an additional import).
- Uses the attached preferredWidth and preferredHeight properties
as well as Item's implicitWidth/implicitHeight properties
for the preferred size of items, rather than using the width and
height properties.
- Inherits from Container, so supports most of its API (though some
parts of the API, like the currentIndex-related stuff, make no
sense for SplitView).
- Uses attached SplitHandle properties for the handle delegate to
visualize hovered/pressed effects.
- Offers convenience API for serializing the user's preferred sizes.
[ChangeLog][Controls][SplitView] Introduced SplitView, a control that
lays out items horizontally or vertically with a draggable splitter
between each item.
Task-number: QTBUG-56318
Change-Id: I3da91643ab312eb9ef5b0567da4e758f17747192
Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@qt.io>
|
