Qt Quick Best Practices: Difference between revisions
Jump to navigation
Jump to search
AutoSpider (talk | contribs) (Add "cleanup" tag) |
(Use LangSwitch) |
||
(6 intermediate revisions by 5 users not shown) | |||
Line 1: | Line 1: | ||
[[Category:Advice]] | |||
{{LangSwitch}} | |||
[[Category: | |||
This article lists out the best practices and also the DOs and DONTs recommended by developers while developing with Qt Quick. Please add your recommendations and help this page grow … | This article lists out the best practices and also the DOs and DONTs recommended by developers while developing with Qt Quick. Please add your recommendations and help this page grow … | ||
=== Formatting === | === Formatting === | ||
Line 16: | Line 10: | ||
*/ | */ | ||
Rectangle { | |||
id: example | |||
// size independently from screen height | |||
width: 100 | |||
height: 100 | |||
} | |||
</code> | </code> | ||
Line 64: | Line 58: | ||
* Expose the current state and the state change as properties rather than functions - cleaner integration with QML property binding | * Expose the current state and the state change as properties rather than functions - cleaner integration with QML property binding | ||
* Keep C++ implementation agnostic of the QML user interface implementation and the QML object tree composition | * Keep C++ implementation agnostic of the QML user interface implementation and the QML object tree composition | ||
* Avoid directly manipulating the QML object tree using C+ | * Avoid directly manipulating the QML object tree using C++. QML elements should "pull" data from C++ rather than C++ trying to "push" data into QML elements | ||
* Use OpenGL to do any blending, scaling or rotating. (-opengl to qmlviewer or QGLWidget as viewport of | * Use OpenGL to do any blending, scaling or rotating. (-opengl to qmlviewer or QGLWidget as viewport of QDeclarativeView) | ||
QDeclarativeView) | |||
* Run fullscreen rather than maximized to avoid compositing overhead (-fullscreen to qmlviewer or use showFullscreen() rather than show()) | * Run fullscreen rather than maximized to avoid compositing overhead (-fullscreen to qmlviewer or use showFullscreen() rather than show()) | ||
=== Open for discussion- add your comments directly here === | |||
* Default Property: If a property has been declared as the default property, the property tag can be omitted. '''Is this a good idea?''' | * Default Property: If a property has been declared as the default property, the property tag can be omitted. '''Is this a good idea?''' | ||
Line 77: | Line 69: | ||
* If a single property has to be documented, an end of line comment could still be used | * If a single property has to be documented, an end of line comment could still be used | ||
''For common coding conventions have also a look on'' http://doc.qt. | ''For common coding conventions have also a look on'' http://doc.qt.io/qt-5/qml-codingconventions.html | ||
=== see also === | === see also === |
Latest revision as of 09:00, 11 July 2019
This article lists out the best practices and also the DOs and DONTs recommended by developers while developing with Qt Quick. Please add your recommendations and help this page grow …
Formatting
/**
* The example component accomplishes …
*/
Rectangle {
id: example
// size independently from screen height
width: 100
height: 100
}
Use 4 spaces for indentation
- Let the { bracket be on the same line separated by 1 white space
- Use blank lines intelligently to separate code blocks
- Use a blank line before a multi line comment - easy to read
Basics
- Starting Qt 4.7.1, use QtQuick namespace, import QtQuick 1.0 - more consistent and is aimed for backward compatibility
- The .qml file name should start with an uppercase letter
- Use property alias and avoid duplicating same property within a component - uses less memory
- Specify each property in a single line - helps readability
- If you are grouping multiple properties in a single line - group logically related properties (e.g. x, y makes sense. x, color are not related)
- Use Grouped Properties where you find logical group of properties (e.g. font)
- Property names should begin with a lowercase letter (exception being Attached Properties)
- Use square brackets even while assigning a single property to a list - easy to identify that its a list
- Define signal handlers with the prefix "on" (e.g. onHover)
- Avoid single line comment at the end of line - one can easily miss this
- Avoid over documentation, name your variables meaningfully
Mandatory
- Each .qml file should have only one top level component
- Each .qml file should have at least one import
- Component name should match the .qml file
- A component id will be unique in that .qml file
- The component id must not be enclosed within quotes
- The component id must begin with a lower-case letter or underscore
- The component id cannot contain characters other than letters, numbers and underscores
- Specify property and value with this syntax property: value
- Multiple properties on same line are separated by a semicolon
Best Practices
- Avoid hard coding of sizes and positions, use layouts smartly
- Use QML more for UI and let Qt/C++ handle the backend, i.e. the business logic, data models
- Trying to do too much in javascript will lead to performance issues, use Qt C++
- Use javascript as sparingly as possible
- Expose the current state and the state change as properties rather than functions - cleaner integration with QML property binding
- Keep C++ implementation agnostic of the QML user interface implementation and the QML object tree composition
- Avoid directly manipulating the QML object tree using C++. QML elements should "pull" data from C++ rather than C++ trying to "push" data into QML elements
- Use OpenGL to do any blending, scaling or rotating. (-opengl to qmlviewer or QGLWidget as viewport of QDeclarativeView)
- Run fullscreen rather than maximized to avoid compositing overhead (-fullscreen to qmlviewer or use showFullscreen() rather than show())
Open for discussion- add your comments directly here
- Default Property: If a property has been declared as the default property, the property tag can be omitted. Is this a good idea?
- Use single line comment at the end of line only in places like end of a code block Is commenting ends of block this a good style?
- If a single property has to be documented, an end of line comment could still be used
For common coding conventions have also a look on http://doc.qt.io/qt-5/qml-codingconventions.html