Category:Developing Qt::Widgets: Difference between revisions
No edit summary |
No edit summary |
||
| Line 1: | Line 1: | ||
h3. Review Guidelines | |||
This is a list of things to look out for when reviewing commits to QtWidgets. This should be applied in conjunction with the general Qt guidelines in [[ | This is a list of things to look out for when reviewing commits to QtWidgets. This should be applied in conjunction with the general Qt guidelines in [[Qt Quality Gate Criteria]]. This is not an exhaustive list. It's a start. It can also be read as guidelines for making changes to QtWidgets, of course. | ||
Changes to QtWidgets should include: | Changes to QtWidgets should include:<br />* a change to dist/changes-x.y.z, when appropriate (new features: yes, bug fixes: yes, documentation typo fixes: no). If you don't mention your change in dist/changes-x.y.z, then the maintainers have to run after you and you'll be required to add the change anyway, just a lot later and with lots of other people committing to the same file… | ||
* a | For bugfixes:<br />* include a QTBUG- number. If you fix a bug without one, consider adding the bug to the database first. That makes it easier for Qt users to check whether a bug they're seeing is already known and where/whether it's already fixed. | ||
For | For new widgets:<br />* add QT_NO_FOO around the widget, and add the new QT_NO_ macro to the qconfig*.h files. If you add a new widgets, the chances of it being useful to a wide audience is rather slim. Face it: otherwise, it would have been in Qt already. That makes it only more important for resource-constrained systems to have the option of turning it off.<br />* add a new autotest (of course)<br />* adhere to the [[Category:Developing_Qt::Accessibility|Accessibility]] rules<br />* If your widget inherits from another widget, consider providing ''all'' base class ctors in your class, too. Add new arguments to the ''front'' of the argument list. End your constructors in QWidget '''parent = 0 or Qt::WFlags f = 0, depending on what the base class uses.<br />''' Mark ''all'' ctors explicit (even the ones that can only be called with more than one argument (for C++11); there's no use-case where implicit conversion of a QWidget* to your class type would be acceptable, and all QWidget subclass ctors contain the QWidget '''parent argument).<br />''' Think about use-cases for subclassing the widget, too, and provide protected and virtual functions (never data) as needed. Once the widget is in and released, you can't add new virtual functions anymore, so take particular care here.<br />* Use the styling subsystem to encode platform-specific look ''and feel''. | ||
[[Category:Developing Qt::Widgets]]<br />[[Category:Developing_Qt::Widgets]] | |||
Revision as of 11:21, 24 February 2015
h3. Review Guidelines
This is a list of things to look out for when reviewing commits to QtWidgets. This should be applied in conjunction with the general Qt guidelines in Qt Quality Gate Criteria. This is not an exhaustive list. It's a start. It can also be read as guidelines for making changes to QtWidgets, of course.
Changes to QtWidgets should include:
* a change to dist/changes-x.y.z, when appropriate (new features: yes, bug fixes: yes, documentation typo fixes: no). If you don't mention your change in dist/changes-x.y.z, then the maintainers have to run after you and you'll be required to add the change anyway, just a lot later and with lots of other people committing to the same file…
For bugfixes:
* include a QTBUG- number. If you fix a bug without one, consider adding the bug to the database first. That makes it easier for Qt users to check whether a bug they're seeing is already known and where/whether it's already fixed.
For new widgets:
* add QT_NO_FOO around the widget, and add the new QT_NO_ macro to the qconfig*.h files. If you add a new widgets, the chances of it being useful to a wide audience is rather slim. Face it: otherwise, it would have been in Qt already. That makes it only more important for resource-constrained systems to have the option of turning it off.
* add a new autotest (of course)
* adhere to the rules
* If your widget inherits from another widget, consider providing all base class ctors in your class, too. Add new arguments to the front of the argument list. End your constructors in QWidget parent = 0 or Qt::WFlags f = 0, depending on what the base class uses.
Mark all ctors explicit (even the ones that can only be called with more than one argument (for C++11); there's no use-case where implicit conversion of a QWidget* to your class type would be acceptable, and all QWidget subclass ctors contain the QWidget parent argument).
Think about use-cases for subclassing the widget, too, and provide protected and virtual functions (never data) as needed. Once the widget is in and released, you can't add new virtual functions anymore, so take particular care here.
* Use the styling subsystem to encode platform-specific look and feel.
This category currently contains no pages or media.