Currently change files are generated using create_changelog.pl from qtsdk.git [1]. This works OK, but misses a lot of bug fixes. For example, the 5.12.3 release of Qt Quick Controls 2 has a bunch of fixes, but create_changelog.pl still results in the "This release contains only minor code improvements" message:
https://codereview.qt-project.org/#/c/257810/1//ALL Simon wrote createchangelog [2], which includes any changes with a Jira task number. To quote what the tool does: commit 66f33fecc3b4a2896a4f33a3a7f06fb5cdd36dc8 Author: Simon Hausmann <[email protected]> Date: Thu Feb 25 16:54:02 2016 +0100 Added little helper tool to create an initial changelog template for a module Simply run the binary in the module directory with the correct branch checked out. The tool will peek at .qmake.conf to figure out the current version and run git tag -l to see what the previous version is. The resulting change log requires manual editing, but it is a start. Change-Id: I975c0d7a74fee8cab2ae6f400972c5dbc73ff367 Reviewed-by: Robin Burchell <[email protected]> And the README: This little tool faciliates the creation of change log files for Qt modules. It is written in golang and can be built by running go build With the binary in place, you can use it like this: 1. Change into a directory that contains a git clone of the module you'd like to create a change log for. 2. Make sure you have the release branch checked out that you'd like to create the file for. 3. Run the createchangelog tool from there. 4. The tool will parse .qmake.conf to determine the version of the upcoming release and it will use "git tag -l" to determine the previous release, in order to look through the git commits between the previous release and HEAD. 5. The proposed template output of the new change log file is printed to standard output, from which you can redirect it to a file and edit it accordingly. To show examples of what the tool generates, I've attached its output when run on the 5.12.3 and dev branches of qtquickcontrols2.git. So, the end result of switching to this is that it becomes clearer that we are actually fixing (non-trivial) bugs, contrary to what the "only minor code improvements" message says. Yes, it does mean that you will have to edit more stuff, but it's mostly just removing commit message bodies, which are included (if I understand correctly) in order to give more context than would otherwise be available had it just included the commit summary. If no one has any serious objections, I'd like for us to start using this to create the draft change file commits as soon as possible. [1] https://code.qt.io/cgit/qtsdk/qtsdk.git/tree/packaging-tools/create_changelog.pl [2] https://code.qt.io/cgit/qt/qtqa.git/tree/src/createchangelog
Qt 5.12.3 is a bug-fix release. It maintains both forward and backward compatibility (source and binary) with Qt 5.12.2. For more details, refer to the online documentation included in this distribution. The documentation is also available online: http://qt-project.org/doc/qt-5.12 The Qt version 5.12 series is binary compatible with the 5.11.x series. Applications compiled for 5.11 will continue to run with 5.12. Some of the changes listed in this file include issue tracking numbers corresponding to tasks in the Qt Bug Tracker: http://bugreports.qt-project.org/ Each of these identifiers can be entered in the bug tracker to obtain more information about a particular change. **************************************************************************** * Important Behavior Changes * **************************************************************************** **************************************************************************** * Library * **************************************************************************** - [QTBUG-70597] Attempt to stabilize Tumbler::test_itemsCorrectlyPositioned I'm not sure if this will help (because I haven't been able to reproduce the flakiness, even in a CI VM), but the tumbler should really not still be spinning after we got the position of its items, so make sure it's stopped before doing any comparisons. - [QTBUG-72786] Default: fix highlighted ItemDelegate colors - Make ItemDelegate respect highlightedText - Change ItemDelegate's highlightedText palette role from white to almost black (i.e inversion of "light" which is 0xFF090909), so that text shows up against a highlighted background. This also allows easily switching ComboBox to a dark style via palette customization. - [QTBUG-74512] Mark BaseValidator::throwRecursionDepthError() as final - [QTBUG-70451] DialogButtonBox: don't sort buttons based on their memory addresses When two buttons' roles are equal, the code would fall back to comparing the buttons' memory addresses. This leads to random results, which are especially noticeable on Windows and with release builds. This patch fixes the issue by instead returning false if the roles are equal. This still satisfies the "comp(a,a)==false" requirement of strict weak ordering: https://en.cppreference.com/w/cpp/named_req/Compare The patch also changes the sorting algorithm used from std::sort() to std::stable_sort(). Although it doesn't appear to be necessary from the testing that I did, it is good to ensure that the order of equal elements is maintained. - [QTBUG-70161] QQuickComboBox: ensure we don't close popup on iOS On iOS (and Android), we give focus to a control on touch release (rather than on touch begin, which is normal on desktop). For a QQuickCombobox, this means that we will both handle focus and open the popup on touch release, and not focus on touch begin and open popup on touch release, like on desktop. Because of this, we need to be more careful about when we choose to close the popup as well, otherwise it will close down before it gets a chance to show on iOS. This patch will check why we lose focus on both the inner line edit and the combobox itself, and based on this, choose whether we should close the popup. Basically, if focus is just transferred between the popup button and the line edit, we choose to keep the popup open. - [QTBUG-72886] Fix DialogButtonBox content size calculation Some history: - f1f884d3 worked around an issue in DialogButtonBox. - c2fd8f7d fixed it by using contentWidth; i.e. the implicit width of the contentItem. It caused QTBUG-72372. - I tried to fix QTBUG-72372 with 6476de0b, but created (or exposed) QTBUG-73860. The problem in QTBUG-73860 can be seen with the following example: Dialog { id: dialog visible: true standardButtons: Dialog.Ok } The single 'Ok' button here will go outside of the dialog. The underlying issue can be seen by looking into DialogButtonBox.qml: implicitWidth: Math.max(implicitBackgroundWidth + leftInset + rightInset, (control.count === 1 ? contentWidth * 2 : contentWidth) + leftPadding + rightPadding) implicitHeight: Math.max(implicitBackgroundHeight + topInset + bottomInset, contentHeight + topPadding + bottomPadding) The implicit width of the box in this case is contentWidth * 2 (there is one button, so control.count === 1). This should result in the button taking half the width of the box and being aligned to the right: alignment: count === 1 ? Qt.AlignRight : undefined ... delegate: Button { width: control.count === 1 ? control.availableWidth / 2 : undefined } What actually happens is that the contentItem (ListView) is temporarily 0 until it gets its final size of 100. However, QQuickDialogButtonBox doesn't respond to this change in the ListView's contentWidth. This problem can be fixed by returning to c2fd8f7d's resizeContent() implementation, which uses contentWidth. Then, there is a second issue: Dialog { id: dialog visible: true standardButtons: Dialog.Ok width: 300 } The button here is also positioned outside of the box. The problem is that the contentWidth is based on implicitContentWidth: QQuickContainerPrivate::updateContentWidth() { // ... contentWidth = implicitContentWidth; // ... } implicitContentWidth is calculated by calling getContentWidth(): void QQuickControlPrivate::updateImplicitContentWidth() { // ... implicitContentWidth = getContentWidth(); // ... } In the case of horizontal alignment, QQuickDialogButtonBoxPrivate::getContentWidth() uses the implicit width of the largest button: for (int i = 0; i < count; ++i) { QQuickItem *item = q->itemAt(i); if (item) { totalWidth += item->implicitWidth(); maxWidth = qMax(maxWidth, item->implicitWidth()); } } // ... if ((alignment & Qt::AlignHorizontal_Mask) == 0) totalWidth = qMax(totalWidth, count * maxWidth + totalSpacing); The Default style button has an implicitWidth of 100. The DialogButtonBox in the example above is 300 pixels wide, so the button should be 150, and it is, thanks to its width binding. However, the DialogButtonBox uses contentWidth to size its contentItem (ListView), and the contentWidth is, as mentioned, 100: the implicit width of the button. So, the button ends up hanging over the side of the box, as it's larger than the box thinks it is. This problem is fixed by setting DialogButtonBox's contentWidth to the contentWidth of the contentItem (ListView). This makes DialogButtonBox use the explicit widths of the buttons rather than their implicit widths. Since the contentWidth is no longer implicit, we must also change any use of contentWidth in the implicitWidth binding to implicitContentWidth. While writing auto tests for this, they caught an issue where contentWidth wasn't updated, so now we call resizeContent() in QQuickContainer::setContentWidth(). Change-Id: I99ffda21b47aeb14d4382e453e87c4312f343a1c - [QTBUG-74226] Fix attached ToolTips using the timeout of the last shown tool tip Attached ToolTips share a single ToolTip item and set properties (such as delay) on it before showing it. Before 63899f3185, this wasn't a problem, but now QQuickToolTip has its own show() function that QQuickToolTipAttached calls. QQuickToolTipAttached passes -1 by default, which QQuickToolTip sees as the "default" and hence doesn't set a timeout at all. However, since that QQuickToolTip instance is shared, it still has a previous timeout value from the last time it was shown by a different QQuickToolTipAttached object. So, instead of QQuickToolTipAttached passing the timeout to QQuickToolTip::show(), make it set it on the QQuickToolTip instead. This ensures that it has the correct value if no timeout was specified for an attached tool tip. - [QTBUG-72536] QQuickScrollView: respect the content size set on/by the flickable If the flickable inside a scrollview has an explicit content size assigned, or if the flickable was created by the application, then don't fall back to calculate the content size. The reason is that it should not try to change the content size of a flickable that is controlled by the application (or by the flickable itself, in the case of ListView, ScrollView and TextArea). Sometimes e.g ListView will report a negative contentWidth, which is not considered illegal. From before we used to just check if the child flickable had a negative content size, and if so, take that as a evidence that the flickable was owned by the scrollview. But with this patch, we instead add two extra variables that keeps explicit track of whether or not we should read the content size from the flickable, regardless of the values it might return. With the two new variables, we also no longer need the "ownsFlickable" property, as we can instead use the new variables to check for the same. - [QTBUG-73354] QQuickMenu: allow enter/return to be used to activate items Before this patch, only space was allowed. Windows 10 and macOS 10.14.2 both allow using enter to activate menu items. Change-Id: I64476347669ff73f233efd129563a18ba51618a5 - [QTBUG-73687] Doc: state that negative scales for Popup are not supported This sentence was probably copied from Item's docs. - [QTBUG-71290] Drawer: fix infinite positioning loop This fixes the issue where Drawer would try to reposition itself forever, but does not address the fact that it is incorrectly positioned afterwards. - [QTBUG-66494] Page: fix binding loop When Dialog (which derives from Page) has only its title set, there'd be a binding loop. A simplified version of the call stack: - QQuickPopup::componentComplete - QQuickPopupPrivate::prepareEnterTransition - QQuickItem::setVisible - QQuickPagePrivate::itemVisibilityChanged - QQuickDialog::implicitHeaderWidthChanged - QQmlBinding::expressionChanged <== Dialog.qml's implicitWidth binding - QQmlPropertyData::readProperty - QQuickDialog::implicitHeaderWidth - QQuickPage::implicitHeaderWidth - QQuickItem::implicitWidth <== QQuickPagePrivate::header, aka Label - QQuickTextPrivate::getImplicitWidth - QQuickTextPrivate::updateSize - QQuickTextPrivate::setupTextLayout - QQuickItem::setImplicitSize - QQuickItemPrivate::implicitWidthChanged - QQuickPagePrivate::itemImplicitWidthChanged - QQuickDialog::implicitHeaderWidthChanged - QQmlBinding::expressionChanged - QQmlAbstractBinding::printBindingLoopError Fix the issue by not emitting change signals if we're already in the process of doing so. Change-Id: I37d6fa35b1e70420e436c0e001f55035d7630542
Qt 5.14 introduces many new features and improvements as well as bugfixes over the 5.12.x series. For more details, refer to the online documentation included in this distribution. The documentation is also available online: http://qt-project.org/doc/qt-5 The Qt version 5.14 series is binary compatible with the 5.12.x series. Applications compiled for 5.12 will continue to run with 5.14. Some of the changes listed in this file include issue tracking numbers corresponding to tasks in the Qt Bug Tracker: http://bugreports.qt-project.org/ Each of these identifiers can be entered in the bug tracker to obtain more information about a particular change. **************************************************************************** * Important Behavior Changes * **************************************************************************** **************************************************************************** * Library * **************************************************************************** - [QTBUG-70451] DialogButtonBox: don't sort buttons based on their memory addresses When two buttons' roles are equal, the code would fall back to comparing the buttons' memory addresses. This leads to random results, which are especially noticeable on Windows and with release builds. This patch fixes the issue by instead returning false if the roles are equal. This still satisfies the "comp(a,a)==false" requirement of strict weak ordering: https://en.cppreference.com/w/cpp/named_req/Compare The patch also changes the sorting algorithm used from std::sort() to std::stable_sort(). Although it doesn't appear to be necessary from the testing that I did, it is good to ensure that the order of equal elements is maintained. - [QTBUG-70161] QQuickComboBox: ensure we don't close popup on iOS On iOS (and Android), we give focus to a control on touch release (rather than on touch begin, which is normal on desktop). For a QQuickCombobox, this means that we will both handle focus and open the popup on touch release, and not focus on touch begin and open popup on touch release, like on desktop. Because of this, we need to be more careful about when we choose to close the popup as well, otherwise it will close down before it gets a chance to show on iOS. This patch will check why we lose focus on both the inner line edit and the combobox itself, and based on this, choose whether we should close the popup. Basically, if focus is just transferred between the popup button and the line edit, we choose to keep the popup open. - [QTBUG-72886] Fix DialogButtonBox content size calculation Some history: - f1f884d3 worked around an issue in DialogButtonBox. - c2fd8f7d fixed it by using contentWidth; i.e. the implicit width of the contentItem. It caused QTBUG-72372. - I tried to fix QTBUG-72372 with 6476de0b, but created (or exposed) QTBUG-73860. The problem in QTBUG-73860 can be seen with the following example: Dialog { id: dialog visible: true standardButtons: Dialog.Ok } The single 'Ok' button here will go outside of the dialog. The underlying issue can be seen by looking into DialogButtonBox.qml: implicitWidth: Math.max(implicitBackgroundWidth + leftInset + rightInset, (control.count === 1 ? contentWidth * 2 : contentWidth) + leftPadding + rightPadding) implicitHeight: Math.max(implicitBackgroundHeight + topInset + bottomInset, contentHeight + topPadding + bottomPadding) The implicit width of the box in this case is contentWidth * 2 (there is one button, so control.count === 1). This should result in the button taking half the width of the box and being aligned to the right: alignment: count === 1 ? Qt.AlignRight : undefined ... delegate: Button { width: control.count === 1 ? control.availableWidth / 2 : undefined } What actually happens is that the contentItem (ListView) is temporarily 0 until it gets its final size of 100. However, QQuickDialogButtonBox doesn't respond to this change in the ListView's contentWidth. This problem can be fixed by returning to c2fd8f7d's resizeContent() implementation, which uses contentWidth. Then, there is a second issue: Dialog { id: dialog visible: true standardButtons: Dialog.Ok width: 300 } The button here is also positioned outside of the box. The problem is that the contentWidth is based on implicitContentWidth: QQuickContainerPrivate::updateContentWidth() { // ... contentWidth = implicitContentWidth; // ... } implicitContentWidth is calculated by calling getContentWidth(): void QQuickControlPrivate::updateImplicitContentWidth() { // ... implicitContentWidth = getContentWidth(); // ... } In the case of horizontal alignment, QQuickDialogButtonBoxPrivate::getContentWidth() uses the implicit width of the largest button: for (int i = 0; i < count; ++i) { QQuickItem *item = q->itemAt(i); if (item) { totalWidth += item->implicitWidth(); maxWidth = qMax(maxWidth, item->implicitWidth()); } } // ... if ((alignment & Qt::AlignHorizontal_Mask) == 0) totalWidth = qMax(totalWidth, count * maxWidth + totalSpacing); The Default style button has an implicitWidth of 100. The DialogButtonBox in the example above is 300 pixels wide, so the button should be 150, and it is, thanks to its width binding. However, the DialogButtonBox uses contentWidth to size its contentItem (ListView), and the contentWidth is, as mentioned, 100: the implicit width of the button. So, the button ends up hanging over the side of the box, as it's larger than the box thinks it is. This problem is fixed by setting DialogButtonBox's contentWidth to the contentWidth of the contentItem (ListView). This makes DialogButtonBox use the explicit widths of the buttons rather than their implicit widths. Since the contentWidth is no longer implicit, we must also change any use of contentWidth in the implicitWidth binding to implicitContentWidth. While writing auto tests for this, they caught an issue where contentWidth wasn't updated, so now we call resizeContent() in QQuickContainer::setContentWidth(). Change-Id: I99ffda21b47aeb14d4382e453e87c4312f343a1c - [QTBUG-74276] Fix SplitView crash when using certain attached properties If the attached property object was created on an item that SplitView doesn't manage, then its m_splitView member will be null, so check for that. Sometimes, an attached SplitView object will be created on an item that SplitView _does_ manage, but SplitView's own contentItem hasn't been created yet (see the comment in the QQuickSplitViewAttached constructor). In that case the SplitView will see the item added as a child of its contentItem eventually, and we just have to wait. While we are waiting, check access to our members in case they are null. - [QTBUG-74226] Fix attached ToolTips using the timeout of the last shown tool tip Attached ToolTips share a single ToolTip item and set properties (such as delay) on it before showing it. Before 63899f3185, this wasn't a problem, but now QQuickToolTip has its own show() function that QQuickToolTipAttached calls. QQuickToolTipAttached passes -1 by default, which QQuickToolTip sees as the "default" and hence doesn't set a timeout at all. However, since that QQuickToolTip instance is shared, it still has a previous timeout value from the last time it was shown by a different QQuickToolTipAttached object. So, instead of QQuickToolTipAttached passing the timeout to QQuickToolTip::show(), make it set it on the QQuickToolTip instead. This ensures that it has the correct value if no timeout was specified for an attached tool tip. - [QTBUG-73484] Update plugins.qmltypes for Qt 5.13 - [QTBUG-72536] QQuickScrollView: respect the content size set on/by the flickable If the flickable inside a scrollview has an explicit content size assigned, or if the flickable was created by the application, then don't fall back to calculate the content size. The reason is that it should not try to change the content size of a flickable that is controlled by the application (or by the flickable itself, in the case of ListView, ScrollView and TextArea). Sometimes e.g ListView will report a negative contentWidth, which is not considered illegal. From before we used to just check if the child flickable had a negative content size, and if so, take that as a evidence that the flickable was owned by the scrollview. But with this patch, we instead add two extra variables that keeps explicit track of whether or not we should read the content size from the flickable, regardless of the values it might return. With the two new variables, we also no longer need the "ownsFlickable" property, as we can instead use the new variables to check for the same. - [QTBUG-73354] QQuickMenu: allow enter/return to be used to activate items Before this patch, only space was allowed. Windows 10 and macOS 10.14.2 both allow using enter to activate menu items. Change-Id: I64476347669ff73f233efd129563a18ba51618a5 - [QTBUG-73687] Doc: state that negative scales for Popup are not supported This sentence was probably copied from Item's docs. - [QTBUG-71290] Drawer: fix infinite positioning loop This fixes the issue where Drawer would try to reposition itself forever, but does not address the fact that it is incorrectly positioned afterwards. - [QTBUG-73754] Fix failing text control tests As bbc81363f explains, we should be using QObject::isSignalConnected() instead of QObjectPrivate::isSignalConnected(). - [QTBUG-66494] Page: fix binding loop When Dialog (which derives from Page) has only its title set, there'd be a binding loop. A simplified version of the call stack: - QQuickPopup::componentComplete - QQuickPopupPrivate::prepareEnterTransition - QQuickItem::setVisible - QQuickPagePrivate::itemVisibilityChanged - QQuickDialog::implicitHeaderWidthChanged - QQmlBinding::expressionChanged <== Dialog.qml's implicitWidth binding - QQmlPropertyData::readProperty - QQuickDialog::implicitHeaderWidth - QQuickPage::implicitHeaderWidth - QQuickItem::implicitWidth <== QQuickPagePrivate::header, aka Label - QQuickTextPrivate::getImplicitWidth - QQuickTextPrivate::updateSize - QQuickTextPrivate::setupTextLayout - QQuickItem::setImplicitSize - QQuickItemPrivate::implicitWidthChanged - QQuickPagePrivate::itemImplicitWidthChanged - QQuickDialog::implicitHeaderWidthChanged - QQmlBinding::expressionChanged - QQmlAbstractBinding::printBindingLoopError Fix the issue by not emitting change signals if we're already in the process of doing so. Change-Id: I37d6fa35b1e70420e436c0e001f55035d7630542 Controls -------- - Added cache property to icon. - SplitView: * [QTBUG-56318] Introduced SplitView, a control that lays out items horizontally or vertically with a draggable splitter between each item.
_______________________________________________ Development mailing list [email protected] https://lists.qt-project.org/listinfo/development
