| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
| |
Task-number: QTBUG-84469
Change-Id: I4991ab7ce8ba8d2522005b1b0a78f7b474c54419
Reviewed-by: Mitch Curtis <mitch.curtis@qt.io>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When a handle is dragged, the items on either side of it are resized.
Until this patch, we were assuming that the item after the
one at the handle index was visible, which was wrong. Now we iterate
through each item after the one at the pressed index until we find
one that's visible. Since we need this in a few other places during
a handle drag, we cache it as a member variable.
This patch also fixes an issue where the visibility of handles were
not updated after setting a new handle delegate.
Change-Id: Icd246abae2ed4dc6c3b81217b9a241b7e4debf7d
Fixes: QTBUG-81867
Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
|
| |
|
|
|
|
|
|
|
|
|
| |
- Don't unset the hovered flag only to potentially set it again.
- Generally simplify the code.
- Move it into a new updateHoveredHandle() function so that
follow up patches can call it from other places.
- Add more logging to debug hover issues.
Change-Id: Iaf06cfe1f556a3f30bd0e883ef504b3df2dbc8e2
Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@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>
|
