qiurui
/
qtdeclarative
mirror of https://github.com/qt/qtdeclarative.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity
qtdeclarative/examples/quick/shapes/interactive.qml

229 lines
7.1 KiB
QML
Raw Normal View History

Use SPDX license identifiers Replace the current license disclaimer in files by a SPDX-License-Identifier. Files that have to be modified by hand are modified. License files are organized under LICENSES directory. Pick-to: 6.4 Task-number: QTBUG-67283 Change-Id: I63563bbeb6f60f89d2c99660400dca7fab78a294 Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
2022-05-13 13:12:05 +00:00
// Copyright (C) 2021 The Qt Company Ltd.
// SPDX-License-Identifier: LicenseRef-Qt-Commercial OR BSD-3-Clause
Add an interactive PathItem example Change-Id: I1ddfba07e80cd0315a2ef85c85a568636f8e808a Reviewed-by: Andy Nichols <andy.nichols@qt.io>
2017-03-17 13:22:24 +00:00
Shapes example: use qqc2 components Changing the example to use qt quick controls where it makes sense Task-number: QTBUG-95739 Pick-to: 6.2 Change-Id: Id0df227657693234de4481c2316dc6c3e0545043 Reviewed-by: Mitch Curtis <mitch.curtis@qt.io>
2021-08-24 11:17:54 +00:00
import QtQuick
import QtQuick.Controls
Shapes interactive example: use Controls canonically; architecture As long as we had the funcs array, it would have been nice to be able to directly get an index from whatever "tool" is selected. For example, TabBar has currentIndex; but TabBar is otherwise not a great fit here. But the funcs array wasn't so elegant anyway. So that prompts switching to the known OO design pattern in which drawing tools are objects containing functions that "do" the drawing, so that there's no conditional dispatch: just ask the tool to handle each mouse state change. I.e. here the DragHandler on the canvas uses the tool's shapeType Component to create the shape, but the DragHandler doesn't have to care which shape it is. Handles for moving the shapes' control points are also shape-agnostic: - a handle is a sort of template taking the path x and y properties to read and write - the handle initializes its position from those properties - the DragHandler inside gets to do what it does best: just drag the handle, nothing else (instead of needing to script the movement of both the handle and the control point, we don't script either one) - declarative bindings on the handle's position update the path properties whenever the handle moves And some styling: - Switch looks better than Button for toggling - use palette colors so that it looks good in dark mode too - fix handle colors getting stuck on yellow - borders on handles (yellow on white makes it hard to see the edge otherwise) - reorder curve types by mathematical order (line, quadratic, cubic) Pick-to: 6.2 Change-Id: Iefd980f428601840deb55370aad9256748855f07 Reviewed-by: Mitch Curtis <mitch.curtis@qt.io>
2021-09-01 14:04:20 +00:00
import QtQuick.Layouts
Shapes example: use qqc2 components Changing the example to use qt quick controls where it makes sense Task-number: QTBUG-95739 Pick-to: 6.2 Change-Id: Id0df227657693234de4481c2316dc6c3e0545043 Reviewed-by: Mitch Curtis <mitch.curtis@qt.io>
2021-08-24 11:17:54 +00:00
import QtQuick.Shapes
Add an interactive PathItem example Change-Id: I1ddfba07e80cd0315a2ef85c85a568636f8e808a Reviewed-by: Andy Nichols <andy.nichols@qt.io>
2017-03-17 13:22:24 +00:00
Shapes example: adhere to guidelines - Fix all qmllint warnings. (except for main.qml, interactive.qml, and sampling.qml) - Translate user facing strings when it makes sense to do so. - Mark readonly properties as 'readonly'. - Avoid binding on multiple properties on a single line. (except for tiger.qml). Pick-to: 6.5 Change-Id: Idbf8a472ca5ba5385d1368aadd608e95231a07f0 Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
2023-03-03 17:07:39 +00:00
pragma ComponentBehavior: Bound
Add an interactive PathItem example Change-Id: I1ddfba07e80cd0315a2ef85c85a568636f8e808a Reviewed-by: Andy Nichols <andy.nichols@qt.io>
2017-03-17 13:22:24 +00:00
Rectangle {
id: root
width: 1024
height: 768
Shapes interactive example: use Controls canonically; architecture As long as we had the funcs array, it would have been nice to be able to directly get an index from whatever "tool" is selected. For example, TabBar has currentIndex; but TabBar is otherwise not a great fit here. But the funcs array wasn't so elegant anyway. So that prompts switching to the known OO design pattern in which drawing tools are objects containing functions that "do" the drawing, so that there's no conditional dispatch: just ask the tool to handle each mouse state change. I.e. here the DragHandler on the canvas uses the tool's shapeType Component to create the shape, but the DragHandler doesn't have to care which shape it is. Handles for moving the shapes' control points are also shape-agnostic: - a handle is a sort of template taking the path x and y properties to read and write - the handle initializes its position from those properties - the DragHandler inside gets to do what it does best: just drag the handle, nothing else (instead of needing to script the movement of both the handle and the control point, we don't script either one) - declarative bindings on the handle's position update the path properties whenever the handle moves And some styling: - Switch looks better than Button for toggling - use palette colors so that it looks good in dark mode too - fix handle colors getting stuck on yellow - borders on handles (yellow on white makes it hard to see the edge otherwise) - reorder curve types by mathematical order (line, quadratic, cubic) Pick-to: 6.2 Change-Id: Iefd980f428601840deb55370aad9256748855f07 Reviewed-by: Mitch Curtis <mitch.curtis@qt.io>
2021-09-01 14:04:20 +00:00
color: palette.window
Add an interactive PathItem example Change-Id: I1ddfba07e80cd0315a2ef85c85a568636f8e808a Reviewed-by: Andy Nichols <andy.nichols@qt.io>
2017-03-17 13:22:24 +00:00
Shapes interactive example: use Controls canonically; architecture As long as we had the funcs array, it would have been nice to be able to directly get an index from whatever "tool" is selected. For example, TabBar has currentIndex; but TabBar is otherwise not a great fit here. But the funcs array wasn't so elegant anyway. So that prompts switching to the known OO design pattern in which drawing tools are objects containing functions that "do" the drawing, so that there's no conditional dispatch: just ask the tool to handle each mouse state change. I.e. here the DragHandler on the canvas uses the tool's shapeType Component to create the shape, but the DragHandler doesn't have to care which shape it is. Handles for moving the shapes' control points are also shape-agnostic: - a handle is a sort of template taking the path x and y properties to read and write - the handle initializes its position from those properties - the DragHandler inside gets to do what it does best: just drag the handle, nothing else (instead of needing to script the movement of both the handle and the control point, we don't script either one) - declarative bindings on the handle's position update the path properties whenever the handle moves And some styling: - Switch looks better than Button for toggling - use palette colors so that it looks good in dark mode too - fix handle colors getting stuck on yellow - borders on handles (yellow on white makes it hard to see the edge otherwise) - reorder curve types by mathematical order (line, quadratic, cubic) Pick-to: 6.2 Change-Id: Iefd980f428601840deb55370aad9256748855f07 Reviewed-by: Mitch Curtis <mitch.curtis@qt.io>
2021-09-01 14:04:20 +00:00
RowLayout {
id: topRow
Add an interactive PathItem example Change-Id: I1ddfba07e80cd0315a2ef85c85a568636f8e808a Reviewed-by: Andy Nichols <andy.nichols@qt.io>
2017-03-17 13:22:24 +00:00
x: 20
y: 10
spacing: 20
Shapes example: use qqc2 components Changing the example to use qt quick controls where it makes sense Task-number: QTBUG-95739 Pick-to: 6.2 Change-Id: Id0df227657693234de4481c2316dc6c3e0545043 Reviewed-by: Mitch Curtis <mitch.curtis@qt.io>
2021-08-24 11:17:54 +00:00
Shapes interactive example: use Controls canonically; architecture As long as we had the funcs array, it would have been nice to be able to directly get an index from whatever "tool" is selected. For example, TabBar has currentIndex; but TabBar is otherwise not a great fit here. But the funcs array wasn't so elegant anyway. So that prompts switching to the known OO design pattern in which drawing tools are objects containing functions that "do" the drawing, so that there's no conditional dispatch: just ask the tool to handle each mouse state change. I.e. here the DragHandler on the canvas uses the tool's shapeType Component to create the shape, but the DragHandler doesn't have to care which shape it is. Handles for moving the shapes' control points are also shape-agnostic: - a handle is a sort of template taking the path x and y properties to read and write - the handle initializes its position from those properties - the DragHandler inside gets to do what it does best: just drag the handle, nothing else (instead of needing to script the movement of both the handle and the control point, we don't script either one) - declarative bindings on the handle's position update the path properties whenever the handle moves And some styling: - Switch looks better than Button for toggling - use palette colors so that it looks good in dark mode too - fix handle colors getting stuck on yellow - borders on handles (yellow on white makes it hard to see the edge otherwise) - reorder curve types by mathematical order (line, quadratic, cubic) Pick-to: 6.2 Change-Id: Iefd980f428601840deb55370aad9256748855f07 Reviewed-by: Mitch Curtis <mitch.curtis@qt.io>
2021-09-01 14:04:20 +00:00
ButtonGroup {
id: toolButtons
buttons: drawingTools.children
Add an interactive PathItem example Change-Id: I1ddfba07e80cd0315a2ef85c85a568636f8e808a Reviewed-by: Andy Nichols <andy.nichols@qt.io>
2017-03-17 13:22:24 +00:00
}
Shapes example: use qqc2 components Changing the example to use qt quick controls where it makes sense Task-number: QTBUG-95739 Pick-to: 6.2 Change-Id: Id0df227657693234de4481c2316dc6c3e0545043 Reviewed-by: Mitch Curtis <mitch.curtis@qt.io>
2021-08-24 11:17:54 +00:00
Shapes interactive example: use Controls canonically; architecture As long as we had the funcs array, it would have been nice to be able to directly get an index from whatever "tool" is selected. For example, TabBar has currentIndex; but TabBar is otherwise not a great fit here. But the funcs array wasn't so elegant anyway. So that prompts switching to the known OO design pattern in which drawing tools are objects containing functions that "do" the drawing, so that there's no conditional dispatch: just ask the tool to handle each mouse state change. I.e. here the DragHandler on the canvas uses the tool's shapeType Component to create the shape, but the DragHandler doesn't have to care which shape it is. Handles for moving the shapes' control points are also shape-agnostic: - a handle is a sort of template taking the path x and y properties to read and write - the handle initializes its position from those properties - the DragHandler inside gets to do what it does best: just drag the handle, nothing else (instead of needing to script the movement of both the handle and the control point, we don't script either one) - declarative bindings on the handle's position update the path properties whenever the handle moves And some styling: - Switch looks better than Button for toggling - use palette colors so that it looks good in dark mode too - fix handle colors getting stuck on yellow - borders on handles (yellow on white makes it hard to see the edge otherwise) - reorder curve types by mathematical order (line, quadratic, cubic) Pick-to: 6.2 Change-Id: Iefd980f428601840deb55370aad9256748855f07 Reviewed-by: Mitch Curtis <mitch.curtis@qt.io>
2021-09-01 14:04:20 +00:00
RowLayout {
id: drawingTools
ToolButton {
text: qsTr("Line")
checkable: true
checked: true
property Component shapeType: Component {
ShapePath {
id: lineShapePath
strokeColor: root.palette.windowText
strokeWidth: widthSlider.value
fillColor: "transparent"
PathLine {
id: pathSegment
x: lineShapePath.startX + 1
y: lineShapePath.startY + 1
}
function finishCreation() {
createStartEndHandles(this, pathSegment);
}
}
}
Add an interactive PathItem example Change-Id: I1ddfba07e80cd0315a2ef85c85a568636f8e808a Reviewed-by: Andy Nichols <andy.nichols@qt.io>
2017-03-17 13:22:24 +00:00
}
Shapes interactive example: use Controls canonically; architecture As long as we had the funcs array, it would have been nice to be able to directly get an index from whatever "tool" is selected. For example, TabBar has currentIndex; but TabBar is otherwise not a great fit here. But the funcs array wasn't so elegant anyway. So that prompts switching to the known OO design pattern in which drawing tools are objects containing functions that "do" the drawing, so that there's no conditional dispatch: just ask the tool to handle each mouse state change. I.e. here the DragHandler on the canvas uses the tool's shapeType Component to create the shape, but the DragHandler doesn't have to care which shape it is. Handles for moving the shapes' control points are also shape-agnostic: - a handle is a sort of template taking the path x and y properties to read and write - the handle initializes its position from those properties - the DragHandler inside gets to do what it does best: just drag the handle, nothing else (instead of needing to script the movement of both the handle and the control point, we don't script either one) - declarative bindings on the handle's position update the path properties whenever the handle moves And some styling: - Switch looks better than Button for toggling - use palette colors so that it looks good in dark mode too - fix handle colors getting stuck on yellow - borders on handles (yellow on white makes it hard to see the edge otherwise) - reorder curve types by mathematical order (line, quadratic, cubic) Pick-to: 6.2 Change-Id: Iefd980f428601840deb55370aad9256748855f07 Reviewed-by: Mitch Curtis <mitch.curtis@qt.io>
2021-09-01 14:04:20 +00:00
ToolButton {
text: qsTr("Quadratic")
checkable: true
property Component shapeType: Component {
ShapePath {
id: quadShapePath
strokeColor: root.palette.windowText
strokeWidth: widthSlider.value
fillColor: fillSwitch.checked ? "green" : "transparent"
PathQuad {
id: pathSegment
Shapes example: adhere to guidelines - Fix all qmllint warnings. (except for main.qml, interactive.qml, and sampling.qml) - Translate user facing strings when it makes sense to do so. - Mark readonly properties as 'readonly'. - Avoid binding on multiple properties on a single line. (except for tiger.qml). Pick-to: 6.5 Change-Id: Idbf8a472ca5ba5385d1368aadd608e95231a07f0 Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
2023-03-03 17:07:39 +00:00
x: quadShapePath.startX + 1
Shapes interactive example: use Controls canonically; architecture As long as we had the funcs array, it would have been nice to be able to directly get an index from whatever "tool" is selected. For example, TabBar has currentIndex; but TabBar is otherwise not a great fit here. But the funcs array wasn't so elegant anyway. So that prompts switching to the known OO design pattern in which drawing tools are objects containing functions that "do" the drawing, so that there's no conditional dispatch: just ask the tool to handle each mouse state change. I.e. here the DragHandler on the canvas uses the tool's shapeType Component to create the shape, but the DragHandler doesn't have to care which shape it is. Handles for moving the shapes' control points are also shape-agnostic: - a handle is a sort of template taking the path x and y properties to read and write - the handle initializes its position from those properties - the DragHandler inside gets to do what it does best: just drag the handle, nothing else (instead of needing to script the movement of both the handle and the control point, we don't script either one) - declarative bindings on the handle's position update the path properties whenever the handle moves And some styling: - Switch looks better than Button for toggling - use palette colors so that it looks good in dark mode too - fix handle colors getting stuck on yellow - borders on handles (yellow on white makes it hard to see the edge otherwise) - reorder curve types by mathematical order (line, quadratic, cubic) Pick-to: 6.2 Change-Id: Iefd980f428601840deb55370aad9256748855f07 Reviewed-by: Mitch Curtis <mitch.curtis@qt.io>
2021-09-01 14:04:20 +00:00
y: quadShapePath.startY + 1
controlX: quadShapePath.startX + 50
controlY: quadShapePath.startY + 50
}
function finishCreation() {
createStartEndHandles(this, pathSegment);
pointDragHandle.createObject(canvas, {
idleColor: "blue",
target: pathSegment, xprop: "controlX", yprop: "controlY"
});
}
}
}
Shapes example: use qqc2 components Changing the example to use qt quick controls where it makes sense Task-number: QTBUG-95739 Pick-to: 6.2 Change-Id: Id0df227657693234de4481c2316dc6c3e0545043 Reviewed-by: Mitch Curtis <mitch.curtis@qt.io>
2021-08-24 11:17:54 +00:00
}
Shapes interactive example: use Controls canonically; architecture As long as we had the funcs array, it would have been nice to be able to directly get an index from whatever "tool" is selected. For example, TabBar has currentIndex; but TabBar is otherwise not a great fit here. But the funcs array wasn't so elegant anyway. So that prompts switching to the known OO design pattern in which drawing tools are objects containing functions that "do" the drawing, so that there's no conditional dispatch: just ask the tool to handle each mouse state change. I.e. here the DragHandler on the canvas uses the tool's shapeType Component to create the shape, but the DragHandler doesn't have to care which shape it is. Handles for moving the shapes' control points are also shape-agnostic: - a handle is a sort of template taking the path x and y properties to read and write - the handle initializes its position from those properties - the DragHandler inside gets to do what it does best: just drag the handle, nothing else (instead of needing to script the movement of both the handle and the control point, we don't script either one) - declarative bindings on the handle's position update the path properties whenever the handle moves And some styling: - Switch looks better than Button for toggling - use palette colors so that it looks good in dark mode too - fix handle colors getting stuck on yellow - borders on handles (yellow on white makes it hard to see the edge otherwise) - reorder curve types by mathematical order (line, quadratic, cubic) Pick-to: 6.2 Change-Id: Iefd980f428601840deb55370aad9256748855f07 Reviewed-by: Mitch Curtis <mitch.curtis@qt.io>
2021-09-01 14:04:20 +00:00
ToolButton {
text: qsTr("Cubic")
checkable: true
property Component shapeType: Component {
ShapePath {
id: cubicShapePath
strokeColor: root.palette.windowText
strokeWidth: widthSlider.value
fillColor: fillSwitch.checked ? "green" : "transparent"
PathCubic {
id: pathSegment
x: cubicShapePath.startX + 1
y: cubicShapePath.startY + 1
control1X: cubicShapePath.startX + 50;
control1Y: cubicShapePath.startY + 50;
control2X: cubicShapePath.startX + 150;
control2Y: cubicShapePath.startY + 50;
}
function finishCreation() {
createStartEndHandles(this, pathSegment);
pointDragHandle.createObject(canvas, {
idleColor: "blue",
target: pathSegment, xprop: "control1X", yprop: "control1Y"
});
pointDragHandle.createObject(canvas, {
idleColor: "lightBlue",
target: pathSegment, xprop: "control2X", yprop: "control2Y"
});
}
}
}
Shapes example: use qqc2 components Changing the example to use qt quick controls where it makes sense Task-number: QTBUG-95739 Pick-to: 6.2 Change-Id: Id0df227657693234de4481c2316dc6c3e0545043 Reviewed-by: Mitch Curtis <mitch.curtis@qt.io>
2021-08-24 11:17:54 +00:00
}
Add an interactive PathItem example Change-Id: I1ddfba07e80cd0315a2ef85c85a568636f8e808a Reviewed-by: Andy Nichols <andy.nichols@qt.io>
2017-03-17 13:22:24 +00:00
}
Shapes interactive example: use Controls canonically; architecture As long as we had the funcs array, it would have been nice to be able to directly get an index from whatever "tool" is selected. For example, TabBar has currentIndex; but TabBar is otherwise not a great fit here. But the funcs array wasn't so elegant anyway. So that prompts switching to the known OO design pattern in which drawing tools are objects containing functions that "do" the drawing, so that there's no conditional dispatch: just ask the tool to handle each mouse state change. I.e. here the DragHandler on the canvas uses the tool's shapeType Component to create the shape, but the DragHandler doesn't have to care which shape it is. Handles for moving the shapes' control points are also shape-agnostic: - a handle is a sort of template taking the path x and y properties to read and write - the handle initializes its position from those properties - the DragHandler inside gets to do what it does best: just drag the handle, nothing else (instead of needing to script the movement of both the handle and the control point, we don't script either one) - declarative bindings on the handle's position update the path properties whenever the handle moves And some styling: - Switch looks better than Button for toggling - use palette colors so that it looks good in dark mode too - fix handle colors getting stuck on yellow - borders on handles (yellow on white makes it hard to see the edge otherwise) - reorder curve types by mathematical order (line, quadratic, cubic) Pick-to: 6.2 Change-Id: Iefd980f428601840deb55370aad9256748855f07 Reviewed-by: Mitch Curtis <mitch.curtis@qt.io>
2021-09-01 14:04:20 +00:00
Label {
text: qsTr("Width")
}
Slider {
id: widthSlider
from: 1
to: 60
value: 4
}
Shapes example: use qqc2 components Changing the example to use qt quick controls where it makes sense Task-number: QTBUG-95739 Pick-to: 6.2 Change-Id: Id0df227657693234de4481c2316dc6c3e0545043 Reviewed-by: Mitch Curtis <mitch.curtis@qt.io>
2021-08-24 11:17:54 +00:00
Shapes interactive example: use Controls canonically; architecture As long as we had the funcs array, it would have been nice to be able to directly get an index from whatever "tool" is selected. For example, TabBar has currentIndex; but TabBar is otherwise not a great fit here. But the funcs array wasn't so elegant anyway. So that prompts switching to the known OO design pattern in which drawing tools are objects containing functions that "do" the drawing, so that there's no conditional dispatch: just ask the tool to handle each mouse state change. I.e. here the DragHandler on the canvas uses the tool's shapeType Component to create the shape, but the DragHandler doesn't have to care which shape it is. Handles for moving the shapes' control points are also shape-agnostic: - a handle is a sort of template taking the path x and y properties to read and write - the handle initializes its position from those properties - the DragHandler inside gets to do what it does best: just drag the handle, nothing else (instead of needing to script the movement of both the handle and the control point, we don't script either one) - declarative bindings on the handle's position update the path properties whenever the handle moves And some styling: - Switch looks better than Button for toggling - use palette colors so that it looks good in dark mode too - fix handle colors getting stuck on yellow - borders on handles (yellow on white makes it hard to see the edge otherwise) - reorder curve types by mathematical order (line, quadratic, cubic) Pick-to: 6.2 Change-Id: Iefd980f428601840deb55370aad9256748855f07 Reviewed-by: Mitch Curtis <mitch.curtis@qt.io>
2021-09-01 14:04:20 +00:00
Switch {
id: showHandlesSwitch
text: qsTr("Handles")
Add an interactive PathItem example Change-Id: I1ddfba07e80cd0315a2ef85c85a568636f8e808a Reviewed-by: Andy Nichols <andy.nichols@qt.io>
2017-03-17 13:22:24 +00:00
}
Shapes interactive example: use Controls canonically; architecture As long as we had the funcs array, it would have been nice to be able to directly get an index from whatever "tool" is selected. For example, TabBar has currentIndex; but TabBar is otherwise not a great fit here. But the funcs array wasn't so elegant anyway. So that prompts switching to the known OO design pattern in which drawing tools are objects containing functions that "do" the drawing, so that there's no conditional dispatch: just ask the tool to handle each mouse state change. I.e. here the DragHandler on the canvas uses the tool's shapeType Component to create the shape, but the DragHandler doesn't have to care which shape it is. Handles for moving the shapes' control points are also shape-agnostic: - a handle is a sort of template taking the path x and y properties to read and write - the handle initializes its position from those properties - the DragHandler inside gets to do what it does best: just drag the handle, nothing else (instead of needing to script the movement of both the handle and the control point, we don't script either one) - declarative bindings on the handle's position update the path properties whenever the handle moves And some styling: - Switch looks better than Button for toggling - use palette colors so that it looks good in dark mode too - fix handle colors getting stuck on yellow - borders on handles (yellow on white makes it hard to see the edge otherwise) - reorder curve types by mathematical order (line, quadratic, cubic) Pick-to: 6.2 Change-Id: Iefd980f428601840deb55370aad9256748855f07 Reviewed-by: Mitch Curtis <mitch.curtis@qt.io>
2021-09-01 14:04:20 +00:00
Switch {
id: fillSwitch
Shapes example: use qqc2 components Changing the example to use qt quick controls where it makes sense Task-number: QTBUG-95739 Pick-to: 6.2 Change-Id: Id0df227657693234de4481c2316dc6c3e0545043 Reviewed-by: Mitch Curtis <mitch.curtis@qt.io>
2021-08-24 11:17:54 +00:00
text: qsTr("Fill")
Add an interactive PathItem example Change-Id: I1ddfba07e80cd0315a2ef85c85a568636f8e808a Reviewed-by: Andy Nichols <andy.nichols@qt.io>
2017-03-17 13:22:24 +00:00
}
}
Shapes interactive example: use Controls canonically; architecture As long as we had the funcs array, it would have been nice to be able to directly get an index from whatever "tool" is selected. For example, TabBar has currentIndex; but TabBar is otherwise not a great fit here. But the funcs array wasn't so elegant anyway. So that prompts switching to the known OO design pattern in which drawing tools are objects containing functions that "do" the drawing, so that there's no conditional dispatch: just ask the tool to handle each mouse state change. I.e. here the DragHandler on the canvas uses the tool's shapeType Component to create the shape, but the DragHandler doesn't have to care which shape it is. Handles for moving the shapes' control points are also shape-agnostic: - a handle is a sort of template taking the path x and y properties to read and write - the handle initializes its position from those properties - the DragHandler inside gets to do what it does best: just drag the handle, nothing else (instead of needing to script the movement of both the handle and the control point, we don't script either one) - declarative bindings on the handle's position update the path properties whenever the handle moves And some styling: - Switch looks better than Button for toggling - use palette colors so that it looks good in dark mode too - fix handle colors getting stuck on yellow - borders on handles (yellow on white makes it hard to see the edge otherwise) - reorder curve types by mathematical order (line, quadratic, cubic) Pick-to: 6.2 Change-Id: Iefd980f428601840deb55370aad9256748855f07 Reviewed-by: Mitch Curtis <mitch.curtis@qt.io>
2021-09-01 14:04:20 +00:00
Component {
id: pointDragHandle
Add an interactive PathItem example Change-Id: I1ddfba07e80cd0315a2ef85c85a568636f8e808a Reviewed-by: Andy Nichols <andy.nichols@qt.io>
2017-03-17 13:22:24 +00:00
Shapes interactive example: use Controls canonically; architecture As long as we had the funcs array, it would have been nice to be able to directly get an index from whatever "tool" is selected. For example, TabBar has currentIndex; but TabBar is otherwise not a great fit here. But the funcs array wasn't so elegant anyway. So that prompts switching to the known OO design pattern in which drawing tools are objects containing functions that "do" the drawing, so that there's no conditional dispatch: just ask the tool to handle each mouse state change. I.e. here the DragHandler on the canvas uses the tool's shapeType Component to create the shape, but the DragHandler doesn't have to care which shape it is. Handles for moving the shapes' control points are also shape-agnostic: - a handle is a sort of template taking the path x and y properties to read and write - the handle initializes its position from those properties - the DragHandler inside gets to do what it does best: just drag the handle, nothing else (instead of needing to script the movement of both the handle and the control point, we don't script either one) - declarative bindings on the handle's position update the path properties whenever the handle moves And some styling: - Switch looks better than Button for toggling - use palette colors so that it looks good in dark mode too - fix handle colors getting stuck on yellow - borders on handles (yellow on white makes it hard to see the edge otherwise) - reorder curve types by mathematical order (line, quadratic, cubic) Pick-to: 6.2 Change-Id: Iefd980f428601840deb55370aad9256748855f07 Reviewed-by: Mitch Curtis <mitch.curtis@qt.io>
2021-09-01 14:04:20 +00:00
Rectangle {
id: rect
property variant target
property string xprop
property string yprop
property color idleColor: "red"
Add an interactive PathItem example Change-Id: I1ddfba07e80cd0315a2ef85c85a568636f8e808a Reviewed-by: Andy Nichols <andy.nichols@qt.io>
2017-03-17 13:22:24 +00:00
Shapes interactive example: use Controls canonically; architecture As long as we had the funcs array, it would have been nice to be able to directly get an index from whatever "tool" is selected. For example, TabBar has currentIndex; but TabBar is otherwise not a great fit here. But the funcs array wasn't so elegant anyway. So that prompts switching to the known OO design pattern in which drawing tools are objects containing functions that "do" the drawing, so that there's no conditional dispatch: just ask the tool to handle each mouse state change. I.e. here the DragHandler on the canvas uses the tool's shapeType Component to create the shape, but the DragHandler doesn't have to care which shape it is. Handles for moving the shapes' control points are also shape-agnostic: - a handle is a sort of template taking the path x and y properties to read and write - the handle initializes its position from those properties - the DragHandler inside gets to do what it does best: just drag the handle, nothing else (instead of needing to script the movement of both the handle and the control point, we don't script either one) - declarative bindings on the handle's position update the path properties whenever the handle moves And some styling: - Switch looks better than Button for toggling - use palette colors so that it looks good in dark mode too - fix handle colors getting stuck on yellow - borders on handles (yellow on white makes it hard to see the edge otherwise) - reorder curve types by mathematical order (line, quadratic, cubic) Pick-to: 6.2 Change-Id: Iefd980f428601840deb55370aad9256748855f07 Reviewed-by: Mitch Curtis <mitch.curtis@qt.io>
2021-09-01 14:04:20 +00:00
width: 20
height: width
visible: showHandlesSwitch.checked
color: hh.hovered ? "yellow" : idleColor
border.color: "grey"
Add an interactive PathItem example Change-Id: I1ddfba07e80cd0315a2ef85c85a568636f8e808a Reviewed-by: Andy Nichols <andy.nichols@qt.io>
2017-03-17 13:22:24 +00:00
Shapes interactive example: use Controls canonically; architecture As long as we had the funcs array, it would have been nice to be able to directly get an index from whatever "tool" is selected. For example, TabBar has currentIndex; but TabBar is otherwise not a great fit here. But the funcs array wasn't so elegant anyway. So that prompts switching to the known OO design pattern in which drawing tools are objects containing functions that "do" the drawing, so that there's no conditional dispatch: just ask the tool to handle each mouse state change. I.e. here the DragHandler on the canvas uses the tool's shapeType Component to create the shape, but the DragHandler doesn't have to care which shape it is. Handles for moving the shapes' control points are also shape-agnostic: - a handle is a sort of template taking the path x and y properties to read and write - the handle initializes its position from those properties - the DragHandler inside gets to do what it does best: just drag the handle, nothing else (instead of needing to script the movement of both the handle and the control point, we don't script either one) - declarative bindings on the handle's position update the path properties whenever the handle moves And some styling: - Switch looks better than Button for toggling - use palette colors so that it looks good in dark mode too - fix handle colors getting stuck on yellow - borders on handles (yellow on white makes it hard to see the edge otherwise) - reorder curve types by mathematical order (line, quadratic, cubic) Pick-to: 6.2 Change-Id: Iefd980f428601840deb55370aad9256748855f07 Reviewed-by: Mitch Curtis <mitch.curtis@qt.io>
2021-09-01 14:04:20 +00:00
property real halfWidth: width / 2
property bool complete: false
Shapes example: adhere to guidelines - Fix all qmllint warnings. (except for main.qml, interactive.qml, and sampling.qml) - Translate user facing strings when it makes sense to do so. - Mark readonly properties as 'readonly'. - Avoid binding on multiple properties on a single line. (except for tiger.qml). Pick-to: 6.5 Change-Id: Idbf8a472ca5ba5385d1368aadd608e95231a07f0 Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
2023-03-03 17:07:39 +00:00
Binding {
target: rect.target
property: rect.xprop
value: rect.x + rect.halfWidth
when: rect.complete
}
Binding {
target: rect.target
property: rect.yprop
value: rect.y + rect.halfWidth
when: rect.complete
}
Examples: Avoid Qt.createQmlObject() We don't want to encourage Qt.createQmlObject(). It's the equivalent of eval() in JavaScript. This has the added benefit that the shapes actually react to changes in the parameters now. Before, once a shape was drawn, it didn't get updated when you manipulated the line width or fill controls. Change-Id: I8d5b7598799b52043f86fd1f617e31de09331891 Reviewed-by: Simon Hausmann <simon.hausmann@qt.io> Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
2019-09-27 15:01:27 +00:00
Shapes interactive example: use Controls canonically; architecture As long as we had the funcs array, it would have been nice to be able to directly get an index from whatever "tool" is selected. For example, TabBar has currentIndex; but TabBar is otherwise not a great fit here. But the funcs array wasn't so elegant anyway. So that prompts switching to the known OO design pattern in which drawing tools are objects containing functions that "do" the drawing, so that there's no conditional dispatch: just ask the tool to handle each mouse state change. I.e. here the DragHandler on the canvas uses the tool's shapeType Component to create the shape, but the DragHandler doesn't have to care which shape it is. Handles for moving the shapes' control points are also shape-agnostic: - a handle is a sort of template taking the path x and y properties to read and write - the handle initializes its position from those properties - the DragHandler inside gets to do what it does best: just drag the handle, nothing else (instead of needing to script the movement of both the handle and the control point, we don't script either one) - declarative bindings on the handle's position update the path properties whenever the handle moves And some styling: - Switch looks better than Button for toggling - use palette colors so that it looks good in dark mode too - fix handle colors getting stuck on yellow - borders on handles (yellow on white makes it hard to see the edge otherwise) - reorder curve types by mathematical order (line, quadratic, cubic) Pick-to: 6.2 Change-Id: Iefd980f428601840deb55370aad9256748855f07 Reviewed-by: Mitch Curtis <mitch.curtis@qt.io>
2021-09-01 14:04:20 +00:00
DragHandler { }
Examples: Avoid Qt.createQmlObject() We don't want to encourage Qt.createQmlObject(). It's the equivalent of eval() in JavaScript. This has the added benefit that the shapes actually react to changes in the parameters now. Before, once a shape was drawn, it didn't get updated when you manipulated the line width or fill controls. Change-Id: I8d5b7598799b52043f86fd1f617e31de09331891 Reviewed-by: Simon Hausmann <simon.hausmann@qt.io> Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
2019-09-27 15:01:27 +00:00
Shapes example: adhere to guidelines - Fix all qmllint warnings. (except for main.qml, interactive.qml, and sampling.qml) - Translate user facing strings when it makes sense to do so. - Mark readonly properties as 'readonly'. - Avoid binding on multiple properties on a single line. (except for tiger.qml). Pick-to: 6.5 Change-Id: Idbf8a472ca5ba5385d1368aadd608e95231a07f0 Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
2023-03-03 17:07:39 +00:00
HoverHandler {
id: hh
}
Add an interactive PathItem example Change-Id: I1ddfba07e80cd0315a2ef85c85a568636f8e808a Reviewed-by: Andy Nichols <andy.nichols@qt.io>
2017-03-17 13:22:24 +00:00
Shapes interactive example: use Controls canonically; architecture As long as we had the funcs array, it would have been nice to be able to directly get an index from whatever "tool" is selected. For example, TabBar has currentIndex; but TabBar is otherwise not a great fit here. But the funcs array wasn't so elegant anyway. So that prompts switching to the known OO design pattern in which drawing tools are objects containing functions that "do" the drawing, so that there's no conditional dispatch: just ask the tool to handle each mouse state change. I.e. here the DragHandler on the canvas uses the tool's shapeType Component to create the shape, but the DragHandler doesn't have to care which shape it is. Handles for moving the shapes' control points are also shape-agnostic: - a handle is a sort of template taking the path x and y properties to read and write - the handle initializes its position from those properties - the DragHandler inside gets to do what it does best: just drag the handle, nothing else (instead of needing to script the movement of both the handle and the control point, we don't script either one) - declarative bindings on the handle's position update the path properties whenever the handle moves And some styling: - Switch looks better than Button for toggling - use palette colors so that it looks good in dark mode too - fix handle colors getting stuck on yellow - borders on handles (yellow on white makes it hard to see the edge otherwise) - reorder curve types by mathematical order (line, quadratic, cubic) Pick-to: 6.2 Change-Id: Iefd980f428601840deb55370aad9256748855f07 Reviewed-by: Mitch Curtis <mitch.curtis@qt.io>
2021-09-01 14:04:20 +00:00
Component.onCompleted: {
x = target[xprop] - halfWidth;
y = target[yprop] - halfWidth;
complete = true;
Examples: Avoid Qt.createQmlObject() We don't want to encourage Qt.createQmlObject(). It's the equivalent of eval() in JavaScript. This has the added benefit that the shapes actually react to changes in the parameters now. Before, once a shape was drawn, it didn't get updated when you manipulated the line width or fill controls. Change-Id: I8d5b7598799b52043f86fd1f617e31de09331891 Reviewed-by: Simon Hausmann <simon.hausmann@qt.io> Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
2019-09-27 15:01:27 +00:00
}
}
Shapes interactive example: use Controls canonically; architecture As long as we had the funcs array, it would have been nice to be able to directly get an index from whatever "tool" is selected. For example, TabBar has currentIndex; but TabBar is otherwise not a great fit here. But the funcs array wasn't so elegant anyway. So that prompts switching to the known OO design pattern in which drawing tools are objects containing functions that "do" the drawing, so that there's no conditional dispatch: just ask the tool to handle each mouse state change. I.e. here the DragHandler on the canvas uses the tool's shapeType Component to create the shape, but the DragHandler doesn't have to care which shape it is. Handles for moving the shapes' control points are also shape-agnostic: - a handle is a sort of template taking the path x and y properties to read and write - the handle initializes its position from those properties - the DragHandler inside gets to do what it does best: just drag the handle, nothing else (instead of needing to script the movement of both the handle and the control point, we don't script either one) - declarative bindings on the handle's position update the path properties whenever the handle moves And some styling: - Switch looks better than Button for toggling - use palette colors so that it looks good in dark mode too - fix handle colors getting stuck on yellow - borders on handles (yellow on white makes it hard to see the edge otherwise) - reorder curve types by mathematical order (line, quadratic, cubic) Pick-to: 6.2 Change-Id: Iefd980f428601840deb55370aad9256748855f07 Reviewed-by: Mitch Curtis <mitch.curtis@qt.io>
2021-09-01 14:04:20 +00:00
}
Examples: Avoid Qt.createQmlObject() We don't want to encourage Qt.createQmlObject(). It's the equivalent of eval() in JavaScript. This has the added benefit that the shapes actually react to changes in the parameters now. Before, once a shape was drawn, it didn't get updated when you manipulated the line width or fill controls. Change-Id: I8d5b7598799b52043f86fd1f617e31de09331891 Reviewed-by: Simon Hausmann <simon.hausmann@qt.io> Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
2019-09-27 15:01:27 +00:00
Shapes interactive example: use Controls canonically; architecture As long as we had the funcs array, it would have been nice to be able to directly get an index from whatever "tool" is selected. For example, TabBar has currentIndex; but TabBar is otherwise not a great fit here. But the funcs array wasn't so elegant anyway. So that prompts switching to the known OO design pattern in which drawing tools are objects containing functions that "do" the drawing, so that there's no conditional dispatch: just ask the tool to handle each mouse state change. I.e. here the DragHandler on the canvas uses the tool's shapeType Component to create the shape, but the DragHandler doesn't have to care which shape it is. Handles for moving the shapes' control points are also shape-agnostic: - a handle is a sort of template taking the path x and y properties to read and write - the handle initializes its position from those properties - the DragHandler inside gets to do what it does best: just drag the handle, nothing else (instead of needing to script the movement of both the handle and the control point, we don't script either one) - declarative bindings on the handle's position update the path properties whenever the handle moves And some styling: - Switch looks better than Button for toggling - use palette colors so that it looks good in dark mode too - fix handle colors getting stuck on yellow - borders on handles (yellow on white makes it hard to see the edge otherwise) - reorder curve types by mathematical order (line, quadratic, cubic) Pick-to: 6.2 Change-Id: Iefd980f428601840deb55370aad9256748855f07 Reviewed-by: Mitch Curtis <mitch.curtis@qt.io>
2021-09-01 14:04:20 +00:00
function createStartEndHandles(shapePath, pathSegment) {
pointDragHandle.createObject(canvas, {
idleColor: "red",
target: shapePath, xprop: "startX", yprop: "startY"
});
pointDragHandle.createObject(canvas, {
idleColor: "red",
target: pathSegment, xprop: "x", yprop: "y"
});
}
Examples: Avoid Qt.createQmlObject() We don't want to encourage Qt.createQmlObject(). It's the equivalent of eval() in JavaScript. This has the added benefit that the shapes actually react to changes in the parameters now. Before, once a shape was drawn, it didn't get updated when you manipulated the line width or fill controls. Change-Id: I8d5b7598799b52043f86fd1f617e31de09331891 Reviewed-by: Simon Hausmann <simon.hausmann@qt.io> Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
2019-09-27 15:01:27 +00:00
Shapes interactive example: use Controls canonically; architecture As long as we had the funcs array, it would have been nice to be able to directly get an index from whatever "tool" is selected. For example, TabBar has currentIndex; but TabBar is otherwise not a great fit here. But the funcs array wasn't so elegant anyway. So that prompts switching to the known OO design pattern in which drawing tools are objects containing functions that "do" the drawing, so that there's no conditional dispatch: just ask the tool to handle each mouse state change. I.e. here the DragHandler on the canvas uses the tool's shapeType Component to create the shape, but the DragHandler doesn't have to care which shape it is. Handles for moving the shapes' control points are also shape-agnostic: - a handle is a sort of template taking the path x and y properties to read and write - the handle initializes its position from those properties - the DragHandler inside gets to do what it does best: just drag the handle, nothing else (instead of needing to script the movement of both the handle and the control point, we don't script either one) - declarative bindings on the handle's position update the path properties whenever the handle moves And some styling: - Switch looks better than Button for toggling - use palette colors so that it looks good in dark mode too - fix handle colors getting stuck on yellow - borders on handles (yellow on white makes it hard to see the edge otherwise) - reorder curve types by mathematical order (line, quadratic, cubic) Pick-to: 6.2 Change-Id: Iefd980f428601840deb55370aad9256748855f07 Reviewed-by: Mitch Curtis <mitch.curtis@qt.io>
2021-09-01 14:04:20 +00:00
Rectangle {
id: canvas
color: palette.base
width: root.width - 40
height: root.height - y - 20
x: 20
anchors.top: topRow.bottom
anchors.topMargin: 20
DragHandler {
target: null
grabPermissions: DragHandler.TakeOverForbidden
property ShapePath activePath: null
onActiveChanged: {
const tool = toolButtons.checkedButton;
if (active) {
activePath = tool.shapeType.createObject(root, {
startX: centroid.position.x, startY: centroid.position.y
});
shape.data.push(activePath);
} else {
activePath.finishCreation();
activePath = null;
Examples: Avoid Qt.createQmlObject() We don't want to encourage Qt.createQmlObject(). It's the equivalent of eval() in JavaScript. This has the added benefit that the shapes actually react to changes in the parameters now. Before, once a shape was drawn, it didn't get updated when you manipulated the line width or fill controls. Change-Id: I8d5b7598799b52043f86fd1f617e31de09331891 Reviewed-by: Simon Hausmann <simon.hausmann@qt.io> Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
2019-09-27 15:01:27 +00:00
}
}
Shapes interactive example: use Controls canonically; architecture As long as we had the funcs array, it would have been nice to be able to directly get an index from whatever "tool" is selected. For example, TabBar has currentIndex; but TabBar is otherwise not a great fit here. But the funcs array wasn't so elegant anyway. So that prompts switching to the known OO design pattern in which drawing tools are objects containing functions that "do" the drawing, so that there's no conditional dispatch: just ask the tool to handle each mouse state change. I.e. here the DragHandler on the canvas uses the tool's shapeType Component to create the shape, but the DragHandler doesn't have to care which shape it is. Handles for moving the shapes' control points are also shape-agnostic: - a handle is a sort of template taking the path x and y properties to read and write - the handle initializes its position from those properties - the DragHandler inside gets to do what it does best: just drag the handle, nothing else (instead of needing to script the movement of both the handle and the control point, we don't script either one) - declarative bindings on the handle's position update the path properties whenever the handle moves And some styling: - Switch looks better than Button for toggling - use palette colors so that it looks good in dark mode too - fix handle colors getting stuck on yellow - borders on handles (yellow on white makes it hard to see the edge otherwise) - reorder curve types by mathematical order (line, quadratic, cubic) Pick-to: 6.2 Change-Id: Iefd980f428601840deb55370aad9256748855f07 Reviewed-by: Mitch Curtis <mitch.curtis@qt.io>
2021-09-01 14:04:20 +00:00
onCentroidChanged: if (activePath) {
var pathObj = activePath.pathElements[0];
pathObj.x = centroid.position.x;
pathObj.y = centroid.position.y;
Add an interactive PathItem example Change-Id: I1ddfba07e80cd0315a2ef85c85a568636f8e808a Reviewed-by: Andy Nichols <andy.nichols@qt.io>
2017-03-17 13:22:24 +00:00
}
}
Rename to Shape/ShapePath and remove public JS API Change-Id: I299354da0632fb0b8487cfb13748ed58b97d75fd Reviewed-by: Andy Nichols <andy.nichols@qt.io>
2017-05-31 10:42:09 +00:00
Shape {
id: shape
Add an interactive PathItem example Change-Id: I1ddfba07e80cd0315a2ef85c85a568636f8e808a Reviewed-by: Andy Nichols <andy.nichols@qt.io>
2017-03-17 13:22:24 +00:00
anchors.fill: parent
}
}
}