| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In upcoming patches, we start registering C++ types declaratively.
A condition of doing so requires that each .pro corresponds to one
QML module. This conflicts with the QtQuick.Controls import, which
currently does quite a lot:
- Registers (and selects) QML files for the style that was set
- Registers private C++ utility types (such as IconLabel) that are
useful for all styles under the QtQuick.Controls.impl import
- Registers private C++ types that are only useful for the Default
style (such as BusyIndicatorImpl).
The reason it does so much can probably be explained by the
intended usage of Qt Quick Controls 2; when you do
import QtQuick.Controls 2.0
you get access to the QML types (e.g. Button) that the style
you're using provides. So if you're using the Material style,
you'll get a Material style button. API-wise, the button is
identical to any other button, because the types in
QtQuick.Templates are what we advertise as the public API.
If we didn't have this functionality, users would need to
import specific style imports to use controls, and the
convenience of being able to simply start the application
with a different style by e.g. passing an application argument
would be lost.
To support declarative registration of types while also supporting
the existing use cases, we split out the Default-style-specific
stuff into a QtQuick.Controls.Default import.
Task-number: QTBUG-82922
Change-Id: Ib4f1620cae78d7acdc13d9ac0752a020bc22f3ea
Reviewed-by: Ulf Hermann <ulf.hermann@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>
|
|
|
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>
|
