Re: [Development] Nominating Matthias Rauter for approval status

[EXT Mitch Curtis via Development]

+1

> -Original Message-
> From: Development  On Behalf Of
> Paul Tvete via Development
> Sent: Tuesday, January 30, 2024 8:11 PM
> To: Qt development mailing list 
> Subject: [Development] Nominating Matthias Rauter for approval status
> 
> Hi,
> 
> I would like to nominate Matthias Rauter as an approver for the Qt Project.
> 
> Matthias has been working on Qt for more than a year now. In this time, he
> has done great work on Qt Location and Qt SVG, among other. I have had the
> pleasure to work with him on the Curve Rendering project in Qt Quick Shapes
> where he has made impressive contributions. He has been consistently
> professional in development and review, and I am certain that he will exercise
> his approver powers responsibly.
> 
> List of changes made by Matthias: https://codereview.qt-
> project.org/q/owner:matthias.rauter%2540qt.io  project.org/q/owner:matthias.rauter%2540qt.io>
> Matthias's review activity: https://codereview.qt-
> project.org/q/commentby:matthias.rauter%2540qt.io
>  project.org/q/commentby:matthias.rauter%2540qt.io>
> 
> Cheers,
>  - Paul
-- 
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] QtQuick Dialogs Widgets fallback

[EXT Mitch Curtis via Development]

> -Original Message-
> From: Kai Uwe Broulik 
> Sent: Thursday, August 24, 2023 7:38 PM
> To: EXT Mitch Curtis ; development@qt-project.org
> Subject: Re: [Development] QtQuick Dialogs Widgets fallback
> 
> Hi,
> > Which style are you referring to here?
> 
> The default QML one, none Fusion/Material/etc substyles.

The default depends on which platform you're on. You can check which style is 
in use by setting QT_LOGGING_RULES to qt.quick.controls.style=true.

> > If there's a way we can improve our desktop-based fallbacks, it would be
> good to know about that.
> 
> First of all, they suffer from the same issue as most of QtQuick Controls 2,
> being in the same scene, which is fine for embedded or mobile but not how
> desktops work.
>
> It means the dialog doesn't have title bar, not the proper shadow around it,
> cannot be moved out of the way, cannot exceed the scene's bounds, etc.

Indeed, this is a larger issue, and is tracked by 
https://bugreports.qt.io/browse/QTBUG-69558.

> More importantly, though, the dialog's size seems fixed to 320x160. If you
> add three buttons (Save Changes? Apply / Discard / Cancel), the
> DialogButtonBox already gets too wide on most locales.
> 
> They also cannot have an icon (error icon, exclamation mark, question mark),
> which you would expect from a message box.

Would you be willing to create bug reports for these? 

> Cheers
> Kai Uwe
-- 
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] QtQuick Dialogs Widgets fallback

[EXT Mitch Curtis via Development]

> -Original Message-
> From: Development  On Behalf Of
> Kai Uwe Broulik
> Sent: Wednesday, August 23, 2023 4:17 AM
> To: development@qt-project.org
> Subject: [Development] QtQuick Dialogs Widgets fallback
> 
> Hi everyone,

Hi Kai,
 
> we found that the Qt Quick Dialogs (MessageDialog and friends) do not
> support a fallback to their widget counterpart like the ones from
> Qt.labs.platform did.
> 
> In KDE Plasma we do not provide a platform theme implementation for the
> message or color dialogs, as the Qt ones are “good enough”, thus we will get
> the QtQuick fallback which are a bit rough for use in a desktop application.

Which style are you referring to here? If there's a way we can improve our 
desktop-based fallbacks, it would be good to know about that.

> I understand and fully agree that the Qt Quick Dialogs module shouldn’t link
> QtWidgets, but is there a way we could support a fallback to QMessageBox,
> QColorDialog, etc, as the labs module did?

Assuming that we could make it entirely optional (also for e.g. static builds), 
I wouldn't be against it, but I'd still prefer to know what could be improved 
with our (desktop style) Qt Quick fallbacks.

> I found [1] which restructures the relevant styles into their own respective
> plug-in. Is it possible we add a QtQuick.Dialogs.Widgets import that then
> delegates to the relevant widgets, if there’s no platform-provided dialog? I
> don’t want to go down the rabbit hole of adding entire proper QFactory* for
> what is effectively a single conspicuous plug-in, so I wonder if we could
> piggyback on that infrastructure.
> 
> Cheers
> Kai Uwe
> 
> [1] https://codereview.qt-project.org/c/qt/qtdeclarative/+/476748
> --
> Development mailing list
> Development@qt-project.org
> https://lists.qt-project.org/listinfo/development
-- 
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Behavior-changing bugfixes in patch-level releases

[EXT Mitch Curtis via Development]

> -Original Message-
> From: Arno Rehn 
> Sent: Wednesday, July 12, 2023 4:13 PM
> To: EXT Mitch Curtis ; Qt development mailing list
> 
> Subject: Re: [Development] Behavior-changing bugfixes in patch-level releases
> 
> Hi Mitch,
> 
> On 12.07.2023 09:52, EXT Mitch Curtis wrote:
> >> Context: We have been hit by
> >> https://codereview.qt-project.org/c/qt/qtdeclarative/+/472596
> >> (which is even marked as "Important Behavior Change") ending up only
> >> in 6.5.1. It was quite the headache figuring out that 6.5.0 ->
> >> 6.5.1 has broken part of our ListViews.
> >
> > I'm sorry to hear that.
> >
> > As the developer who approved the change, I've left my thoughts
> > here:
> >
> > https://bugreports.qt.io/browse/QTBUG-
> 114166?focusedId=734562=com
> > .atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-
> > 734562
> >
> >  In summary, I believe the official branch policy was followed here.
> >
> > I'm not sure if your use case is the same as the snippet in the bug
> > report, so it would be useful if you could share it so that we can see
> > if there's a legitimate usage that we've broken. That's not to say
> > that it's good to introduce regressions, of course, but often it's
> > hard to know how users are using APIs and we often only find out after
> > the change has been merged, because auto tests can't cover every use
> > case for the same reason.
> 
> We have a vertical ListView which shows icon-only buttons. The buttons all
> have the same width, but depending on the icon size and/or the style, that
> width may differ. So we update the contentWidth of the ListView as soon as
> the first button is loaded. Something like this:
> 
> 
> ListView {
>  id: sidebar
>  Layout.fillHeight: true
>  implicitWidth: contentWidth
> 
>  model: // ...
> 
>  delegate: IconButton {
>  icon.name: // ...
>  onImplicitWidthChanged: if (sidebar.contentWidth < 0) {
>  sidebar.contentWidth = implicitWidth
>  }
>  }
> }
> 
> Maybe we're doing this wrong; but I didn't find any other viable way to have a
> ListView auto-determine the size in the non-scrollable dimension based on its
> content.

I'd recommend setting a size on the ListView that doesn't depend on the 
implicit size of the delegates; one that is calculated with TextMetrics, for 
example. The reason for this is that it's not always possible to know the size 
of every delegate at startup. While scrolling a view, delegates that are larger 
or smaller might be loaded.

To use a more recent example where this problem had to be solved, 
https://doc.qt.io/qt-6/qml-qtquick-tableview.html#row-heights-and-column-widths 
says:

"When a new column is flicked into view, TableView will determine its width 
by calling the columnWidthProvider. If set, this function will alone decide the 
width of the column. Otherwise, it will check if an explicit width has been set 
with setColumnWidth(). If not, implicitColumnWidth() will be used. The implicit 
width of a column is the same as the largest implicit width found among the 
currently loaded delegate items in that column. Trying to set an explicit width 
directly on a delegate has no effect, and will be ignored and overwritten. The 
same logic also applies to row heights."

Note the part that says:

"The implicit width of a column is the same as the largest implicit width 
found among the currently loaded delegate items in that column."

There's also a note below:

"Note: The resolved width of a column is discarded when the whole column is 
flicked out of the view, and is recalculated again if it's flicked back in. 
This means that if the width depends on the implicitColumnWidth(), the 
calculation can be different each time, depending on which row you're at when 
the column enters (since implicitColumnWidth() only considers the delegate 
items that are currently loaded). To avoid this, you should use a 
columnWidthProvider, or ensure that all the delegate items in the same column 
have the same implicitWidth."

This is also described in e.g. https://bugreports.qt.io/browse/QTBUG-76830, and 
documented in 
https://doc-snapshots.qt.io/qt6-dev/qml-qtquick-listview.html#variable-delegate-size-and-section-labels.
 The cacheBuffer workaround mentioned there may help but is not a complete 
solution.

From testing locally with a runnable adaptation of your example, I get a 
ListView whose width is 12:

import QtQuick
import QtQuick.Controls
import QtQuick.Layouts

ApplicationWindow {
visible: true
width: 800
height: 600
title:

Re: [Development] Behavior-changing bugfixes in patch-level releases

[EXT Mitch Curtis via Development]

Hi Arno,

> -Original Message-
> From: Development  On Behalf Of
> Arno Rehn
> Sent: Wednesday, July 12, 2023 3:01 PM
> To: Qt development mailing list 
> Subject: [Development] Behavior-changing bugfixes in patch-level releases
> 
> Hey everyone,
> 
> what is the policy for adding behavior-changing bugfixes to patch-level
> releases? Is this something to expect?
> At the moment we operate under the assumption that bumping the patch-
> level of Qt is pretty much a no-brainer and can be done without having to do
> much in the way of validation.
> 
> If behavior changes in patch-level releases are to be expected, we'll have to 
> be
> more careful with bumping Qt.
> 
> Context: We have been hit by
> https://codereview.qt-project.org/c/qt/qtdeclarative/+/472596 (which is
> even marked as "Important Behavior Change") ending up only in 6.5.1.
> It was quite the headache figuring out that 6.5.0 -> 6.5.1 has broken part of
> our ListViews.

I'm sorry to hear that.

As the developer who approved the change, I've left my thoughts here:

https://bugreports.qt.io/browse/QTBUG-114166?focusedId=734562=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-734562

In summary, I believe the official branch policy was followed here.

I'm not sure if your use case is the same as the snippet in the bug report, so 
it would be useful if you could share it so that we can see if there's a 
legitimate usage that we've broken. That's not to say that it's good to 
introduce regressions, of course, but often it's hard to know how users are 
using APIs and we often only find out after the change has been merged, because 
auto tests can't cover every use case for the same reason.

> Regards,
> Arno
> 
> --
> Arno Rehn
> Tel +49 89 189 166 0
> Fax +49 89 189 166 111
> a.r...@menlosystems.com
> www.menlosystems.com
> 
> Menlo Systems GmbH
> Bunsenstrasse 5, D-82152 Martinsried, Germany Amtsgericht München HRB
> 138145
> Geschäftsführung: Dr. Michael Mei, Dr. Ronald Holzwarth USt.-IdNr.
> DE217772017, St.-Nr. 14316170324
> --
> Development mailing list
> Development@qt-project.org
> https://lists.qt-project.org/listinfo/development
-- 
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Nominating Santhosh Kumar Selvaraj for approver rights

[EXT Mitch Curtis via Development]

+1

> -Original Message-
> From: Development  On Behalf Of
> Jan-Arve Sæther via Development
> Sent: Wednesday, June 21, 2023 2:56 AM
> To: Jack Simcox via Development 
> Subject: [Development] Nominating Santhosh Kumar Selvaraj for approver
> rights
> 
> Hello all,
> 
> I would like to nominate Santhosh Kumar Selvaraj for approver rights in the Qt
> project.
> 
> Santhosh is a member of the UI Team, and has been working on improvement
> to our styles, dark mode support, palette handling both in qtbase and
> qtdeclarative.
> 
> You can see his merged changes here:
> https://codereview.qt-
> project.org/q/owner:santhosh.kumar.selvaraj%2540qt.io+is:merged
> 
> and his reviews here:
> 
> https://codereview.qt-
> project.org/q/reviewer:santhosh.kumar.selvaraj%2540qt.io
> 
> cheers,
> ---
> Jan Arve Sæther
> Team Lead
> 
> The Qt Company
> Sandakerveien 116
> 0484, Oslo, Norway
> jan-arve.saet...@qt.io
> http://qt.io
> ---
> 

-- 
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Nominating Edward Welbourne as QLocale / date/time maintainer

[EXT Mitch Curtis via Development]

+1

> -Original Message-
> From: Development  On Behalf Of
> Marc Mutz via Development
> Sent: Thursday, May 4, 2023 6:10 PM
> To: development@qt-project.org
> Subject: [Development] Nominating Edward Welbourne as QLocale /
> date/time maintainer
> 
> Hi,
> 
> I'd like to nominate Eddy as the maintainer for the QLocale and
> src/corelib/time QtCore subsystems. Eddy is filling that role de-facto 
> already;
> making it de-jure sounds only logical.
> 
> I asked, and he'd be on board, if we'd have him.
> 
> Anyone else in favour? (I'm not sure I have a vote, actually...)
> 
> Thanks,
> Marc
> 
> --
> Marc Mutz 
> Principal Software Engineer
> 
> The Qt Company
> Erich-Thilo-Str. 10 12489
> Berlin, Germany
> www.qt.io
> 
> Geschäftsführer: Mika Pälsi, Juha Varelius, Jouni Lintunen Sitz der 
> Gesellschaft:
> Berlin,
> Registergericht: Amtsgericht Charlottenburg, HRB 144331 B
> --
> Development mailing list
> Development@qt-project.org
> https://lists.qt-project.org/listinfo/development
-- 
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Qt code browser url changed (cgit <-> cgit.cgi)?

[EXT Mitch Curtis via Development]

The source code text seems to be missing - the line numbers seem to be correct 
by I don't see any code. Inspecting the HTML shows that there is no text there, 
so it's not just a CSS issue.

> -Original Message-
> From: Development  On Behalf Of
> Andrey Leman via Development
> Sent: Monday, March 27, 2023 5:06 AM
> To: Konrad Rosenbaum ; development@qt-project.org
> Subject: Re: [Development] Qt code browser url changed (cgit <-> cgit.cgi)?
> 
> Hi,
> 
> 
> 
> Yes, the server has been upgraded to new version. Could you please test if it
> works as before now? e.g https://code.qt.io/cgit/...
> 
> 
> 
> From: Development  on behalf of
> Konrad Rosenbaum 
> Date: Sunday, 26 March 2023, 18:07
> To: development@qt-project.org 
> Subject: Re: [Development] Qt code browser url changed (cgit <-> cgit.cgi)?
> 
> Hi,
> 
> On 26/03/2023 14:16, Christian Ehrlicher wrote:
> > today there was a thread on stackoverflow which mentions that the
> > links to the examples don't work anymore. The links in the docs (and
> > also in the source repo) are
> >
> > https://code.qt.io/cgit/qt/qtbase.git/tree/examples/widgets/...
> >
> > But it needs to be
> >
> > https://code.qt.io/cgit.cgi/qt/qtbase.git/tree/examples/...
> >
> >
> > Did something changed recently wrt this? Do you need a bug report for it?
> 
> It changed some time before or around noon on March 25th. I have a regular
> git pull job running in the background and it failed since the afternoon of 
> that
> day. My guess would be that someone did maintenance or installed a new
> version and some minor mayhem was overseen...
> 
> Question to the admins: will you fix the cgit URLs or does everybody else need
> to fix their links?
> 
> 
> 
>  Konrad

-- 
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Using QtCreator for Qt development

[EXT Mitch Curtis via Development]

> -Original Message-
> From: Development  On Behalf Of
> Eike Ziller via Development
> Sent: Monday, 12 December 2022 5:20 PM
> To: Владимир Белявский 
> Cc: development@qt-project.org
> Subject: Re: [Development] Using QtCreator for Qt development
> 
> 
> 
> > Am 10/12/2022 um 13:57 schrieb Владимир Белявский
> :
> >
[...]
> > also view all unit tests there, debug, fix, build and run selected directly 
> > and
> so on?
> 
> I think the only well-supported Qt configuration is with QT_BUILD_TESTS=ON
> and QT_BUILD_TESTS_BY_DEFAULT=ON. Or are there CMake variables to
> turn individual test on for the build?

Владимир, I use these configure args:

-DCMAKE_BUILD_TYPE=Debug -DFEATURE_developer_build=ON -DQT_BUILD_TESTS=ON 
-DQT_BUILD_TESTS_BY_DEFAULT=OFF -DQT_BUILD_EXAMPLES=ON 
-DQT_BUILD_EXAMPLES_BY_DEFAULT=OFF -DFEATURE_sanitize_address=ON

The test and example-related ones will ensure that you can build tests and 
examples (in Creator), but by default they won't be built, which saves a lot of 
time.

I use Alt+B,Alt+R ("Build for Run Configuration") to build the currently 
selected/active (the target that comes up when you hit Ctrl+T) test, as 
building the top-level qtdeclarative project won't do that with the configure 
args above.

> Anyway, with both on, you can just choose a test to run & debug. It looks like
> our autotest integration (the separate "Tests" panel) takes ages looking for
> tests, but running tests directly as normal run configurations works fine.

For what it's worth, I disable the AutoTest plugin, and use application 
arguments to run specific test(s) instead.

> Qt also has some mechanism for opening tests as separate CMake projects,
> but I don't know how that works.
> 
> Br, Eike
> 
> --
> Eike Ziller
> Principal Software Engineer
> 
> The Qt Company GmbH
> Erich-Thilo-Straße 10
> D-12489 Berlin
> eike.zil...@qt.io
> http://qt.io
> Geschäftsführer: Mika Pälsi,
> Juha Varelius, Jouni Lintunen
> Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg,
> HRB 144331 B
> 
> 
> ___
> Development mailing list
> Development@qt-project.org
> https://lists.qt-project.org/listinfo/development
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

[Development] Heads up for anyone working on Qt Quick Controls code

[EXT Mitch Curtis via Development]

Some directories have been renamed in this patch that will hopefully be merged 
soon:

https://codereview.qt-project.org/c/qt/qtdeclarative/+/444028

You may have to rebase open patches.

It may also be necessary to wipe your qtdeclarative build and rebuild.

No user-facing API/libraries should be affected.
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Duplicated test data tags

[EXT Mitch Curtis via Development]

> -Original Message-
> From: Edward Welbourne 
> Sent: Friday, 14 October 2022 4:56 PM
> To: Milian Wolff ; EXT Mitch Curtis 
> Cc: Development@qt-project.org
> Subject: Re: [Development] Duplicated test data tags
[...]
> Mitch Curtis (14 October 2022 03:40) replied:
> > QTest::failOnWarning (introduced in 6.3) could also be used by tests
> > to make that warning fail the test:
> >
> > https://doc.qt.io/qt-6/qtest.html#failOnWarning
> 
> True enough; but you would need to add that to the start of your _data()
> function; I think a global setting is more in line with what's needed.

So even init() would be too late? I would have thought that would run before 
the data function.

> Fortunately we do have QT_FATAL_WARNINGS; I had forgotten about that.
> 
> So the question is: does it suffice to encourage developers to test with that
> enabled, or do we need something more specific to the particular issue of tag
> and column names in _data() functions ?
> 
>   Eddy.
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Duplicated test data tags

[EXT Mitch Curtis via Development]

> -Original Message-
> From: Development  On Behalf Of
> Milian Wolff
> Sent: Friday, 14 October 2022 3:00 AM
> To: Development@qt-project.org
> Subject: Re: [Development] Duplicated test data tags
> 
[...] 
> I have many times accidentally written bogus code that duplicated the tags.
> Getting a warning is useful, so thanks for working on that!
> 
> But we won't easily spot these in the thousands of lines of outputs a large
> test suite is generating. At the very least I would suggest something akin to
> QT_FATAL_WARNINGS that can be set to more easily spot faulty client code.

QTest::failOnWarning (introduced in 6.3) could also be used by tests to make 
that warning fail the test:

https://doc.qt.io/qt-6/qtest.html#failOnWarning

> Cheers
> --
> Milian Wolff
> m...@milianw.de
> http://milianw.de
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Using '#pragma once' instead of include guards?

[EXT Mitch Curtis via Development]

> -Original Message-
> From: Development  On Behalf Of
> Volker Hilsheimer via Development
> Sent: Monday, 10 October 2022 5:55 PM
> To: development@qt-project.org
> Subject: [Development] Using '#pragma once' instead of include guards?
> 
> Hi,
> 
> 
> We are using `#pragma once` in a number of examples and tests in the Qt
> source tree, but I don’t think we have officially endorsed it in favour of
> explicit include guards.
> 
> #pragma once is “non-standard but widely supported” [1], with some
> caveats, e.g. when there are multiple header files with the same name
> (which each compiler then handles differently, as there is no standard).
> 
> From what I see, it should in practice be ok to use. But perhaps I’m missing
> something. Does anything speak against using ‘#pragma once’ in new files?

FYI, there was a discussion about this a few years back:

https://lists.qt-project.org/pipermail/development/2018-October/033726.html
 
> 
> Volker
> 
> [1] https://en.wikipedia.org/wiki/Pragma_once
> 
> ___
> Development mailing list
> Development@qt-project.org
> https://lists.qt-project.org/listinfo/development
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Requesting a repository for Qt Quick Effect Maker

[EXT Mitch Curtis]

I asked this back in April but there was no official answer at that stage: what 
will the license be?

From: Development  On Behalf Of Tomi 
Korpipää
Sent: Wednesday, 21 September 2022 6:56 PM
To: development@qt-project.org
Subject: Re: [Development] Requesting a repository for Qt Quick Effect Maker

Anyone to second this?

-Tomi

From: Volker Hilsheimer 
mailto:volker.hilshei...@qt.io>>
Sent: Wednesday, August 31, 2022 11:43
To: Tomi Korpipää mailto:tomi.korpi...@qt.io>>; 
development@qt-project.org 
mailto:development@qt-project.org>>
Subject: Re: [Development] Requesting a repository for Qt Quick Effect Maker

+1

Volker


> On 29 Aug 2022, at 12:15, Tomi Korpipää 
> mailto:tomi.korpi...@qt.io>> wrote:
>
> Hi,
>
> I'd like to request a new repository on codereview.qt-project.org.
>
> Name of the repository: qt/qtquickeffectmaker.git
>
> Name: Qt Quick Effect Maker
> Description: Qt Quick Effect Maker (QQEM) for creating custom shader effects.
> Responsible person: Kaj Grönholm
> Content: https://git.qt.io/kagronho/qt-quick-effect-maker/ master branch, 
> fresh without git history.
> No CI for now.
>
> Thank you,
>
> Tomi Korpipää
> Senior Manager, R
>
> The Qt Company
> Tutkijantie 4 C
> 90590, Oulu, Finland
> tomi.korpi...@qt.io
> +358 44 5312522
> http://qt.io
>
>
> The Future is Written with Qt
>
> ___
> Development mailing list
> Development@qt-project.org
> https://lists.qt-project.org/listinfo/development
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Reminder: Codereview scheduled maintenance break on Monday 6-Jun 7 am CET

[EXT Mitch Curtis]

> -Original Message-
> From: Development  On Behalf Of
> Thiago Macieira
> Sent: Wednesday, 13 July 2022 23:43 PM
> To: development@qt-project.org
> Subject: Re: [Development] Reminder: Codereview scheduled maintenance
> break on Monday 6-Jun 7 am CET
> 
> On Monday, 6 June 2022 09:02:07 PDT Thiago Macieira wrote:
> > On Monday, 6 June 2022 01:56:14 PDT Jukka Jokiniva wrote:
> > > Fix was found and deployed. Maintenance break is over for Gerrit.
> >
> > The previous Gerrit had the ability to add a short description of what
> > a patchset was, which helped reviewers to know what you'd changed
> > between patchsets. Gerrit still sets it if you edit the commit message.
> >
> > But I can't find the ability any more. Does anyone know where it went?
> 
> I still can't find this feature. I guess it was removed in this version of 
> Gerrit.

CCing gerrit-admin as I would also like this feature back if possible.

> --
> Thiago Macieira - thiago.macieira (AT) intel.com
>   Cloud Software Architect - Intel DCAI Cloud Engineering
> 
> 
> 
> ___
> Development mailing list
> Development@qt-project.org
> https://lists.qt-project.org/listinfo/development
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] "error: ran out of registers during register allocation" when building qlibrary.cpp on macOS 11.6 with Clang 13

[Mitch Curtis]

I just realised I never sent my reply to this; it was still a draft… well, at 
least I can add more info now. :)

> -Original Message-
> From: Development  On Behalf Of
> Thiago Macieira
> Sent: Monday, 22 November 2021 6:07 PM
> To: development@qt-project.org
> Subject: Re: [Development] "error: ran out of registers during register
> allocation" when building qlibrary.cpp on macOS 11.6 with Clang 13
>
> On Monday, 22 November 2021 05:47:04 PST Mitch Curtis wrote:
> > error: ran out of registers during register allocation
>
> Unless it's complaining about inline assembly, I don't see how this could be
> our fault. I don't see any inline assembly in qlibrary.cpp or in headers it
> includes, so my guess is it's a compiler bug.
>
> Register allocation failures are more common in debug builds.

Using a RelWithDebInfo build does indeed work around it.

I had some success building clang myself and then building Qt with that, but 
shortly after I started getting the following error (or others like it) when 
building Qt Quick apps, so I gave up and tried the release build workaround.

11:31:51: Running steps for project quick-cmake...
11:31:51: Starting: "/usr/local/Cellar/cmake/3.21.1/bin/cmake" --build 
/Users/mitch/dev/temp/quick-cmake-qt_dev_self_built_clang_debug_non_fw-Debug 
--target all
[1/1 3.5/sec] Linking CXX executable quick-cmake
FAILED: quick-cmake
: && /Users/mitch/dev/llvm-project/build/bin/clang-14 -fsanitize=address 
-fno-omit-frame-pointer -fno-optimize-sibling-calls -g -isysroot 
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX12.1.sdk
 -Wl,-search_paths_first -Wl,-headerpad_max_install_names  
CMakeFiles/quick-cmake.dir/quick-cmake_autogen/mocs_compilation.cpp.o 
CMakeFiles/quick-cmake.dir/main.cpp.o 
CMakeFiles/quick-cmake.dir/quick-cmake_autogen/EWIEGA46WW/qrc_qml.cpp.o -o 
quick-cmake  
-Wl,-rpath,/Users/mitch/dev/qt-dev-self-built-clang-debug-non-fw/qtbase/lib  
/Users/mitch/dev/qt-dev-self-built-clang-debug-non-fw/qtbase/lib/libQt6Quick_debug.6.3.0.dylib
  
/Users/mitch/dev/qt-dev-self-built-clang-debug-non-fw/qtbase/lib/libQt6QmlModels_debug.6.3.0.dylib
  
/Users/mitch/dev/qt-dev-self-built-clang-debug-non-fw/qtbase/lib/libQt6Qml_debug.6.3.0.dylib
  
/Users/mitch/dev/qt-dev-self-built-clang-debug-non-fw/qtbase/lib/libQt6Network_debug.6.3.0.dylib
  
/Users/mitch/dev/qt-dev-self-built-clang-debug-non-fw/qtbase/lib/libQt6OpenGL_debug.6.3.0.dylib
  
/Users/mitch/dev/qt-dev-self-built-clang-debug-non-fw/qtbase/lib/libQt6Gui_debug.6.3.0.dylib
  -framework  OpenGL  -framework  AGL  -framework AppKit  -framework ImageIO  
-framework Metal  
/Users/mitch/dev/qt-dev-self-built-clang-debug-non-fw/qtbase/lib/libQt6Core_debug.6.3.0.dylib
  -framework DiskArbitration  -framework IOKit && :
Undefined symbols for architecture x86_64:
"std::terminate()", referenced from:
  ___clang_call_terminate in qrc_qml.cpp.o
"operator delete(void*)", referenced from:
  
std::__1::enable_if<((QtPrivate::FunctionPointer::ArgumentCount) == 
(-(1))) && (!(std::is_convertible_v)), 
QMetaObject::Connection>::type QObject::connect(QtPrivate::FunctionPointer::Object const*, void (QQmlApplicationEngine::*)(QObject*, QUrl 
const&), QObject const*, main::$_0, Qt::ConnectionType) in main.cpp.o
  QtPrivate::QFunctorSlotObject, void>::impl(int, QtPrivate::QSlotObjectBase*, QObject*, void**, 
bool*) in main.cpp.o
"operator new(unsigned long)", referenced from:
  
std::__1::enable_if<((QtPrivate::FunctionPointer::ArgumentCount) == 
(-(1))) && (!(std::is_convertible_v)), 
QMetaObject::Connection>::type QObject::connect(QtPrivate::FunctionPointer::Object const*, void (QQmlApplicationEngine::*)(QObject*, QUrl 
const&), QObject const*, main::$_0, Qt::ConnectionType) in main.cpp.o
"___cxa_begin_catch", referenced from:
  ___clang_call_terminate in qrc_qml.cpp.o
"___gxx_personality_v0", referenced from:
  _main in main.cpp.o
  
std::__1::enable_if<((QtPrivate::FunctionPointer::ArgumentCount) == 
(-(1))) && (!(std::is_convertible_v)), 
QMetaObject::Connection>::type QObject::connect(QtPrivate::FunctionPointer::Object const*, void (QQmlApplicationEngine::*)(QObject*, QUrl 
const&), QObject const*, main::$_0, Qt::ConnectionType) in main.cpp.o
  QtPrivate::QFunctorSlotObject, void>::QFunctorSlotObject(main::$_0) in main.cpp.o
  Dwarf Exception Unwind Info (__eh_frame) in main.cpp.o
  (anonymous namespace)::initializer::~initializer() in qrc_qml.cpp.o
  Dwarf Exception Unwind Info (__eh_frame) in qrc_qml.cpp.o
ld: symbol(s) not found for architecture x86_64
clang-14: error: linker command failed with exit code 1 (use -v to see 
invocation)
ninja: build stopped: subcommand failed.
11:31:51: Th

Re: [Development] Importing a module build in creator

[Mitch Curtis]

This is the same situation I’m in. Would be nice if they were built when you 
hit run, but as a workaround I use Alt+B, Alt+R (from memory… I think that’s 
right):
https://codereview.qt-project.org/c/qt-creator/qt-creator/+/330075
That way you can do that key combination and then Ctrl+R to run the test.
On 11/1/2022, 13:25, "Development"  wrote:
Am 11.01.2022 um 12:39 schrieb Edward Welbourne:
> Arno Rehn (9 January 2022 15:59) wrote:
>> I'm skipping building the tests by default and would like
>> to build only a subset (the ones of the module I'm working on).
>> QtCreator doesn't seem to support EXCLUDE_FROM_ALL tests at all, so I
>> usually have to resort to the command line for that.
>
> I suspect combining
>
>-DQT_BUILD_TESTS=ON
>-DQT_BUILD_TESTS_BY_DEFAULT=OFF
>
> would help here.  CMake would know how to build the tests, but would
> only do so on request, so you could tell ninja to build $submodule/test
> (or indeed $subdirectory/test; see ninja -t targets for a full list) so
> as to only build the tests you care about, or build tst_component_check
> to (build and) run a specific test.

That's what I'm doing, actually. Works fine on he command line, like you
said.
But QtCreator does not know how to handle this case. You see all test
targets in QtCreator's list, but running them does not build them first.
So either you'll get a "file not found" error or maybe an outdated
executable.
You can only build them with a manual call to ninja.

Regards,
Arno

--
Arno Rehn
Tel +49 89 189 166 0
Fax +49 89 189 166 111
a.r...@menlosystems.com
www.menlosystems.com 

Menlo Systems GmbH
Bunsenstrasse 5, D-82152 Martinsried, Germany
Amtsgericht München HRB 138145
Geschäftsführung: Dr. Michael Mei, Dr. Ronald Holzwarth
USt.-IdNr. DE217772017, St.-Nr. 14316170324
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development


___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

[Development] "error: ran out of registers during register allocation" when building qlibrary.cpp on macOS 11.6 with Clang 13

[Mitch Curtis]

I'm running into the following error on macOS 11.6 with Clang 13:

[577/1574] Building CXX object 
src/corelib/CMakeFiles/Core.dir/plugin/qlibrary.cpp.o
FAILED: src/corelib/CMakeFiles/Core.dir/plugin/qlibrary.cpp.o
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/c++
 -DCore_EXPORTS -DGL_SILENCE_DEPRECATION -DPCRE2_CODE_UNIT_WIDTH=16 
-DQT_ASCII_CAST_WARNINGS -DQT_BUILDING_QT -DQT_BUILD_CORE_LIB 
-DQT_DEPRECATED_WARNINGS -DQT_DEPRECATED_WARNINGS_SINCE=0x06 
-DQT_DISABLE_DEPRECATED_BEFORE=0x05 -DQT_MOC_COMPAT -DQT_NO_CAST_TO_ASCII 
-DQT_NO_FOREACH -DQT_NO_NARROWING_CONVERSIONS_IN_CONNECT 
-DQT_NO_USING_NAMESPACE -DQT_STRICT_QLIST_ITERATORS -DQT_TYPESAFE_FLAGS 
-DQT_USE_QSTRINGBUILDER -D_LARGEFILE64_SOURCE -D_LARGEFILE_SOURCE 
-I/Users/mitch/dev/qt-dev-debug-non-fw/qtbase/src/corelib/Core_autogen/include 
-I/Users/mitch/dev/qt-dev-debug-non-fw/qtbase/include 
-I/Users/mitch/dev/qt-dev-debug-non-fw/qtbase/include/QtCore 
-I/Users/mitch/dev/qt-dev/qtbase/src/corelib 
-I/Users/mitch/dev/qt-dev-debug-non-fw/qtbase/src/corelib 
-I/Users/mitch/dev/qt-dev-debug-non-fw/qtbase/src/corelib/global 
-I/Users/mitch/dev/qt-dev-debug-non-fw/qtbase/src/corelib/kernel 
-I/Users/mitch/dev/qt-dev/qtbase/src/corelib/../3rdparty/tinycbor/src 
-I/Users/mitch/dev/qt-dev-debug-non-fw/qtbase/include/QtCore/6.3.0 
-I/Users/mitch/dev/qt-dev-debug-non-fw/qtbase/include/QtCore/6.3.0/QtCore 
-I/Users/mitch/dev/qt-dev/qtbase/src/corelib/../3rdparty/double-conversion/double-conversion
 -I/Users/mitch/dev/qt-dev/qtbase/src/corelib/../3rdparty/double-conversion 
-I/Users/mitch/dev/qt-dev/qtbase/src/corelib/../3rdparty/forkfd 
-I/Users/mitch/dev/qt-dev-debug-non-fw/qtbase/src/corelib/.rcc 
-I/Users/mitch/dev/qt-dev-debug-non-fw/qtbase/mkspecs/macx-clang 
-I/Users/mitch/dev/qt-dev/qtbase/src/3rdparty/pcre2/src -fsanitize=address 
-fno-omit-frame-pointer -fno-optimize-sibling-calls -g -isysroot 
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX12.0.sdk
 -mmacosx-version-min=10.14 -fPIC -fvisibility=hidden 
-fvisibility-inlines-hidden -Wall -Wextra -Werror "-Wno-error=#warnings" 
-Wno-error=deprecated-declarations -fapplication-extension -std=c++17 
-Winvalid-pch -Xclang -include-pch -Xclang 
/Users/mitch/dev/qt-dev-debug-non-fw/qtbase/src/corelib/CMakeFiles/Core.dir/cmake_pch.hxx.pch
 -Xclang -include -Xclang 
/Users/mitch/dev/qt-dev-debug-non-fw/qtbase/src/corelib/CMakeFiles/Core.dir/cmake_pch.hxx
 -MD -MT src/corelib/CMakeFiles/Core.dir/plugin/qlibrary.cpp.o -MF 
src/corelib/CMakeFiles/Core.dir/plugin/qlibrary.cpp.o.d -o 
src/corelib/CMakeFiles/Core.dir/plugin/qlibrary.cpp.o -c 
/Users/mitch/dev/qt-dev/qtbase/src/corelib/plugin/qlibrary.cpp
error: ran out of registers during register allocation

Compiler version:

Mitchs-MacBook-Pro:dev mitch$ 
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/c++
 --version
Apple clang version 13.0.0 (clang-1300.0.29.3)
Target: x86_64-apple-darwin20.6.0
Thread model: posix
InstalledDir: 
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin

Configuring Qt with these options:

-DCMAKE_BUILD_TYPE=Debug -DFEATURE_framework=OFF -DFEATURE_developer_build=ON 
-DQT_BUILD_TESTS=ON -DQT_BUILD_TESTS_BY_DEFAULT=OFF -DQT_BUILD_EXAMPLES=ON 
-DQT_BUILD_EXAMPLES_BY_DEFAULT=OFF -DFEATURE_sanitize_address=ON

A colleague has run into it as well, but for them it went away when upgrading 
to Clang 13.

Before I report it as a bug to llvm, I thought I'd check if anyone else has run 
into this or has any ideas as to what could be causing it. CCing Thiago since 
he touched that code last. :)

Cheers.
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Proposing to move deploy tools to qtbase

[Mitch Curtis]

> -Original Message-
> From: Development  On Behalf Of
> Ulf Hermann
> Sent: Tuesday, 16 November 2021 3:23 PM
> To: development@qt-project.org
> Subject: Re: [Development] Proposing to move deploy tools to qtbase
> 
> > I’m working on adding new CMake APIs for install support for Qt 6.3.
> > As part of that, there will be conveniences for invoking the
> > appropriate xxxdeployqt tool where available. At the moment,
> > macdeployqt and windeployqt live in qttools, whereas androiddeployqt
> lives in qtbase.
> > I’d like to propose moving macdeployqt and windeployqt to qtbase as
> > well.
> 
> +1
> 
> Installation and deployment has to be part of the core functionality of Qt's
> build system, not some afterthought.

+1

> ___
> Development mailing list
> Development@qt-project.org
> https://lists.qt-project.org/listinfo/development
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Jira and issues left "In Progress"

[Mitch Curtis]

> -Original Message-
> From: Development  On Behalf Of
> Alex Blasche
> Sent: Thursday, 28 October 2021 3:45 PM
> To: development@qt-project.org
> Subject: [Development] Jira and issues left "In Progress"
> 
> Hi,
> 
> We have a growing problem with Jira issues forgotten in the "In Progress"
> state. For the 10 most important  Jira projects we currently have 600+ issues
> being stuck in the mentioned state. Since we recognize "In Progress" as a
> blocking state (not open for take over by other engineers), I believe we
> should keep the numbers small and mostly constraint to limited time frames.
> 
> By historical standard this is still much better than past times and I 
> attribute
> most of it to the "Fixed" git tag which automatically closes Jira issues.
> Nevertheless of those "In Progress" issues about 170+ have not been
> touched (or were forgotten) for more than 3 months.
> 
> I would like to do something about this by adding some automation similar to
> the "Need more Info" automation. Those forgotten issues are likely not in
> progress anymore or were fixed a long time ago. I believe returning them to
> the "Open" state would trigger a re-evaluation by assignees (you). You either
> close them as already done or keep them in "Open" as you recognize them
> as not being done yet.
> 
> My proposal would be to return every "In Progress" issue to "Open" if there
> was no change for 3 month.
> 
> I'd appreciate your feedback.

Sounds good to me. I imagine the majority of those are just forgotten, like you 
said.
 
> --
> Alex
> 
> ___
> Development mailing list
> Development@qt-project.org
> https://lists.qt-project.org/listinfo/development
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Nominating Oliver Eftevaag as Approver

[Mitch Curtis]

+1

From: Development  On Behalf Of Paul Wicking
Sent: Wednesday, 27 October 2021 6:25 AM
To: development@qt-project.org
Subject: [Development] Nominating Oliver Eftevaag as Approver

Hi all,

I'd like to nominate Oliver Eftevaag as an approver.


Oliver has been working as a software engineer for the Qt Company for almost a 
year now and has made a fair number of contributions to Qt [0]. He also 
participates actively in reviews [1]. He's curious and passionate about 
learning new things, and happy to share his knowledge with his colleagues.

I trust he'll use the approver rights responsibly.

Disclaimer: we sporadically meet for lunch or by the coffee machine.
//! Paul

[0] - 
https://codereview.qt-project.org/q/owner:oliver.eftevaag%2540qt.io
[1] - 
https://codereview.qt-project.org/q/reviewer:oliver.eftevaag%2540qt.io
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

[Development] qtquickcalendar's dev branch is now CMake-only

[Mitch Curtis]

Hi.

As part of porting qtquickcalendar to Qt 6 [1], and as done for "proper" Qt 
modules, CMake will now be the only supported build system with which to build 
the dev branch of the module. It is still possible to use the dev branch of 
qtquickcalendar in your qmake-based projects, and the 5.15 branch continues to 
support qmake.

Cheers.

[1] https://bugreports.qt.io/browse/QTEXT-8
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Temporarily preventing changes being staged in the dev branch of qtquickcontrols2

[Mitch Curtis]

Thanks for bringing this up. It's a good point I hadn't thought about. I wonder 
if it's too late to do the merge in 6.2 instead... that would save a lot of 
hassle in the long term.

On 23/7/21, 4:02 pm, "Alexandru Croitor"  wrote:

Hi

> On 20/7/21, 2:10 pm, "Development on behalf of Mitch Curtis" 
 wrote:
> 
>Hi.
> 
>I'd like to request that we temporarily prevent changes from being 
staged in the dev branch of qtquickcontrols2 in preparation for merging it into 
qtdeclarative, as otherwise changes could be missed in the merge.
> 
>I'm sending this to both the release team and the development mailing 
list as a heads up.
> 

As i understand the current intention is to merge qtquickcontrols2 dev 
branch into qtdeclarative dev branch, which is Qt 6.3 at the moment.

That leaves qtuickcontrols2 and qtdeclarative separate in 6.2 LTS branch.

The current cherry-pick bot can't handle cross-repo cherry-picks.

Which means any qqc2 code changes in qtdeclarative repo 6.3, 6.4, 6.5, 
branch will have to be replicated with a more manual process to 6.2 branch of 
qtquickcontrols2 repo, because 6.2 is LTS.

Can these cherry-picks be done automatically somehow? Is the manual process 
the one we want / are stuck with?

Is this enough justification to do the qqc2 -> qtdeclarative merge in 6.2 
branch instead?

___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Temporarily preventing changes being staged in the dev branch of qtquickcontrols2

[Mitch Curtis]

CCing qt.relea...@qt.io since apparently the other address is no longer in use.

On 20/7/21, 2:10 pm, "Development on behalf of Mitch Curtis" 
 wrote:

Hi.

I'd like to request that we temporarily prevent changes from being staged 
in the dev branch of qtquickcontrols2 in preparation for merging it into 
qtdeclarative, as otherwise changes could be missed in the merge.

I'm sending this to both the release team and the development mailing list 
as a heads up.

Cheers.

___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development


___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

[Development] Temporarily preventing changes being staged in the dev branch of qtquickcontrols2

[Mitch Curtis]

Hi.

I'd like to request that we temporarily prevent changes from being staged in 
the dev branch of qtquickcontrols2 in preparation for merging it into 
qtdeclarative, as otherwise changes could be missed in the merge.

I'm sending this to both the release team and the development mailing list as a 
heads up.

Cheers.

___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Mirror IRC channels on KDE's Matrix Instance

[Mitch Curtis]

Hi Cristián, thanks for setting it up.

I've never used Matrix before - how do I sign in using my KDE identity (I'm 
using the Element client if it makes a difference)? I'm guessing I need to set 
the homeserver to some KDE server?

Cheers.

> -Original Message-
> From: Development  On Behalf Of
> Cristián Maureira-Fredes
> Sent: Tuesday, 13 July 2021 10:59 AM
> To: development@qt-project.org
> Subject: Re: [Development] Mirror IRC channels on KDE's Matrix Instance
> 
> Hello,
> 
> Just to finalize this thread,
> as https://phabricator.kde.org/T14673 states, the following channels are now
> bridged:
> 
> 
> #qt:kde.org
> #qt-cmake:kde.org
> #qt-creator:kde.org
> #qt-cs:kde.org
> #qt-labs:kde.org
> #qt-pyside:kde.org
> #qt-quick:kde.org
> #qt-releases:kde.org
> #qt-webengine:kde.org (irc: #qtwebengine)
> 
> 
> To share the links to the channels
> you can use the following:
> 
> https://go.kde.org/matrix/#/#qt-pyside:kde.org
> 
> changing 'qt-pyside' for the channel you want to share ;)
> 
> A big thanks to the KDE folks that help the process!
> 
> Cheers
> 
> 
> On 7/6/21 12:37 PM, Cristián Maureira-Fredes wrote:
> > Hello,
> >
> > Since nobody refused to this decision, will contact the folks at KDE
> > to start the process of mirroring the IRC channels into KDE's Matrix
> > instance.
> >
> > Thanks everyone!
> >
> > Cheers
> >
> > On 6/28/21 12:51 PM, Cristián Maureira-Fredes wrote:
> >> Hello everyone,
> >>
> >> Context
> >> ---
> >>
> >> After the "Improve the contributor experience" session at the past Qt
> >> Contributors Summit, many ideas came out related to an overall
> >> improvement to the contribution experience, mainly focused on new
> >> people joining the Qt Project.
> >>
> >> One of the topics was Communication,
> >> from which we (qt project people) discussed together with some KDE
> >> folks and agreed that bringing the Qt and KDE communities closer was
> >> a good idea, mainly based on the good experience KDE has currently on
> >> the platform.
> >>
> >> We have a good opportunity to do this via a bridge from our newly
> >> created Libera.chat IRC channels, to KDE's Matrix Instance.
> >>
> >> During the QtCS,
> >> we tried this out, and mirrored the #qt-cs IRC channel to Matrix:
> >> https://go.kde.org/matrix/#/#qt-cs:kde.org
> >> and according to the people that participated in the session the
> >> experience was nice, and it might be worth to bridge all the other
> >> #qt-* channels on IRC.
> >>
> >> Read more about Matrix: https://matrix.org/ Read more about KDE's
> >> Matrix Instance: https://community.kde.org/Matrix
> >>
> >>
> >> Implications
> >> 
> >>
> >> If you prefer IRC, it's totally fine, this change would only imply
> >> that you will get more people on IRC to interact with.
> >>
> >> If you want to move to Matrix completely, this change will enable you
> >> to stay in touch with folks on the IRC channels.
> >>
> >> Permissions work different on Matrix than IRC, but with the current
> >> list of moderators in the #qt- domain we can easily assign
> >> permissions to people on the Matrix channels accordingly.
> >>
> >> Let's keep the discussion of other communication platforms outside
> >> this thread, while they might be valid, it's out of the scope of this
> >> proposal.
> >>
> >> Question
> >> 
> >>
> >> I would like to ask the Qt Project if you agree or disagree with the
> >> proposal to mirror all the #qt-* channels from Libera.chat to KDE's
> >> Matrix Instance.
> >>
> >> If we don't have unresolved disagreements, I'd say we can proceed
> >> with the mirroring Monday next week, but if there are concerns, I
> >> would prefer to address them first.
> >>
> >> Cheers
> >>
> >>
> >>
> >
> 
> --
> Dr. Cristián Maureira-Fredes
> R Manager
> 
> The Qt Company GmbH
> Erich-Thilo-Str. 10
> D-12489 Berlin
> 
> Geschäftsführer: Mika Pälsi,
> Juha Varelius, Jouni Lintunen
> Sitz der Gesellschaft: Berlin,
> Registergericht: Amtsgericht
> Charlottenburg, HRB 144331 B
> ___
> Development mailing list
> Development@qt-project.org
> https://lists.qt-project.org/listinfo/development
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Merging qtquickcontrols2 into qtdeclarative

[Mitch Curtis]

Thanks Tor Arne. Can you elaborate a bit on the commands used for a prefixed 
subtree merge? Or point to a page that explains it?

From: Tor Arne Vestbø 
Sent: Monday, 12 July 2021 4:17 PM
To: Mitch Curtis 
Cc: development@qt-project.org
Subject: Re: [Development] Merging qtquickcontrols2 into qtdeclarative

One way to do this is with a prefixed subtree merge without squashing the 
history of controls2.

What ossi (?) referred to was using git replace to inject the history of 
controls, but I’m not sure how that would look so perhaps he can outline that 
approach.

Cheers,
Tor Arne


On 12 Jul 2021, at 14:42, Mitch Curtis 
mailto:mitch.cur...@qt.io>> wrote:

Hi.

The consensus from the contributor's summit session regarding 
https://bugreports.qt.io/browse/QTBUG-79454 was that qtquickcontrols2 should be 
merged into qtdeclarative:

https://wiki.qt.io/QtCS2021_-_Testing_upstream_changes_with_downstream_modules#Move_specific_modules_into_the_repository_of_the_module_they_depend_on

In terms of Git, what is the best way to proceed with this? Which commands 
should be used? Any specific things to be aware of? For example, one note made 
during the session was:

“Graft history in, don't merge it.”

Cheers.
___
Development mailing list
Development@qt-project.org<mailto:Development@qt-project.org>
https://lists.qt-project.org/listinfo/development

___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

[Development] Merging qtquickcontrols2 into qtdeclarative

[Mitch Curtis]

Hi.

The consensus from the contributor's summit session regarding 
https://bugreports.qt.io/browse/QTBUG-79454 was that qtquickcontrols2 should be 
merged into qtdeclarative:

https://wiki.qt.io/QtCS2021_-_Testing_upstream_changes_with_downstream_modules#Move_specific_modules_into_the_repository_of_the_module_they_depend_on

In terms of Git, what is the best way to proceed with this? Which commands 
should be used? Any specific things to be aware of? For example, one note made 
during the session was:

"Graft history in, don't merge it."

Cheers.
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Version-controlling the SVGs of built-in icons

[Mitch Curtis]

> -Original Message-
> From: Development  On Behalf Of
> Edward Welbourne
> Sent: Friday, 18 June 2021 1:28 PM
> To: Volker Hilsheimer 
> Cc: development@qt-project.org
> Subject: Re: [Development] Version-controlling the SVGs of built-in icons
> 
> Volker Hilsheimer (18 June 2021 11:19) wrote:
> > The majority of time spent on QTBUG-38776 is chasing down the various
> > SVGs from which it’s then trivial to generate PNGs in different
> > resolutions.
> 
> The very fact that we're generating PNGs at different resolutions from SVGs,
> when decent support for SVG would make that mostly redundant, says we
> should be fixing our SVG support (and making it efficient enough to make it
> practical to use it).
> 
>   Eddy, who illustrates geometry essays with hand-written inline SVGs.

I agree with this. If the SVG is not too complex it should be efficient enough 
to just use them instead since they should only be rendered once at startup.

I think I remember Gunnar saying that Jolla did this for their icons.

> ___
> Development mailing list
> Development@qt-project.org
> https://lists.qt-project.org/listinfo/development
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Version-controlling the SVGs of built-in icons

[Mitch Curtis]

For completeness since Alessandro mentioned exporting: for qtquickcontrols2, 
I've been using the same Inkscape extension that we document for exporting 
9-patch images, since it also works with regular images:

https://doc.qt.io/qt-5/qtquickcontrols2-imagine.html#exporting-9-patch-images

From: Development  On Behalf Of Alessandro 
Portale
Sent: Friday, 18 June 2021 12:00 PM
To: Volker Hilsheimer ; development@qt-project.org
Subject: Re: [Development] Version-controlling the SVGs of built-in icons

Very interesting topic, indeed. Thanks.

In order to support High-DPI and themed looks in Qt Creator, we switched from a 
decade-old collection of PNGs with unknown origins inconsistent looks to having 
everything in an SVG document under source control:
  
https://github.com/qt-creator/qt-creator/blob/master/src/tools/icons/qtcreatoricons.svg
That SVG is considered "proper source code" and updates happen in the same 
commit along with the resulting @1x/@2x PNGs, and the C++ code that integrates 
the icon.

There is a little python script that automates exporting and optimizing the 
PNGs. 
https://github.com/qt-creator/qt-creator/blob/master/src/tools/icons/export.py
Gimmick: The PNGs are generated in the position of the source tree where they 
will be added to the repository.

The stuff in Qt Creator is a bit self-baked regarding the namings, etc. I would 
not mind having a unified approach across the repositories.

Br,
Alessandro

Von: Development 
mailto:development-boun...@qt-project.org>> 
im Auftrag von Volker Hilsheimer 
mailto:volker.hilshei...@qt.io>>
Gesendet: Freitag, 18. Juni 2021 11:19
An: development@qt-project.org 
mailto:development@qt-project.org>>
Betreff: [Development] Version-controlling the SVGs of built-in icons

Hi,


The majority of time spent on QTBUG-38776 is chasing down the various SVGs from 
which it's then trivial to generate PNGs in different resolutions.

Which makes me think that we should have those SVGs version controlled 
somewhere. That "somewhere" can either be the respective module repositories, 
or a dedicated repo with all SVGs. I'm in favour of the latter option, mostly 
because it makes it easier for the digital artists who create and maintain 
those SVGs to do that without having to clone the world and navigate a rather 
complex repo and file system structure. But there are pros and cons to either 
approach.

Since that might become the place for scalable versions of all icons, including 
those for Qt Creator and Qt Design Studio, having such a repo under the "qt" 
namespace seems odd. But I don't see any obviously better option either.

Any opinions?


Volker


___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Version-controlling the SVGs of built-in icons

[Mitch Curtis]

> -Original Message-
> From: Development  On Behalf Of
> Volker Hilsheimer
> Sent: Friday, 18 June 2021 11:20 AM
> To: development@qt-project.org
> Subject: [Development] Version-controlling the SVGs of built-in icons
> 
> Hi,
> 
> 
> The majority of time spent on QTBUG-38776 is chasing down the various
> SVGs from which it’s then trivial to generate PNGs in different resolutions.
> 
> Which makes me think that we should have those SVGs version controlled
> somewhere. That “somewhere” can either be the respective module
> repositories, or a dedicated repo with all SVGs. I’m in favour of the latter
> option, mostly because it makes it easier for the digital artists who create 
> and
> maintain those SVGs to do that without having to clone the world and
> navigate a rather complex repo and file system structure. But there are pros
> and cons to either approach.
> 
> Since that might become the place for scalable versions of all icons, 
> including
> those for Qt Creator and Qt Design Studio, having such a repo under the “qt"
> namespace seems odd. But I don’t see any obviously better option either.
> 
> Any opinions?

Hi Volker.

I've been adding source SVGs for PNG icons in the module itself in the case of 
qtquickcontrols2:

mitch@mitch-ubuntu-20:~/dev/qt-dev/qtquickcontrols2$ find . -name "*svg"
./tests/auto/qquickiconimage/icons/testtheme/appointment-new.svg
./examples/quickcontrols2/wearable/qml/Settings/images/theme.svg
./examples/quickcontrols2/wearable/qml/Settings/images/demo-mode.svg
./examples/quickcontrols2/imagine/automotive/icons/automotive/icons.svg
./examples/quickcontrols2/imagine/musicplayer/icons/musicplayer/icons.svg
./src/quickdialogs2/quickdialogs2quickimpl/images/up-icon-thick-square.svg
./src/quickdialogs2/quickdialogs2quickimpl/images/crumb-separator-icon-round.svg
./src/quickdialogs2/quickdialogs2quickimpl/images/file-icon-round.svg
./src/quickdialogs2/quickdialogs2quickimpl/images/up-icon-square.svg
./src/quickdialogs2/quickdialogs2quickimpl/images/folder-icon-square.svg
./src/quickdialogs2/quickdialogs2quickimpl/images/file-icon-square.svg
./src/quickdialogs2/quickdialogs2quickimpl/images/up-icon-round.svg
./src/quickdialogs2/quickdialogs2quickimpl/images/imagine/filedialogdelegate-background.svg
./src/quickdialogs2/quickdialogs2quickimpl/images/crumb-separator-icon-square.svg
./src/quickdialogs2/quickdialogs2quickimpl/images/folder-icon-round.svg
./src/quickcontrols2/material/images/drop-indicator.svg
./src/quickcontrols2/material/images/arrow-indicator.svg
./src/quickcontrols2/doc/images/qtquickcontrols2-control.svg
./src/quickcontrols2/doc/images/qtquickcontrols2-popup.svg
./src/quickcontrols2/fusion/images/arrow.svg
./src/quickcontrols2/fusion/images/progressmask.svg
./src/quickcontrols2/fusion/images/checkmark.svg

I would vote for keeping the icons in the modules where they're used. Ideally 
that would be next to the generated images, as that makes it easy to find them 
and is an easy convention to follow.

I'm not sure how many designers use Git to be honest. Most of my interactions 
with designers have involved exchanging files through email/chat/file hosting. 
If they are using Git though, I wouldn't think it would matter too much where 
the files are, because that still needs to be communicated up front before the 
work begins.

Cheers.

> 
> Volker
> 
> 
> ___
> Development mailing list
> Development@qt-project.org
> https://lists.qt-project.org/listinfo/development
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Solutions for ensuring that changes in upstream modules are tested with downstream modules before merging

[Mitch Curtis]

From: Development  On Behalf Of Shawn 
Rutledge
Sent: Tuesday, 15 June 2021 10:57 PM
To: development@qt-project.org
Subject: Re: [Development] Solutions for ensuring that changes in upstream 
modules are tested with downstream modules before merging


On 2021 Jun 7, at 15:30, Mitch Curtis 
mailto:mitch.cur...@qt.io>> wrote:

Some I can think of:

- Slower git operations.
- Slower build times for qtdeclarative devs. You can use e.g. ninja targets, 
but you would have to do this every time you build. Ideally we’d add a 
configure option for this, like -no-gui in qtbase, so that they don’t need to 
build qtquickcontrols2.

FWIW, I’m routinely building all of Qt together (the modules that I have 
anyway) with cmake and ninja.  (It’s around 15k steps, building all autotests 
but not examples.  A Zen3 processor and ccache make it bearable.  Before that, 
I was using icecc.)  So the cases where I have broken something in controls by 
making a change in qtdeclarative are usually only test failures (behavior 
changes), not build failures, right?  (Or at least not build failures that I 
didn’t know about.)  I never run all autotests in all modules locally, because 
it takes too long.  Even running all tests in qtdeclarative takes too long, 
except when the change is so invasive that I know I really need to.  If I’m 
worried about a specific change breaking controls, I run those tests.  (The 
script to run tests in xephyr is handy, so I can keep using the computer while 
they are running.)

“only” test failures, yes. :D Build failures would be preferable because 
they’re more obvious and easily fixed.

I rarely run all tests for a module when making a change. I’d never get any 
work done if I did.

- Creator would probably be quite a bit slower to work with having both of 
these in one project.

Qtdeclarative is already a rather big module.  And Creator is slow, for sure.  
It’s been a couple of years since I could use it at all on my older laptops 
without enough memory.


This why I like the idea of just running qtquickcontrols2 tests for each 
qtdeclarative change: it doesn’t waste developer time (and again, CI 
integrations don’t count since they shouldn’t be wasting developer time).

Hopefully that will work, yeah.


Though then you do lose the ability to use controls in examples, which does 
seem like a huge loss.

It depends whether we care about being able to automatically test examples 
without building controls first, right?  Otherwise I thought the existing 
advice lately is to go ahead and use controls in examples?

I’m not sure to be honest. I know the consensus is that we should use controls 
in examples but I don’t know how that’s supposed to work in terms of module 
dependencies.
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Solutions for ensuring that changes in upstream modules are tested with downstream modules before merging

[Mitch Curtis]

Some I can think of:

- Slower git operations.
- Slower build times for qtdeclarative devs. You can use e.g. ninja targets, 
but you would have to do this every time you build. Ideally we’d add a 
configure option for this, like -no-gui in qtbase, so that they don’t need to 
build qtquickcontrols2.
- Creator would probably be quite a bit slower to work with having both of 
these in one project.

This why I like the idea of just running qtquickcontrols2 tests for each 
qtdeclarative change: it doesn’t waste developer time (and again, CI 
integrations don’t count since they shouldn’t be wasting developer time). 
Though then you do lose the ability to use controls in examples, which does 
seem like a huge loss.

From: David Skoland 
Sent: Monday, 7 June 2021 1:30 PM
To: Mitch Curtis 
Cc: Volker Hilsheimer ; development@qt-project.org
Subject: Re: [Development] Solutions for ensuring that changes in upstream 
modules are tested with downstream modules before merging

I would really be interested if there are other leaf modules that have this 
issue. If it's just qtquickcontrols2 then perhaps merging into qtdeclarative 
would be the easiest solution after all.

Taking a quick look through the qtquickcontrols2’s changes, it seems a large 
number(half?) of them are just Qt Submodule Update Bot and Qt Cherry-pick Bot 
changes. I would think that merging qqc2 into qtdeclarative could make things 
simpler, but I would like to hear if anyone knows about any potential downsides 
this may have. Is it a realistic move to make at this point?

On 7 Jun 2021, at 10:22, Mitch Curtis 
mailto:mitch.cur...@qt.io>> wrote:

-Original Message-
From: Volker Hilsheimer 
mailto:volker.hilshei...@qt.io>>
Sent: Friday, 4 June 2021 4:51 PM
To: Mitch Curtis mailto:mitch.cur...@qt.io>>
Cc: development@qt-project.org<mailto:development@qt-project.org>
Subject: Re: [Development] Solutions for ensuring that changes in upstream
modules are tested with downstream modules before merging


On 4 Jun 2021, at 16:10, Mitch Curtis 
mailto:mitch.cur...@qt.io>> wrote:


-Original Message-
From: Volker Hilsheimer 
mailto:volker.hilshei...@qt.io>>
Sent: Friday, 4 June 2021 2:45 PM
To: Mitch Curtis mailto:mitch.cur...@qt.io>>
Cc: development@qt-project.org<mailto:development@qt-project.org>
Subject: Re: [Development] Solutions for ensuring that changes in
upstream modules are tested with downstream modules before merging


On 4 Jun 2021, at 13:56, Mitch Curtis 
mailto:mitch.cur...@qt.io>> wrote:

Hi.

A common problem I see is that a change in say qtbase or
qtdeclarative can
cause test failures in modules that depend on them after that change
is merged. As a result, dependency updates for the downstream modules
can be blocked, requiring the module maintainer to look into the
failure, only to discover that it is caused by an upstream module.
This causes a lot of time and effort to be diverted away from regular
work. Both upstream and downstream developers would benefit from
having more immediate CI feedback on these kinds of changes.


https://bugreports.qt.io/browse/QTBUG-79454 was created to track
this
problem. So far the ideas suggested have been:


- Run tests of dependent modules when testing a change, in addition
to
the regular tests for that module

- Merge repositories of more tightly coupled modules (e.g. move
qtquickcontrols2 into qtdeclarative)


It would be beneficial to discuss the advantages and disadvantages
of
these and other solutions so that we can address this problem.


Cheers.


Excellent topic for the upcoming Qt Contributors Summit, Mitch, great
if you can add it to the list of topics:

https://wiki.qt.io/Qt_Contributors_Summit_2021_-_Program

Which doesn’t mean that we shouldn't start the discussion on the
list, and maybe we can then conclude it at the summit.


Cheers,
Volker

OK, added it to the list.

Thanks.


As for the topic:

I do think that we have cases where too many modules are lumped into a
single repo, and cases where we have too much granularity.

For the former: I see no immediate reason why QtNetwork needs to be in
qtbase (network tests failing is a major cause of unrelated integrations
failing), or why the Qt Positioning module needs to be in qtlocation.

For the latter: Qt Quick Controls 2 might be better off sharing a commit
history with QtQuick

However, while we can make adjustments, I also think that there’s no
perfect solution. It’s always a tradeoff between speed and autonomy on the
one, and integrity across dependencies on the other hand.

I agree.


Running more tests is a similar tradeoff, and I don’t think blocking an
integration into e.g. qtbase because it breaks a leaf module is a good solution
to the problem. We should aim for fast feedback, and short meantime to
recover such breakages, and making CI runs take even longer helps with
neither. In particular if we then can’t make any such changes even though a
follow up change in a l

Re: [Development] Solutions for ensuring that changes in upstream modules are tested with downstream modules before merging

[Mitch Curtis]

Good point. I guess you implied this in "all the relevant examples", but just 
to spell it out: this would also allow other leaf repositories that currently 
depend on qtdeclarative.git, but might not want to depend on 
qtquickcontrols2.git for whatever reason, to use controls in their examples.

From: Tuukka Turunen 
Sent: Friday, 4 June 2021 9:35 PM
To: Volker Hilsheimer ; Mitch Curtis 

Cc: development@qt-project.org
Subject: Re: [Development] Solutions for ensuring that changes in upstream 
modules are tested with downstream modules before merging


Hi,

Having the controls within declarative and also using the controls more in all 
the relevant examples would be beneficial for the users. So I think this might 
be one dependency we could add, not only for testing.

Yours,

Tuukka


Lähettäjä: Development 
mailto:development-boun...@qt-project.org>> 
käyttäjän Volker Hilsheimer 
mailto:volker.hilshei...@qt.io>> puolesta
Lähetetty: perjantaina, kesäkuuta 4, 2021 5:55 ip.
Vastaanottaja: Mitch Curtis
Kopio: development@qt-project.org<mailto:development@qt-project.org>
Aihe: Re: [Development] Solutions for ensuring that changes in upstream modules 
are tested with downstream modules before merging

> On 4 Jun 2021, at 16:10, Mitch Curtis 
> mailto:mitch.cur...@qt.io>> wrote:
>
>> -Original Message-
>> From: Volker Hilsheimer 
>> mailto:volker.hilshei...@qt.io>>
>> Sent: Friday, 4 June 2021 2:45 PM
>> To: Mitch Curtis mailto:mitch.cur...@qt.io>>
>> Cc: development@qt-project.org<mailto:development@qt-project.org>
>> Subject: Re: [Development] Solutions for ensuring that changes in upstream
>> modules are tested with downstream modules before merging
>>
>>> On 4 Jun 2021, at 13:56, Mitch Curtis 
>>> mailto:mitch.cur...@qt.io>> wrote:
>>>
>>> Hi.
>>>
>>> A common problem I see is that a change in say qtbase or qtdeclarative can
>> cause test failures in modules that depend on them after that change is
>> merged. As a result, dependency updates for the downstream modules can
>> be blocked, requiring the module maintainer to look into the failure, only to
>> discover that it is caused by an upstream module. This causes a lot of time
>> and effort to be diverted away from regular work. Both upstream and
>> downstream developers would benefit from having more immediate CI
>> feedback on these kinds of changes.
>>>
>>> https://bugreports.qt.io/browse/QTBUG-79454 was created to track this
>> problem. So far the ideas suggested have been:
>>>
>>> - Run tests of dependent modules when testing a change, in addition to
>> the regular tests for that module
>>> - Merge repositories of more tightly coupled modules (e.g. move
>> qtquickcontrols2 into qtdeclarative)
>>>
>>> It would be beneficial to discuss the advantages and disadvantages of
>> these and other solutions so that we can address this problem.
>>>
>>> Cheers.
>>
>>
>> Excellent topic for the upcoming Qt Contributors Summit, Mitch, great if you
>> can add it to the list of topics:
>>
>> https://wiki.qt.io/Qt_Contributors_Summit_2021_-_Program
>>
>> Which doesn't mean that we shouldn't start the discussion on the list, and
>> maybe we can then conclude it at the summit.
>>
>>
>> Cheers,
>> Volker
>
> OK, added it to the list.
>

Thanks.


As for the topic:

I do think that we have cases where too many modules are lumped into a single 
repo, and cases where we have too much granularity.

For the former: I see no immediate reason why QtNetwork needs to be in qtbase 
(network tests failing is a major cause of unrelated integrations failing), or 
why the Qt Positioning module needs to be in qtlocation.

For the latter: Qt Quick Controls 2 might be better off sharing a commit 
history with QtQuick

However, while we can make adjustments, I also think that there's no perfect 
solution. It's always a tradeoff between speed and autonomy on the one, and 
integrity across dependencies on the other hand.


Running more tests is a similar tradeoff, and I don't think blocking an 
integration into e.g. qtbase because it breaks a leaf module is a good solution 
to the problem. We should aim for fast feedback, and short meantime to recover 
such breakages, and making CI runs take even longer helps with neither. In 
particular if we then can't make any such changes even though a follow up 
change in a leaf module is already available and just needs to wait for the 
dependency update. Then we are in a deadlock, unless we keep the code in qtbase 
working for both versions of e.g. qtdeclarative, which is not always practical.


The problem

Re: [Development] Solutions for ensuring that changes in upstream modules are tested with downstream modules before merging

[Mitch Curtis]

> -Original Message-
> From: Volker Hilsheimer 
> Sent: Friday, 4 June 2021 4:51 PM
> To: Mitch Curtis 
> Cc: development@qt-project.org
> Subject: Re: [Development] Solutions for ensuring that changes in upstream
> modules are tested with downstream modules before merging
> 
> > On 4 Jun 2021, at 16:10, Mitch Curtis  wrote:
> >
> >> -Original Message-
> >> From: Volker Hilsheimer 
> >> Sent: Friday, 4 June 2021 2:45 PM
> >> To: Mitch Curtis 
> >> Cc: development@qt-project.org
> >> Subject: Re: [Development] Solutions for ensuring that changes in
> >> upstream modules are tested with downstream modules before merging
> >>
> >>> On 4 Jun 2021, at 13:56, Mitch Curtis  wrote:
> >>>
> >>> Hi.
> >>>
> >>> A common problem I see is that a change in say qtbase or
> >>> qtdeclarative can
> >> cause test failures in modules that depend on them after that change
> >> is merged. As a result, dependency updates for the downstream modules
> >> can be blocked, requiring the module maintainer to look into the
> >> failure, only to discover that it is caused by an upstream module.
> >> This causes a lot of time and effort to be diverted away from regular
> >> work. Both upstream and downstream developers would benefit from
> >> having more immediate CI feedback on these kinds of changes.
> >>>
> >>> https://bugreports.qt.io/browse/QTBUG-79454 was created to track
> >>> this
> >> problem. So far the ideas suggested have been:
> >>>
> >>> - Run tests of dependent modules when testing a change, in addition
> >>> to
> >> the regular tests for that module
> >>> - Merge repositories of more tightly coupled modules (e.g. move
> >> qtquickcontrols2 into qtdeclarative)
> >>>
> >>> It would be beneficial to discuss the advantages and disadvantages
> >>> of
> >> these and other solutions so that we can address this problem.
> >>>
> >>> Cheers.
> >>
> >>
> >> Excellent topic for the upcoming Qt Contributors Summit, Mitch, great
> >> if you can add it to the list of topics:
> >>
> >> https://wiki.qt.io/Qt_Contributors_Summit_2021_-_Program
> >>
> >> Which doesn’t mean that we shouldn't start the discussion on the
> >> list, and maybe we can then conclude it at the summit.
> >>
> >>
> >> Cheers,
> >> Volker
> >
> > OK, added it to the list.
> >
> 
> Thanks.
> 
> 
> As for the topic:
> 
> I do think that we have cases where too many modules are lumped into a
> single repo, and cases where we have too much granularity.
> 
> For the former: I see no immediate reason why QtNetwork needs to be in
> qtbase (network tests failing is a major cause of unrelated integrations
> failing), or why the Qt Positioning module needs to be in qtlocation.
> 
> For the latter: Qt Quick Controls 2 might be better off sharing a commit
> history with QtQuick
> 
> However, while we can make adjustments, I also think that there’s no
> perfect solution. It’s always a tradeoff between speed and autonomy on the
> one, and integrity across dependencies on the other hand.

I agree.

> Running more tests is a similar tradeoff, and I don’t think blocking an
> integration into e.g. qtbase because it breaks a leaf module is a good 
> solution
> to the problem. We should aim for fast feedback, and short meantime to
> recover such breakages, and making CI runs take even longer helps with
> neither. In particular if we then can’t make any such changes even though a
> follow up change in a leaf module is already available and just needs to wait
> for the dependency update. Then we are in a deadlock, unless we keep the
> code in qtbase working for both versions of e.g. qtdeclarative, which is not
> always practical.

I could be wrong, but perhaps this is what Ossi's 
https://bugreports.qt.io/browse/COIN-133 was targeting. In any case, I can't 
really speak for qtbase as I rarely work on it.

> The problem is perhaps not that we break things, but that we don’t notice
> for too long that we broke things? And once we do notice, we often seem to
> be unwilling to revert the change that did cause the breakage, if things don’t
> get fixed quickly.

This might be the case for qtbase and its leaf modules, but not for 
qtdeclarative and qtquickcontrols2. The typical situation there is: 
qtquickcontrols2 dependency update fails. I immediately cannot think of any 
relevant changes that would cause such a failure, so I quick

Re: [Development] Solutions for ensuring that changes in upstream modules are tested with downstream modules before merging

[Mitch Curtis]

> -Original Message-
> From: Volker Hilsheimer 
> Sent: Friday, 4 June 2021 2:45 PM
> To: Mitch Curtis 
> Cc: development@qt-project.org
> Subject: Re: [Development] Solutions for ensuring that changes in upstream
> modules are tested with downstream modules before merging
> 
> > On 4 Jun 2021, at 13:56, Mitch Curtis  wrote:
> >
> > Hi.
> >
> > A common problem I see is that a change in say qtbase or qtdeclarative can
> cause test failures in modules that depend on them after that change is
> merged. As a result, dependency updates for the downstream modules can
> be blocked, requiring the module maintainer to look into the failure, only to
> discover that it is caused by an upstream module. This causes a lot of time
> and effort to be diverted away from regular work. Both upstream and
> downstream developers would benefit from having more immediate CI
> feedback on these kinds of changes.
> >
> > https://bugreports.qt.io/browse/QTBUG-79454 was created to track this
> problem. So far the ideas suggested have been:
> >
> > - Run tests of dependent modules when testing a change, in addition to
> the regular tests for that module
> > - Merge repositories of more tightly coupled modules (e.g. move
> qtquickcontrols2 into qtdeclarative)
> >
> > It would be beneficial to discuss the advantages and disadvantages of
> these and other solutions so that we can address this problem.
> >
> > Cheers.
> 
> 
> Excellent topic for the upcoming Qt Contributors Summit, Mitch, great if you
> can add it to the list of topics:
> 
> https://wiki.qt.io/Qt_Contributors_Summit_2021_-_Program
> 
> Which doesn’t mean that we shouldn't start the discussion on the list, and
> maybe we can then conclude it at the summit.
> 
> 
> Cheers,
> Volker

OK, added it to the list.

___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

[Development] Solutions for ensuring that changes in upstream modules are tested with downstream modules before merging

[Mitch Curtis]

Hi.

A common problem I see is that a change in say qtbase or qtdeclarative can 
cause test failures in modules that depend on them after that change is merged. 
As a result, dependency updates for the downstream modules can be blocked, 
requiring the module maintainer to look into the failure, only to discover that 
it is caused by an upstream module. This causes a lot of time and effort to be 
diverted away from regular work. Both upstream and downstream developers would 
benefit from having more immediate CI feedback on these kinds of changes.

https://bugreports.qt.io/browse/QTBUG-79454 was created to track this problem. 
So far the ideas suggested have been:

- Run tests of dependent modules when testing a change, in addition to the 
regular tests for that module
- Merge repositories of more tightly coupled modules (e.g. move 
qtquickcontrols2 into qtdeclarative)

It would be beneficial to discuss the advantages and disadvantages of these and 
other solutions so that we can address this problem.

Cheers.


___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

[Development] Stepping down as Qt Virtual Keyboard maintainer

[Mitch Curtis]

Hi.

I would like to formally step down as the maintainer of Qt Virtual Keyboard. I 
initially volunteered to take care of the module, however, with Jarkko Koivikko 
having written most of the module himself, it was never really an accurate 
reflection of its ownership. I have mostly been reviewing Jarkko's changes and 
doing administrative stuff, which I will continue to help out with.

Unsurprisingly, I would like to nominate Jarkko as the maintainer. For a list 
of his changes, see the previous thread nominating him to be an approver:

https://lists.qt-project.org/pipermail/development/2021-January/040908.html

Cheers.
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

[Development] Nominating Jarkko Koivikko as an approver

[Mitch Curtis]

Hi.

I would like to nominate Jarkko Koivikko as an approver for the Qt Project.

Jarkko has been contributing to the Qt project since mid-2014, having 
practically written the entirety of the Qt Virtual Keyboard module. His 
knowledge in this area is second to none, and would be a great asset in 
ensuring the quality of commits and moving the module forward in general.

Here is the list of his changes on Gerrit: 

https://codereview.qt-project.org/q/owner:jarkko.koivikko%2540code-q.fi

Cheers.
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Long-lived P1 issues

[Mitch Curtis]

> -Original Message-
> From: Development  On Behalf Of
> Jason McDonald
> Sent: Friday, 4 December 2020 5:25 AM
> To: Kai Köhne 
> Cc: development@qt-project.org
> Subject: Re: [Development] Long-lived P1 issues
> 
> 
> On Fri, 4 Dec 2020 at 02:09, Kai Köhne   > wrote:
> 
> 
>   > Was there any outcome from this discussion? Like, re-evaluating
> priority
>   > levels and what they mean in terms of release blockers?
> 
> 
> 
> I note that the number of open P1's has dropped from 1175 to 1063.  Some of
> that decline has been from genuine P1's getting fixed for Qt 6, some is due to
> maintainers doing some housekeeping, and I have closed a handful while
> sifting through the older half of the Needs More Info bugs.
> 
> 
> Thank you to everyone who has contributed so far.
> 
> 
> There was no consensus, however, so I've put this on the backburner until I
> can finish reading through the rest of the NMI bugs and the Testlib backlog,
> which will take me into the new year.
> 
> 
> When I'm done with those tasks, perhaps I can find one or two maintainers
> who wouldn't mind a little help to straighten out their module's backlog in
> exchange for educating me about their module.  (Warning: I can only commit
> to a maximum of ten hours per week for the foreseeable future.)
> 
> Personally, I don't have a problem with the definitions of the priority 
> levels.
> The only change I'd suggest is to make it explicit that the availability of an
> easy workaround should generally cause the priority of a bug to drop down
> one step.
> 
> 
> What I'm seeing in Jira suggests that collectively we just aren't very strict
> about sticking to those definitions.  I've seen some cases where P1 has been
> set to indicate that "this bug really annoys me" rather than "this bug 
> seriously
> disrupts my work".  I also see cases where the reporter set the priority
> themselves.  Back in the Nokia days, we had separate Severity and Priority
> fields so that Jira could show both the level of disruption experienced by the
> reporter and the urgency for a fix set by the maintainer.  I'm afraid that I 
> can't
> remember why we merged those fields.

There was a discussion related to this recently:

https://lists.qt-project.org/pipermail/development/2020-February/038988.html

> 
> 
>   I don't think there was any sort of decision or consensus. Which
> means we keep working with the status quo, as documented in
> https://bugreports.qt.io/secure/ShowConstantsHelp.jspa?#PriorityLevels
> 
>   I suggest to simplify P3, P4 descriptions though to
> 
> P2: Important, should be fixed.
> P3: Should be fixed.
> 
>   (the mentioning that they don't block a release probably stems from
> a time where P1 meant blocking the release. This is not the case anymore, so
> what's the point in highlighting that a P2, P3 doesn't block a release?).
> 
> 
> 
> I think that would be a good change.  P1's blocking a release only made sense
> back in the days where we could only manage one release every three or
> four months.
> 
> 
> Cheers,
> --
> Jason

___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Maintainers, your action needed: Qt 5.12.10 changes files

[Mitch Curtis]

> -Original Message-
> From: Development  On Behalf Of
> Jani Heikkinen
> Sent: Friday, 16 October 2020 10:53 AM
> To: development@qt-project.org
> Subject: [Development] Maintainers, your action needed: Qt 5.12.10 changes
> files
> 
> Hi,
> Initial ones here: https://codereview.qt-
> project.org/q/message:%2522Add+changes+file+for+Qt+5.12.10%2522

Nice!

One thing that we should probably change is the behaviour of the script when it 
finds no entries. Currently it leaves the headers:

https://codereview.qt-project.org/c/qt/qtwebchannel/+/317510/1/dist/changes-5.12.10

It should be like the old behaviour:

- This release contains only minor code improvements.

I created https://bugreports.qt.io/browse/QTQAINFRA-3970 to track that.
 
> Those are now done by using that new go -based script; hoping all is OK ;)
> 
> Please finalize these asap; release target is 27th October
> 
> br
> Jani Heikkinen
> Release Manager
> 
> ___
> Development mailing list
> Development@qt-project.org
> https://lists.qt-project.org/listinfo/development
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] qmake: qmltest missing in Qt6

[Mitch Curtis]

> -Original Message-
> From: Development  On Behalf Of
> Arno Rehn
> Sent: Sunday, 9 August 2020 7:58 PM
> To: development@qt-project.org
> Subject: [Development] qmake: qmltest missing in Qt6
> 
> Hey everybody,
> 
> I'm trying to port over qtwebchannel from qmake to CMake, so we can
> hopefully include it in Qt 6.1 again. The problem is that I can't get the unit
> tests going with the old qmake system against current qt6 dev.
> I'd like to have something working which I can then port.
> 
> The error message from qmake is just:
> > Project ERROR: Unknown module(s) in QT: qmltest
> 
> It seems to have its root in cause in mkspecs/features/qmltestcase.prf,
> where it reads
> > mkspecs/features/qmltestcase.prf:QT += qml qmltest
> 
> Is this a regression? I thought that qmake should still be supported with Qt6,
> even though Qt itself has switched to CMake.
> Any ideas?

Do you have qtbase/lib/libQt6QuickTest.so.6.0.0? It could be that it failed to 
build for some reason, assuming you're using a self-built Qt.
 
> Regards,
> Arno
> 
> --
> Arno Rehn
> Tel +49 89 189 166 0
> Fax +49 89 189 166 111
> a.r...@menlosystems.com
> www.menlosystems.com
> 
> Menlo Systems GmbH
> Am Klopferspitz 19a, 82152 Martinsried, Germany Amtsgericht München HRB
> 138145
> Geschäftsführung: Dr. Michael Mei, Dr. Ronald Holzwarth USt.-IdNr.
> DE217772017, St.-Nr. 14316170324
> ___
> Development mailing list
> Development@qt-project.org
> https://lists.qt-project.org/listinfo/development
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Requesting a repository for Qt Quick Calendar

[Mitch Curtis]

https://bugreports.qt.io/browse/QTQAINFRA-3812

> -Original Message-
> From: Edward Welbourne 
> Sent: Wednesday, 24 June 2020 11:33 AM
> To: Mitch Curtis 
> Cc: development@qt-project.org
> Subject: Re: Requesting a repository for Qt Quick Calendar
> 
> Mitch Curtis (24 June 2020 10:49) wrote:
> > Gerrit admins, can you please create the repository? :)
> 
> I believe the recommended process here is to open a Jira ticket.
> You can reference your mail in the list's archive as evidence that it's
> warranted.  Probably QTQAINFRA has a Gerrit section.
> 
>   Eddy.
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Requesting a repository for Qt Quick Calendar

[Mitch Curtis]

According to [1], a "a reasonable amount of time" has passed, with everyone 
having several business days to object to the creation of the repository.

Gerrit admins, can you please create the repository? :)

[1] https://quips-qt-io.herokuapp.com/quip-0002.html#lazy-consensus

> -Original Message-
> From: Development  On Behalf Of
> Mitch Curtis
> Sent: Wednesday, 17 June 2020 9:00 AM
> To: development@qt-project.org
> Subject: [Development] Requesting a repository for Qt Quick Calendar
> 
> Hi.
> 
> I'd like to request a Gerrit repository for Qt Quick Calendar at
> qt/qtquickcalendar.
> 
> The Qt Quick Calendar module provides a set of types that can be used to
> build calendars in Qt Quick.
> 
> This module will be delivered through the marketplace. It will be released
> independently of Qt releases. In addition, it has no compatibility guarantee,
> meaning that we have much greater flexibility to experiment with new ideas.
> 
> Cheers.
> ___
> Development mailing list
> Development@qt-project.org
> https://lists.qt-project.org/listinfo/development
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

[Development] Requesting a repository for Qt Quick Calendar

[Mitch Curtis]

Hi.

I'd like to request a Gerrit repository for Qt Quick Calendar at 
qt/qtquickcalendar.

The Qt Quick Calendar module provides a set of types that can be used to build 
calendars in Qt Quick.

This module will be delivered through the marketplace. It will be released 
independently of Qt releases. In addition, it has no compatibility guarantee, 
meaning that we have much greater flexibility to experiment with new ideas.

Cheers.
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Proposal: Deprecate QVector in Qt 6

[Mitch Curtis]

> -Original Message-
> From: Development  On Behalf Of
> André Somers
> Sent: Thursday, 23 April 2020 12:04 PM
> To: Jaroslaw Kobus ; development@qt-project.org
> Subject: Re: [Development] Proposal: Deprecate QVector in Qt 6
> 
> Hi,
> 
> On 23-04-20 11:58, Jaroslaw Kobus wrote:
> > There are cases, where the name of the function contains the "list", like:
> >
> > QList
> QMdiArea::subWindowList(QMdiArea::WindowOrder
> > order = CreationOrder) const; QList >
> > QGraphicsItemAnimation::translationList() const;
> > QList
> QLowEnergyAdvertisingParameters::whiteList() const; etc...
> >
> > So, subWindowList() returning the vector?
> 
> Yeah. Not ideal, but not a big deal either in these cases, especially the last
> one which uses a common term "whiteList". I do see an issue with API like
> QSet::toList(). That would obviously need to be deprecated in favor of a
> QSet::toVector().

QSet::toVector() was rejected in favour of range constructors: 
https://bugreports.qt.io/browse/QTBUG-71067

> André
> 
> 
> >
> > Changing QList to QVector may in consequence require even more API
> changes.
> >
> > Jarek
> >
> > 
> > From: Development  on behalf of
> > André Somers 
> > Sent: Thursday, April 23, 2020 11:21 AM
> > To: development@qt-project.org
> > Subject: Re: [Development] Proposal: Deprecate QVector in Qt 6
> >
> > Hi Simon,
> >
> >
> > On 23-04-20 10:55, Simon Hausmann wrote:
> > Hi,
> >
> > So take for example this function in QIconEngine:
> >
> >  virtual QList availableSizes(QIcon::Mode mode =
> > Icon::Normal, QIcon::State state = QIcon::Off) const;
> >
> > If we change that to QVector, we require our users to clutter their code
> base with #ifdefs. If we keep it with QList but use QVector in all non-virtual
> functions, then we create a less consistent API.
> >
> > Do you think the #ifdefs or inconsistency is worth the proximity to
> > the standard? (despite QVector not being like std::vector due to CoW
> > semantics)
> >
> > I may be missing the obvious, but I really fail to see the problem if
> > you change the signature to
> >
> > virtual QVector availableSizes(...);
> >
> >
> > If we have that
> >
> >  template using QList = QVector;
> >
> >
> > a subclass reimplementing using QList should just work in both Qt5 and Qt6,
> right? So what #ifdef's would be needed?
> >
> >
> > And yes, I _do_ think staying close to the established meaning of what is a
> vector and what is a list is good. Getting list of QList (which is not a 
> list) brings
> us closer to that goal.
> >
> >
> > André
> >
> >
> >
> > Simon
> > 
> > From: Daniel Engelke
> >
> 
> > Sent: Thursday, April 23, 2020 10:52
> > To: Simon Hausmann
> 
> > Cc: development@qt-project.org
> > 
> > Subject: Re: [Development] Proposal: Deprecate QVector in Qt 6
> >
> > Hi Simon,
> >
> > I think having a name that is close to the standard is very important as it
> makes it easy to find the Qt counterpart.
> > Back in the days I had to ask a StackOverflow question to find Qts
> unique_ptr (QScopedPointer), because I couldn't find it due to the naming.
> >
> > Dmitriy also has a very valid point. It is burned in a lot of peoples heads 
> > that
> using QList is a bad idea.
> >
> > I don't see a lot of work in string replacing QList with QVector and
> QStringList with whatever it would be, as long as the API is compatible.
> > It's even less work if auto has been used.
> >
> > Dan
> >
> >
> > From: Simon Hausmann
> > 
> > To: Dmitriy Purgin 
> > Cc: "development@qt-project.org"
> > 
> > Sent: 4/23/2020 10:27 AM
> > Subject: Re: [Development] Proposal: Deprecate QVector in Qt 6
> >
> > Hi Dmitriy,
> >
> > No, this is not an April's Foolk joke.
> >
> > Previous discussions were largely centred around the implementations and
> bringing them together. With this thread my concern is the API and the churn
> our users would have to apply to their code base in order to use Qt 5 and Qt
> 6.
> >
> >
> > Simon
> > 
> > From: Dmitriy Purgin 
> > Sent: Thursday, April 23, 2020 9:53
> > To: Simon Hausmann
> 
> > Cc: development@qt-project.org
> > 
> > Subject: Re: [Development] Proposal: Deprecate QVector in Qt 6
> >
> > Hi Simon,
> >
> > I hope it's not a belated April's Fool joke? As far as I can remember, for 
> > the
> past few years, one would read everywhere to switch to QVector from QList
> because of this and that, and to choose QVector as the default choice
> container instead of QList like it was back in the days. I can't give the 
> exact
> references but 

Re: [Development] Priority field in Jira

[Mitch Curtis]

>From: Volker Hilsheimer 
> 
> The priority field changes it’s meaning during the lifetime of the bug report:
> 
> * in the beginning, it tells us how important it is for the reporter of the 
> bug. This is useful.

This is news to me; I've not once heard of it being used this way. I also 
question the usefulness of a field that has two meanings over time. Why not 
have two fields with distinct meanings that can't be confused and that result 
in no extra work? However little that work may be, it's still unnecessary. This 
solution is even more "inclusive" [1], as well.

I would argue that a good bug report should explain what the consequences of a 
bug are and how this affects the user's application. I have asked for this 
exact information in several instances in the past and it greatly helped me 
come up with a suitable priority. If this information is not initially present 
in the report, this question has to be asked eventually anyway. When you ask 
what the consequences of a bug are and how it affects the end user, you can 
quite easily come up with an objective assessment of the priority of that bug, 
and of course any +1 comments, votes and watchers can naturally increase that 
priority over time to some extent.

> * after triaging (which we do regularly, at least in The Qt Company), it 
> tells us how important it is for the Qt Company (and perhaps the Qt 
> community/project at large)

But if the initial priority as reported by the customer is important, then 
you've just lost it by overriding during triage (not many people are going to 
check the "All" tab to see the history). This might solve the issue of being 
"inclusive", but then becomes a lack of transparency.

> Anything that is still a P0 after triaging should be treated as such: 
> unplanned work that needs to be fixed so urgently that it preempts any 
> planned work.
> 
> For everything else: if you are in a team that plans their work weeks based 
> on JIRA tickets, then the priority of a ticket is one piece of information 
> for that planning process.
> 
> Not allowing reporters to set priority removes a piece of information, but 
> shouldn’t change anything else, so I’m not convinced that we should limit 
> things by default.

Most reports are created with priorities left as unevaluated, so by now we 
should be used to coming to a conclusion about the priority without an initial 
assessment from the reporter. This is something I think the bug triaging duties 
are great for getting better at, and I think pretty much everyone in the 
company does a good job at assessing priorities.

> If reporters consistently abuse their privilege, in spite of dialogue and 
> feedback, then we might need to find more effective ways to deal with those 
> particular reporters.

To be clear: I've probably ever only had a ping-pong issue once, so I'm not 
claiming that that is a problem. I'm just questioning whether our process could 
be more efficient.

[1] Though if you look another popular open source project with a public bug 
tracker with lots of bugs, you'll see that reporters have even less freedom in 
managing a report and somehow it works fine: 
https://github.com/godotengine/godot/issues
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Priority field in Jira

[Mitch Curtis]

>
>From: Development  on behalf of Lorn 
>Potter 
>Sent: Wednesday, 26 February 2020 11:15 AM
>To: development@qt-project.org
>Subject: Re: [Development] Priority field in Jira
>
>On 25/2/20 8:11 PM, Joerg Bornemann wrote:
>> On 2/25/20 10:31, Edward Welbourne wrote:
>>
>>> How about: because we can always over-ride them if we really disagree;
>>> and their prioritising of the bug is an opening for discussion of why
>>> it's so important to them - which, after all, we might have missed.
>>>
>>> I'd rather have a dialog than a privilege,
>>
>> This is about expertise, not privilege. For reporters, the priority is
>> usually muuch higher than for us or even other users of Qt, because
>> the priority is assessed from the viewpoint of their project.
>>
>> Let's say I've written this audio player app and found some quirk in
>> QtMultimedia that makes skipping impossible every once in a while. Users
>> give one star ratings and complain loudly.
>> What priority is this bug for me? Well, P0 of course.
>> For us? Not so much...
>
>That's when one uses the privilege of being the assignee to change the
>priority to what you think it is, with an explanation to the reporter
>why it isn't a P0.

How is this different in the end? I can probably count the number of times a 
priority set by a reporter didn't need to be changed on one hand. So in the end 
it's simply extra work that has be done on top of an already massive backlog of 
bugs.

>Removing the ability for a reporter to change priority does not seem all
>that inclusive to me.
>my 2c...

I must have missed something here, because I'm not aware of any issues with 
"exclusion" in our bug tracker, and don't know how this can be construed as 
being exclusive. There are processes that we follow to ensure that we have an 
accurate overview of which bugs need the most attention. This is (or should be) 
standard practice at every company that develops software, most of which don't 
have public trackers in the first place. I fail to see how preventing people 
who are unfamiliar with our prioritisation process from changing the priority 
is excluding anyone, _especially_ when the means for disputing a priority is 
already present and is the same regardless of whether or not the priority field 
is open to everyone.
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Priority field in Jira

[Mitch Curtis]

Will try to make comments inline... had to change email client.

On 25/2/20, 10:31 am, "Edward Welbourne"  wrote:

Mitch Curtis (25 February 2020 10:23) elaborated on what he'd said earlier:
>> For some context and for those who don't know: within the company, we
>> now have weekly bug triaging where a team of two people prioritise
>> all unprioritised bugs. So new reports rarely go more than a few days
>> without having a priority set. We've been doing this for a few years
>> (?) now and it works quite well.

> Someone just reminded me that some devs within the company don't have
> approver rights yet, which is a good point.

(Full disclosure: I was that someone.)

> So I'll revise my question:

> Why do we allow users who are unfamiliar with our conventions about
> priority values to set the priority of a bug report?

How about: because we can always over-ride them if we really disagree;
and their prioritising of the bug is an opening for discussion of why
it's so important to them - which, after all, we might have missed.

I'd rather have a dialog than a privilege,

We do have a means for dialog: the comments, which reporters kinda have to use 
to communicate their thoughts about the priority of the report, regardless of 
whether or not they can change the priority. So at that point it's more of a 
gesture of good will, which I understand, but just seems like extra work for 
everyone when the priority is inevitably restored to the previous value.

I would say a far greater privilege is being able to close a report, and that 
too will result in dialog via the comments section if the reporter is unhappy 
with the resolution.

Eddy.
   

___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Priority field in Jira

[Mitch Curtis]

> For some context and for those who don't know: within the company, we
> now have weekly bug triaging where a team of two people prioritise all
> unprioritised bugs. So new reports rarely go more than a few days without
> having a priority set. We've been doing this for a few years (?) now and it
> works quite well.

Someone just reminded me that some devs within the company don't have approver 
rights yet, which is a good point. So I'll revise my question:

Why do we allow users who are unfamiliar with our conventions about priority 
values to set the priority of a bug report?
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

[Development] Priority field in Jira

[Mitch Curtis]

Hi.

I'm curious about what the reasons were for allowing (non-approver) reporters 
of bugs to set the priority field in Jira.

In my experience this often results in priorities being assigned that don't 
follow our conventions [1] on what constitutes a certain priority, but instead 
a priority that reflects how important the bug is to the reporter.

That's not to say that everyone who works on Qt has the same idea about 
priority, as there is always some small variation. However, when a reporter 
changes priority, it's almost always above what most Qt developers would set. 
This doesn't happen too often from the areas of Qt that I get Jira 
notifications for, but I also don't see the point in allowing it in the first 
place (and welcome any small decreases in the amount of Jira notifications), so 
I'm hoping someone can explain.

The only information I've found so far is from this [2] email from 2013:

- Who can prioritize bugs?
   - whoever ask
   - we will create a special group in jira
   - approvers should be in the group by default
  Rationale: We do not have man power and we need help. We do not expect 
anyone to destroy our precious bugs reports or play "ping pong" with a 
priority.

For some context and for those who don't know: within the company, we now have 
weekly bug triaging where a team of two people prioritise all unprioritised 
bugs. So new reports rarely go more than a few days without having a priority 
set. We've been doing this for a few years (?) now and it works quite well.

Cheers.

[1] 
https://bugreports.qt.io/secure/ShowConstantsHelp.jspa?decorator=popup#PriorityLevels
[2] https://lists.qt-project.org/pipermail/development/2013-July/011874.html
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] A modest proposal: disable lower-case keywords (emit, foreach, forever, signals, slots) by default

[Mitch Curtis]

> -Original Message-
> From: Edward Welbourne 
> Sent: Monday, 24 February 2020 1:35 PM
> To: Mitch Curtis 
> Cc: Qt development mailing list ; Lars Knoll
> ; Thiago Macieira 
> Subject: Re: [Development] A modest proposal: disable lower-case
> keywords (emit, foreach, forever, signals, slots) by default
> 
> Mitch Curtis (24 February 2020 13:22)
> > I don't think anyone has explained what that harm is yet.
> 
> #define emit
> 
> causes problems when you import a header that declares
> 
>   void emit(Type arg);
> 
> and the compiler sees
> 
>   void (Type arg);
> 
> and throws a wobbly.
> 
>   Eddy.

Sorry, I should have been more specific: I meant any form of emit (e.g. qEmit) 
that doesn't conflict. So far the arguments have been:

- It's ugly.

Purely subjective. Are code comments also ugly?

- It can be misused

I've never seen it happen. In the very few cases where it does, the 
consequences are so insignificant as to not even be worth considering.

- It's redundant

Only when the major/popular IDEs that a significant portion of Qt users use can 
highlight signal emissions. Until then, it's not redundant if it improves 
readability.
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] A modest proposal: disable lower-case keywords (emit, foreach, forever, signals, slots) by default

[Mitch Curtis]

> -Original Message-
> From: Lars Knoll 
> Sent: Monday, 24 February 2020 1:40 PM
> To: Mitch Curtis 
> Cc: Thiago Macieira ; Qt development mailing
> list 
> Subject: Re: [Development] A modest proposal: disable lower-case
> keywords (emit, foreach, forever, signals, slots) by default
> 
>   On 24 Feb 2020, at 13:22, Mitch Curtis  <mailto:mitch.cur...@qt.io> > wrote:
> 
> 
>   -Original Message-
>   From: Development  <mailto:development-boun...@qt-project.org> > On Behalf Of
>   Lars Knoll
>   Sent: Monday, 24 February 2020 12:25 PM
>   To: Thiago Macieira  <mailto:thiago.macie...@intel.com> >
>   Cc: Qt development mailing list  project.org <mailto:development@qt-project.org> >
>   Subject: Re: [Development] A modest proposal: disable
> lower-case
>   keywords (emit, foreach, forever, signals, slots) by default
> 
> 
> 
>   On 21 Feb 2020, at 17:39, Thiago Macieira
> mailto:thiago.macie...@intel.com> >
> 
> 
>   wrote:
> 
> 
> 
>   On Friday, 21 February 2020 04:59:02 PST Ville
> Voutilainen wrote:
> 
> 
>   Having a keyword-extension to normal C++ is
> ugly as sin, to some of
>   us. It causes fair amounts of "wtf is that?".
> 
> 
> 
>   That was my reaction when I first saw it, in 1999.
> 
>   Over 20 years later, I don't bat an eye.
> 
> 
> 
>   After 20 years, my eyes simply ignore any ‘emit’ in the source
> code.
> 
>   In any case, I do understand why Qt added emit as a keyword
> 25 years ago.
>   But today, we do have IDEs which should be able to figure
> out on the fly
>   whether a function call is a signal emission (as they already do
> for virtual vs
>   non virtual methods). So why don’t we move the over to be
> a tooling
>   problem? Simply highlight signal emissions differently in the
> IDE and you
>   don’t need a keyword for it anymore.
> 
> 
> 
>   That's one way of handling it, but I don't see the harm in keeping it
> for those who want to use it. I don't think anyone has explained what that
> harm is yet.
> 
> 
> 
> It’s redundant. I would prefer to remove things that are redundant and
> where the information could be provided by other means.

In that case, I share the same concerns as Andre in that it requires IDEs to 
have knowledge about Qt. I only use Creator, so it won't bother me, but it will 
affect others who are e.g. transitioning or are so used to another IDE that 
they'd never switch. Semi-related to this: Jira still doesn't know about QML as 
a highlighter syntax, 11 years later. :)

> 
> 
>   It’s also safer, as the keyword can be forgotten or applied to
> the wrong places.
> 
> 
> 
>   I don't think I've ever seen this happen, and am curious as to why it's
> dangerous. It might be misleading, but it couldn't cause harm, just a moment
> of mild confusion. In terms of harm, I see it as on par with (or probably even
> less dangerous than) an out-dated code comment. I think that marking signal
> emissions aids the reader (and there is certainly *a lot* of Qt code that 
> could
> e.g. use more code comments to aid people who have to maintain it).
> 
> 
> 
> Of course it won’t change the logic. I could sprinkle my source code with tons
> of “emit” all over the place and it wouldn’t change it’s meaning ;-)
> 
> emit if emit (emit myVar == emit true)
> mySignal() emit emit emit;
> 
> But we could convey the information that this is a signal you’re calling
> *reliably* through other means. This implies that the keyword is not
> required.

This sounds a lot like what Eike said, where the assumption is that because 
people can misuse it, they will. I don't know why anyone would use it in the 
wrong context except by accident. I agree that IDE highlighting is better 
because it's infallible, but like I said, I've never seen the keyword misused.

> Cheers,
> Lars
> 
> 
> 
>   Cheers,
>   Lars
> 
> 
>   ___
>   Development mailing list
>   Development@qt-project.org <mailto:Development@qt-
> project.org>
>   https://lists.qt-project.org/listinfo/development
> 

___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] A modest proposal: disable lower-case keywords (emit, foreach, forever, signals, slots) by default

[Mitch Curtis]

> -Original Message-
> From: Development  On Behalf Of
> Ville Voutilainen
> Sent: Friday, 21 February 2020 3:02 PM
> To: Christian Kandeler 
> Cc: development@qt-project.org
> Subject: Re: [Development] A modest proposal: disable lower-case
> keywords (emit, foreach, forever, signals, slots) by default
> 
> On Fri, 21 Feb 2020 at 15:44, Christian Kandeler 
> wrote:
> >
> > On Fri, 21 Feb 2020 15:00:53 +0200
> > Ville Voutilainen  wrote:
> >
> > > On Fri, 21 Feb 2020 at 14:58, Sérgio Martins 
> wrote:
> > > > > Why do I need to know that it's a signal being emitted? How is
> > > > > that "vital information"? I could just as well invoke any other
> > > > > callback, but I find myself not exactly yearning for being able
> > > > > to write callback somethingHappened();
> > > >
> > > >
> > > > Signals have different semantics than regular functions.
> > >
> > > In what way?
> >
> > They typically call back into "upper layers", which is worth considering on
> the calling side, e.g. due to the danger of inconsistent state getting 
> accessed
> if you don't emit the signal at the end of a function, to name just one tyical
> pitfall.
> > I, for one, definitely want to see whether I am emitting a signal or not.
> 
> Right; the claims that you can ignore signal emits when looking at a piece of
> code or expect that they don't affect the current scope are exactly
> backwards.
> 
> A signal emitted yields to a coroutine scheduler that runs arbitrary 
> callbacks,
> which in case of direct connections absolutely can affect the current scope.
> 
> Thanks, Christian - that's the first ever plausible explanation for marking a
> signal emission.

Personally I find it a bit concerning that you don't consider readability or 
maintainability a plausible explanation for annotating code with emit. Though I 
can rest easy with the knowledge that you're not the sole authority for what 
constitutes a plausible explanation, despite how you worded it.

I can only assume that that same mindset must also encapsulate all of the 
developers who never wrote any comments for their code because... it made sense 
to them and that's all matters.

> Getting back to macro vs. function.. I think using a function wrapper is fine,
> considering that signals can't meaningfully return, so the prvalue/xvalue
> issue doesn't arise. We could even have qEmit() return void, to prevent a
> possible return value from being (ab)used.
> 
> Yeah, I'm sure we'll have no trouble finding people who think
> 
> qEmit(mah_bucket_callback());
> 
> is unacceptably ugly compared to
> 
> qEmit mah_bucket_callback();
> 
> The big advantage of that ugly version is that it's regular C++ without using
> macros.
> 
> At the risk of riffing on this a tad too far, we could alternatively consider 
> using
> an operator on a global dummy qEmit object, but that runs a risk of getting
> into precedence games.
> ___
> Development mailing list
> Development@qt-project.org
> https://lists.qt-project.org/listinfo/development
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] A modest proposal: disable lower-case keywords (emit, foreach, forever, signals, slots) by default

[Mitch Curtis]

> -Original Message-
> From: Development  On Behalf Of
> Lars Knoll
> Sent: Monday, 24 February 2020 12:25 PM
> To: Thiago Macieira 
> Cc: Qt development mailing list 
> Subject: Re: [Development] A modest proposal: disable lower-case
> keywords (emit, foreach, forever, signals, slots) by default
> 
> > On 21 Feb 2020, at 17:39, Thiago Macieira 
> wrote:
> >
> > On Friday, 21 February 2020 04:59:02 PST Ville Voutilainen wrote:
> >> Having a keyword-extension to normal C++ is ugly as sin, to some of
> >> us. It causes fair amounts of "wtf is that?".
> >
> > That was my reaction when I first saw it, in 1999.
> >
> > Over 20 years later, I don't bat an eye.
> 
> After 20 years, my eyes simply ignore any ‘emit’ in the source code.
> 
> In any case, I do understand why Qt added emit as a keyword 25 years ago.
> But today, we do have IDEs which should be able to figure out on the fly
> whether a function call is a signal emission (as they already do for virtual 
> vs
> non virtual methods). So why don’t we move the over to be a tooling
> problem? Simply highlight signal emissions differently in the IDE and you
> don’t need a keyword for it anymore.

That's one way of handling it, but I don't see the harm in keeping it for those 
who want to use it. I don't think anyone has explained what that harm is yet.

>It’s also safer, as the keyword can be forgotten or applied to the wrong 
>places.

I don't think I've ever seen this happen, and am curious as to why it's 
dangerous. It might be misleading, but it couldn't cause harm, just a moment of 
mild confusion. In terms of harm, I see it as on par with (or probably even 
less dangerous than) an out-dated code comment. I think that marking signal 
emissions aids the reader (and there is certainly *a lot* of Qt code that could 
e.g. use more code comments to aid people who have to maintain it).

> Cheers,
> Lars
> 
> ___
> Development mailing list
> Development@qt-project.org
> https://lists.qt-project.org/listinfo/development
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] A modest proposal: disable lower-case keywords (emit, foreach, forever, signals, slots) by default

[Mitch Curtis]

> -Original Message-
> From: Development  On Behalf Of
> Shawn Rutledge
> Sent: Friday, 21 February 2020 1:59 PM
> To: development@qt-project.org
> Subject: Re: [Development] A modest proposal: disable lower-case
> keywords (emit, foreach, forever, signals, slots) by default
> 
> 
> > On 21 Feb 2020, at 13:30, Mitch Curtis  wrote:
> > How can you tell if it's a signal being emitted or just a function call 
> > without
> the emit syntax? With the emit syntax before the signal emission, it's
> immediately obvious that it's a signal. Not all signals follow the *Changed()
> naming convention, nor should they, so it becomes even less obvious in
> those cases.
> 
> Invent a naming convention?  Add a feature to Creator that makes it clear,
> like different syntax highlighting or a little symbol next to it?
> 
> (Some people name every slot function starting with the word “slot” to make
> clear what it is.)

Or just use an existing convention, perhaps just under a different name. qEmit 
looks good to me.
 
> ___
> Development mailing list
> Development@qt-project.org
> https://lists.qt-project.org/listinfo/development
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] A modest proposal: disable lower-case keywords (emit, foreach, forever, signals, slots) by default

[Mitch Curtis]

> -Original Message-
> From: Eike Ziller 
> Sent: Friday, 21 February 2020 1:55 PM
> To: Mitch Curtis 
> Cc: Ville Voutilainen ; Alex Blasche
> ; development@qt-project.org
> Subject: Re: [Development] A modest proposal: disable lower-case
> keywords (emit, foreach, forever, signals, slots) by default
> 
> 
> 
> > On 21. Feb 2020, at 13:30, Mitch Curtis  wrote:
> > How can you tell if it's a signal being emitted or just a function call 
> > without
> the emit syntax? With the emit syntax before the signal emission, it's
> immediately obvious that it's a signal.
> 
> It isn’t because you can put “emit” anywhere in your code because it has no
> semantics for the compiler.

There are lots of nonsensical things you can do with the language. I'm thinking 
in the context of people who are trying to make their code easy to read, not 
prove a point.

> It’s not beter than any code comment that you could also put there, like
> 
> /*emit*/ something();
> 
> or
> 
> something(); // emit
> 
> > Not all signals follow the *Changed() naming convention, nor should they,
> so it becomes even less obvious in those cases.
> >
> >> ___
> >> Development mailing list
> >> Development@qt-project.org
> >> https://lists.qt-project.org/listinfo/development
> > ___
> > Development mailing list
> > Development@qt-project.org
> > https://lists.qt-project.org/listinfo/development
> 
> --
> Eike Ziller
> Principal Software Engineer
> 
> The Qt Company GmbH
> Erich-Thilo-Straße 10
> D-12489 Berlin
> eike.zil...@qt.io
> http://qt.io
> Geschäftsführer: Mika Pälsi,
> Juha Varelius, Mika Harjuaho
> Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg,
> HRB 144331 B

___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] A modest proposal: disable lower-case keywords (emit, foreach, forever, signals, slots) by default

[Mitch Curtis]

> -Original Message-
> From: Eike Ziller 
> Sent: Friday, 21 February 2020 1:55 PM
> To: Mitch Curtis 
> Cc: Ville Voutilainen ; Alex Blasche
> ; development@qt-project.org
> Subject: Re: [Development] A modest proposal: disable lower-case
> keywords (emit, foreach, forever, signals, slots) by default
> 
> 
> 
> > On 21. Feb 2020, at 13:30, Mitch Curtis  wrote:
> >
> >> -Original Message-
> >> From: Development  On Behalf
> Of
> >> Ville Voutilainen
> >> Sent: Friday, 21 February 2020 12:16 PM
> >> To: Alex Blasche 
> >> Cc: development@qt-project.org
> >> Subject: Re: [Development] A modest proposal: disable lower-case
> >> keywords (emit, foreach, forever, signals, slots) by default
> >>
> >> On Fri, 21 Feb 2020 at 10:42, Alex Blasche 
> wrote:
> >>> I think a fallback to
> >>>
> >>> somethingChanged()
> >>>
> >>> without any annotation is not what we want. We'd miss vital
> >>> information
> >> and reduce readability.
> >>
> >> Can you please explain what that vital information is?
> >
> > How can you tell if it's a signal being emitted or just a function call 
> > without
> the emit syntax? With the emit syntax before the signal emission, it's
> immediately obvious that it's a signal.
> 
> It isn’t because you can put “emit” anywhere in your code because it has no
> semantics for the compiler.

I never said it had any semantic purpose, I'm purely arguing that it has 
implications for readability.

> It’s not beter than any code comment that you could also put there, like
> 
> /*emit*/ something();
> 
> or
> 
> something(); // emit

I disagree; I think those are ugly.

> > Not all signals follow the *Changed() naming convention, nor should they,
> so it becomes even less obvious in those cases.
> >
> >> ___
> >> Development mailing list
> >> Development@qt-project.org
> >> https://lists.qt-project.org/listinfo/development
> > ___
> > Development mailing list
> > Development@qt-project.org
> > https://lists.qt-project.org/listinfo/development
> 
> --
> Eike Ziller
> Principal Software Engineer
> 
> The Qt Company GmbH
> Erich-Thilo-Straße 10
> D-12489 Berlin
> eike.zil...@qt.io
> http://qt.io
> Geschäftsführer: Mika Pälsi,
> Juha Varelius, Mika Harjuaho
> Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg,
> HRB 144331 B

___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] A modest proposal: disable lower-case keywords (emit, foreach, forever, signals, slots) by default

[Mitch Curtis]

> -Original Message-
> From: Ville Voutilainen 
> Sent: Friday, 21 February 2020 1:42 PM
> To: Mitch Curtis 
> Cc: Alex Blasche ; development@qt-project.org
> Subject: Re: [Development] A modest proposal: disable lower-case
> keywords (emit, foreach, forever, signals, slots) by default
> 
> On Fri, 21 Feb 2020 at 14:30, Mitch Curtis  wrote:
> 
> > > > without any annotation is not what we want. We'd miss vital
> > > > information
> > > and reduce readability.
> > > Can you please explain what that vital information is?
> > How can you tell if it's a signal being emitted or just a function call 
> > without
> the emit syntax? With the emit syntax before the signal emission, it's
> immediately obvious that it's a signal. Not all signals follow the *Changed()
> naming convention, nor should they, so it becomes even less obvious in
> those cases.
> 
> Why do I need to know that it's a signal being emitted? How is that "vital
> information"? I could just as well invoke any other callback, but I find 
> myself
> not exactly yearning for being able to write callback somethingHappened();

I can't answer why you need to know, but for me personally, it's just one less 
small thing to think about. I'm not going to try to step into it while 
debugging, for example, and end up in some tasty moc guts. It's like const on 
local variables; a lot of people leave it out but I like having it because it's 
one less thing to consider when I'm already tired and have been thinking all 
day. :)

Having the emit syntax costs the people who don't want to use it nothing, and I 
know which code I'd rather have to maintain.
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] A modest proposal: disable lower-case keywords (emit, foreach, forever, signals, slots) by default

[Mitch Curtis]

> -Original Message-
> From: Development  On Behalf Of
> Ville Voutilainen
> Sent: Friday, 21 February 2020 12:16 PM
> To: Alex Blasche 
> Cc: development@qt-project.org
> Subject: Re: [Development] A modest proposal: disable lower-case
> keywords (emit, foreach, forever, signals, slots) by default
> 
> On Fri, 21 Feb 2020 at 10:42, Alex Blasche  wrote:
> > I think a fallback to
> >
> > somethingChanged()
> >
> > without any annotation is not what we want. We'd miss vital information
> and reduce readability.
> 
> Can you please explain what that vital information is?

How can you tell if it's a signal being emitted or just a function call without 
the emit syntax? With the emit syntax before the signal emission, it's 
immediately obvious that it's a signal. Not all signals follow the *Changed() 
naming convention, nor should they, so it becomes even less obvious in those 
cases.
 
> ___
> Development mailing list
> Development@qt-project.org
> https://lists.qt-project.org/listinfo/development
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] [Releasing] HEADS-UP: Qt 5.15 Feature Freeze is in effect now

[Mitch Curtis]

> -Original Message-
> From: Releasing  On Behalf Of Jani
> Heikkinen
> Sent: Wednesday, 5 February 2020 6:37 AM
> To: Lars Knoll ; Yulong Bai 
> Cc: Volker Hilsheimer ; Qt development mailing list
> ; releas...@qt-project.org
> Subject: Re: [Releasing] [Development] HEADS-UP: Qt 5.15 Feature Freeze is
> in effect now
> 
> Hi!
> 
> Yeah, for me this seems to be quite low risky addition as well. Only concern 
> is
> that we need to delay the Alpha release because of this late addition. We
> have Alpha content in place already now and at least in theory we should
> delay it until all new features are in... So adding 2 weeks delay to there
> doesn't sound that nice to me at this point.; delays are usually causing
> problems & unnecessary hassle later phases of releasing :( And taking this in
> between Alpha and beta doesn't sound that well to me either; what is the
> purpose of Alpha if there isn't all known features in...
> 
> Why this is so important that we should get the exception & go in after FF?

Hi Jani.

- It's a vital part of creating a table in Qt Quick, and something that is 
non-trivial for a good chunk of users to implement themselves.
- I think you and Lars have already said it's low risk, which is true.
- I don't think this counts as justification, but.. it's been in the works for 
a while, and we really shouldn't delay it any longer.
- I'm also confident we will be ready to merge it today.

Cheers.
 
> br,
> Jani
> 
> 
> From: Lars Knoll 
> Sent: Tuesday, February 4, 2020 3:50 PM
> To: Yulong Bai
> Cc: Jani Heikkinen; Qt development mailing list; releas...@qt-project.org;
> Volker Hilsheimer
> Subject: Re: [Development] HEADS-UP: Qt 5.15 Feature Freeze is in effect
> now
> 
> I’d be ok with extending the deadline for this one item until end of next
> week. It shouldn’t be able to break other things as far as I can tell.
> 
> But would like to hear Jani’s opinion as well. If he’s also ok go ahead, but 
> it
> really needs to get approved and merged quickly.
> 
> Cheers,
> Lars
> 
> On 4 Feb 2020, at 14:39, Yulong Bai
> mailto:yulong@qt.io>> wrote:
> 
> Hello,
> 
> HeaderView is almost done but I just missed the feature-freeze. I will have it
> ready by this Friday.
> 
> So, is it OK for everybody that I merge it after the 5.15 feature freeze. It's
> here https://codereview.qt-project.org/c/qt/qtquickcontrols2/+/270170
> 
> br,
> Yulong
> Software Engineer
> 
> From: Jani Heikkinen mailto:jani.heikki...@qt.io>>
> Sent: 03 February 2020 06:35
> To: development@qt-project.org
> mailto:development@qt-project.org>>;
> releas...@qt-project.org  project.org>
> Subject: [Development] HEADS-UP: Qt 5.15 Feature Freeze is in effect now
> 
> Hi all,
> 
> Qt 5.15 Feature Freeze is in effect now. So no new features in '5.15'
> anymore. Please update Qt 5.15 new features page
> (https://wiki.qt.io/New_Features_in_Qt_5.15) now; it seems to be quite
> empty still...
> 
> Target is to publish Qt 5.15 Alpha as soon as possible; Let's see if we can 
> get it
> out already during this week.
> 
> API review for Qt 5.15 will start soon as well. Please do reviews immediately
> when available.
> 
> br,
> Jani Heikkinen
> Release Manager
> 
> ___
> Releasing mailing list
> releas...@qt-project.org
> https://lists.qt-project.org/listinfo/releasing
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] The future of smart pointers in Qt API

[Mitch Curtis]

> Vitaly Fanaskov
> 
> [...] In this case, I think we won't have this confusing definitions like 
> "visual
> parent" and "just a parent"
> (that we have in controls).

Sorry, couldn't resist: visual parent vs QObject parent is a distinction that 
Qt Quick made, not Qt Quick Controls.

___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Notes from "Releasing" session in QtCon19

[Mitch Curtis]

> -Original Message-
> From: Development  On Behalf Of
> André Hartmann
> Sent: Saturday, 23 November 2019 2:02 PM
> To: Christian Ehrlicher ; development@qt-
> project.org
> Subject: Re: [Development] Notes from "Releasing" session in QtCon19
> 
> Hi all,
> 
> > The script creating the changlog still oversees a lot of QTBUG - > entries. 
> > I
> could not find out why the bug number is sometimes added
> to> the changelog entry and sometimes doesn't.> See for example>
> https://codereview.qt-project.org/c/qt/qtbase/+/281862/2..3/dist/changes-
> 5.14.0
> 
> I've experienced the same with
> https://codereview.qt-
> project.org/c/qt/qtserialbus/+/281838/1..4/dist/changes-5.14.0
> 
> Had to add many of them by hand.

There is a better tool for the job:

https://lists.qt-project.org/pipermail/development/2019-April/035545.html

> Greetings,
> André
> >
> >
> > Cheers,
> > Christian
> > ___
> > Development mailing list
> > Development@qt-project.org
> > https://lists.qt-project.org/listinfo/development
> 
> ___
> Development mailing list
> Development@qt-project.org
> https://lists.qt-project.org/listinfo/development
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] clang-format

[Mitch Curtis]

> -Original Message-
> From: Development  On Behalf Of
> Frederik Gladhorn
> Sent: Monday, 14 October 2019 1:46 PM
> To: development@qt-project.org
> Subject: [Development] clang-format
> 
> Hi,
> 
> after just a bit over a year, we have a hint of progress on the state of using
> clang-format.
> 
> If you use qt5.git, you'll get the git hook for it set up, to automatically 
> run
> clang-format on the lines you changed.
> To benefit today, get the dev branch of qt5 and run init-repository -f 
> --force-
> hooks.
> The commit hook runs and shows a diff of what should be changed, but
> doesn't add anything, so your changes should be safe from unwanted
> reformatting no matter what.
> If you think the changes make sense, just run "git clang-format" and all the
> things you have added to the staging area will be reformatted.
> 
> git add myfile # stage a file
> git commit # try to commit, clang-format thinks you need to reformat git
> clang-format # apply the reformatting to the index git diff # see what clang-
> format did
> 
> The hook script which is probably far from optimal (written in sh) is found in
> qt/qtrepotools. You can also just link https://code.qt.io/cgit/qt/
> qtrepotools.git/tree/git-hooks/clang-format-pre-commit as pre-commit into
> your .git/hooks directory and you get to enjoy it.
> 
> I bet we'll have some issues and it's not quite perfect, but hey, small
> progress.
> 
> Enjoy re-formatting and feel relaxed about it too ;)
> 
> Cheers,
> Frederik

For anyone curious about how it looks, here's a dummy test I did:

mitch@mitch-ubuntu-18:~/dev/qt5.13/qtquickcontrols2$ git commit
clang-format output:
diff --git a/tests/auto/qquickmenubar/tst_qquickmenubar.cpp 
b/tests/auto/qquickmenubar/tst_qquickmenubar.cpp
index c0d9f8ed..9a22d26f 100644
--- a/tests/auto/qquickmenubar/tst_qquickmenubar.cpp
+++ b/tests/auto/qquickmenubar/tst_qquickmenubar.cpp
@@ -543,8 +543,7 @@ void tst_qquickmenubar::addRemove()
 QCOMPARE(menuBar->count(), 1);
 QVERIFY(!menuBar->menuAt(1));
 QVERIFY(!menuBar->itemAt(1));
-QCoreApplication::sendPostedEvents(
-menu1.data(), QEvent::DeferredDelete);
+QCoreApplication::sendPostedEvents(menu1.data(), QEvent::DeferredDelete);
 QVERIFY(!menu1.isNull());
 QCoreApplication::sendPostedEvents(menuBarItem1, QEvent::DeferredDelete);
 QVERIFY(menuBarItem1.isNull());
clang-format detected change in format, please run:
  git clang-format
and amend the change.

As a side note, I installed it on Ubuntu 18.04.3 with:

sudo apt-get install clang-format

but there was no git-clang-format binary, even though 
https://packages.ubuntu.com/search?searchon=contents=git-clang-format=exactfilename=disco=any
 said there should be, so I just made a symbolic link to it:

sudo ln -s /usr/bin/git-clang-format-6.0 /usr/bin/git-clang-format

Would be great to know if there's a proper way to do this that I'm missing.

> 
> 
> ___
> Development mailing list
> Development@qt-project.org
> https://lists.qt-project.org/listinfo/development
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Property bindings in Qt 6

[Mitch Curtis]

> -Original Message-
> From: Development  On Behalf Of
> Simon Hausmann
> Sent: Thursday, 26 September 2019 5:03 PM
> To: development@qt-project.org
> Subject: [Development] Property bindings in Qt 6
> 
> Hi,
> 
> Earlier this year, Olivier, Samuel, Auri and I worked on a project to re-
> evaluate how we could bring the declarative Qt Quick approach of doing user
> interfaces closer to C++, in order to allow building and running user 
> interfaces
> in very memory and processor-power constrained environments. There
> were many different outcomes of this. One of them was that we figured out
> a way to compile QML binding expressions down to full C++, without any run-
> time interpretation. This required building a new way of defining properties
> and their relationships, a new property binding system. The results were so
> convincing that the plan was born to productize this for Qt 6 in multiple 
> layers
> and steps. I'd like to initiate a first step in that direction by proposing 
> API and
> functionality for Qt 6 and briefly outline how we see the building blocks 
> apply
> to QML and Qt Quick:
> 
> In QML, today, properties consist of a type, a setter function and a getter
> function, and the functions are implemented by the developer. There is also
> a change signal that needs to be emitted when the value changes.
> 
> Binding expressions declared in .qml files are created behind the scenes and
> the QML engine makes sure to call the getter functions during the evaluation
> and the setter function to write the result. Through a connection to the
> change signal, bindings are automatically re-evaluated when properties
> change and the new values are passed to the setter functions. It's pretty
> magic and it works, but it requires a fair amount of indirection and side-
> loading of data structures.
> 
> I would like to propose an API that replaces the setter and getter functions
> on objects with a new property template class that encapsulates the
> property value instead, and the ability to tie binding expressions to these
> properties for automatic updates. In short, it looks like this:
> 
> QProperty surname("John");
> 
> QProperty lastname("Smith");
> 
> 
> QProperty fullname;
> 
> fullname.setBinding([&]() { return surname() + " " + lastname(); });
> 
> 
> qDebug() << fullname(); // Prints "John Smith"
> 
> 
> surname = "Emma"; // Marks binding expression as dirty
> 
> 
> qDebug() << fullname(); // Re-evaluates the binding expression and prints
> "Emma Smith"
> 
> 
> 
> 
> 
> You can see a work-in-progress patch for this in Gerrit at
> 
> https://codereview.qt-project.org/c/qt/qtbase/+/275352
> 
> 
> The basic data structure behind this is the property value itself as well as
> doubly linked lists to track dependencies between properties and binding
> expressions. Due to the encapsulation of the data itself in a class, it is
> possible to do a lazy evaluation of bindings. (Credit goes in particular to
> Olivier for the idea and first implementation in our project)
> 
> 
> Once this class and its documentation is complete, the next step is to build a
> bridge to the QML engine and the moc, so that it's possible to associate
> binding expressions in .qml files with properties declared this way. 
> Similarly,
> it needs to be possible to access such properties through the meta-call, if
> they are placed inside Q_OBJECT classes.
> 
> The next step is to begin applying this to the implementation of Qt Quick.
> Some of which may require shims for the public Qt Quick API (to keep it
> Q_PROPERTY based), and for the private Qt Quick types the idea would be to
> start using QProperty.
> 
> Finally, once all the pieces are in place, we hope to extend the qml tooling 
> to
> compile the binding expressions in .qml files to C++ that uses this more 
> light-
> weight property system whenever possible. Ulf has been working towards
> this from the QML engine direction (see the recent email about moc and
> meta-type extraction) and Fabian has been working on the QML linter as a
> starting point towards a compilation model for QML.
> 
> 
> This is our rough plan of how we'd like to address one aspect of QML and Qt
> Quick today. We are looking forward to any feedback and questions to help
> us review and refine this design.

I think you guys did an awesome job with it from what I've seen. :)

In my experience with a similar system, one drawback is the lack of ability to 
implement custom setters. For example, I often find that I need to validate 
some input to a setter:

https://code.qt.io/cgit/qt/qtquickcontrols2.git/tree/src/quicktemplates2/qquickslider.cpp#n355

In the end the solution was to use "dirty events" (i.e. derive from a certain 
type, implement operator() and pass a pointer the property in its constructor) 
as a way of reacting to the changes after they were made, but this is not ideal.

Will custom setters be possible?

> 
> Simon

Re: [Development] Question about tests/manual folders

[Mitch Curtis]

> -Original Message-
> From: Development  On Behalf Of
> Asmo Saarela
> Sent: Friday, 20 September 2019 8:30 AM
> To: development@qt-project.org
> Subject: [Development] Question about tests/manual folders
> 
> Hi all,
> 
> 
> 
> I would like to understand the content and the use of the manual test assets
> in the Qt modules.
> 
> Could you provide a few examples of how you are using, maintaining, and
> developing those?
> 
> 
> 
> It seems that there are some 439 folders related to the manual tests in the
> repositories: /tests/manual/*
> 
> 
> 
> When are you executing these manual tests? What do you do with the
> information from the test execution?

In qtquickcontrols2:

- buttons - similar to testbench but specifically for buttons.
- fonts - shows how changing font sizes affects controls.
- gifs - simulates events on controls and records them (on Linux) as GIFs for 
use in documentation.
- screenshots - allows loading code snippets from the doc directory to take 
screenshots of them for use in documentation.
- styles - used for the screenshots of each style on this page: 
https://doc.qt.io/qt-5/qtquickcontrols2-styles.html
- systemtrayicon - tests that system tray icons work.
- testbench - quickly checking that all controls in various states look and 
function as expected. I used it quite a lot when working on the Imagine style, 
for example.
- viewinqwidget - tests controls with QQuickWidget.

I haven't used the fonts, systemtrayicon and viewinqwidget tests before, or 
don't use them very often, but can see how they'd be useful. The gifs, 
screenshots and styles tests are used whenever doc images need to be added or 
updated. The buttons and especially testbench tests I have used before and will 
use again.

> 
> 
> Best regards, Asmo Saarela
> 
> Test Lead

___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Qt Static Package

[Mitch Curtis]

> -Original Message-
> From: Simon Hausmann
> Sent: Monday, 29 April 2019 5:58 PM
> To: Mitch Curtis 
> Cc: Thiago Macieira ; development@qt-
> project.org
> Subject: Re: [Development] Qt Static Package
> 
> 
> The application is perfectly distributable, but the static libraries are tied 
> to the
> exact compiler binary and therefore not so suitable for sending to other
> people. So it’s all good :)
> 
> Simon

Ah, thank you for clarifying!

> On 29. Apr 2019, at 17:47, Mitch Curtis  wrote:
> 
> >> -Original Message-
> >> From: Development  On Behalf
> Of
> >> Thiago Macieira
> >> Sent: Monday, 29 April 2019 5:18 PM
> >> To: development@qt-project.org
> >> Subject: Re: [Development] Qt Static Package
> >>
> >>> On Monday, 29 April 2019 00:27:14 PDT Mitch Curtis wrote:
> >>> -static -release -ltcg -opensource -confirm-license -nomake tests
> >>> -nomake examples -silent
> >>
> >> -static -ltcg is most definitely not redistributable. That build is
> >> only usable in your exact machine, and only for so long as you don't
> >> perform a system update.
> >
> > That's a pity. It shaved off 8 mb (19%) of my executable's size.
> >
> > Can you explain why it's not redistributable? I thought the whole point of
> link time code generation was for release builds?
> >
> >> --
> >> Thiago Macieira - thiago.macieira (AT) intel.com  Software Architect
> >> - Intel System Software Products
> >>
> >>
> >>
> >> ___
> >> Development mailing list
> >> Development@qt-project.org
> >> https://lists.qt-project.org/listinfo/development
> > ___
> > Development mailing list
> > Development@qt-project.org
> > https://lists.qt-project.org/listinfo/development
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Qt Static Package

[Mitch Curtis]

> -Original Message-
> From: Development  On Behalf Of
> Mitch Curtis
> Sent: Monday, 29 April 2019 5:45 PM
> To: Thiago Macieira ; development@qt-
> project.org
> Subject: Re: [Development] Qt Static Package
> 
> > -Original Message-
> > From: Development  On Behalf
> Of
> > Thiago Macieira
> > Sent: Monday, 29 April 2019 5:18 PM
> > To: development@qt-project.org
> > Subject: Re: [Development] Qt Static Package
> >
> > On Monday, 29 April 2019 00:27:14 PDT Mitch Curtis wrote:
> > > -static -release -ltcg -opensource -confirm-license -nomake tests
> > > -nomake examples -silent
> >
> > -static -ltcg is most definitely not redistributable. That build is
> > only usable in your exact machine, and only for so long as you don't
> > perform a system update.
> 
> That's a pity. It shaved off 8 mb (19%) of my executable's size.
> 
> Can you explain why it's not redistributable? I thought the whole point of 
> link
> time code generation was for release builds?

Everywhere I read online says that it's for release builds. 
https://blog.qt.io/blog/2019/01/02/qt-applications-lto/ (where I got the idea 
to use -ltcg) says:

"But, this optimization is definitely something that fits well into the release 
process, when creating your final build. So, your Release Manager can use it."

> > --
> > Thiago Macieira - thiago.macieira (AT) intel.com
> >   Software Architect - Intel System Software Products
> >
> >
> >
> > ___
> > Development mailing list
> > Development@qt-project.org
> > https://lists.qt-project.org/listinfo/development
> ___
> Development mailing list
> Development@qt-project.org
> https://lists.qt-project.org/listinfo/development
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Qt Static Package

[Mitch Curtis]

> -Original Message-
> From: Development  On Behalf Of
> Thiago Macieira
> Sent: Monday, 29 April 2019 5:18 PM
> To: development@qt-project.org
> Subject: Re: [Development] Qt Static Package
> 
> On Monday, 29 April 2019 00:27:14 PDT Mitch Curtis wrote:
> > -static -release -ltcg -opensource -confirm-license -nomake tests
> > -nomake examples -silent
> 
> -static -ltcg is most definitely not redistributable. That build is only 
> usable in
> your exact machine, and only for so long as you don't perform a system
> update.

That's a pity. It shaved off 8 mb (19%) of my executable's size.

Can you explain why it's not redistributable? I thought the whole point of link 
time code generation was for release builds?

> --
> Thiago Macieira - thiago.macieira (AT) intel.com
>   Software Architect - Intel System Software Products
> 
> 
> 
> ___
> Development mailing list
> Development@qt-project.org
> https://lists.qt-project.org/listinfo/development
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Qt Static Package

[Mitch Curtis]

> -Original Message-
> From: Carlos Enrique Pérez Sánchez 
> Sent: Friday, 26 April 2019 9:42 PM
> To: Mitch Curtis ; development@qt-project.org
> Subject: Re: [Development] Qt Static Package
> 
> > This sounds very similar to what I saw with linuxdeployqt a while back
> Currently, I can link dynamically on Linux (using qmake to generate the
> makefile) and make a standalone executable with linuxdeployqt and it works
> well. I do have to add some dependencies manually like the svg module
> (even if I add it to the .pro file) but after that it works well.
> Regarding static builds, I have a few issues on Linux but none of them are
> related directly to Qt. After install the corresponding -dev package the
> related dependency issue is gone. However, it is hard to track all
> dependencies and make another build every time something goes wrong
> because I have a low-power device so the build process takes about 8 hours.
> So, instead, I'm linking dynamically on Linux using linuxdeployqt.
> 
> > I've sinced moved to Qbs, and for a while was building statically on Linux
> and it solved all of the issues I had. Recently users started running into 
> issues
> with missing ICU libs
> I'm using qmake because there is not Qbs option in Qt 5.12 (at least on Linux,
> opensource license). Also, I have zero experience with Qbs, but I will give 
> it a
> try if you suggest so, but...
> the command line options to pass to configure are exactly the same?
> BTW: Can you post the command line you use to build Qt statically?

Here are my static configure args for Linux:

-static -release -ltcg -opensource -confirm-license -nomake tests -nomake 
examples -silent
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Qt Static Package

[Mitch Curtis]

> -Original Message-
> From: Development  On Behalf Of
> Carlos Enrique Pérez Sánchez
> Sent: Saturday, 20 April 2019 2:56 AM
> To: development@qt-project.org
> Subject: Re: [Development] Qt Static Package
> 
> I invited Mitch Curtis to join the discussion. He may have a word on this 
> since
> he is actively working on the Qt Quick Controls 2 module. Hope he can help
> us here. Making a working static build of Qt Quick Controls 2 can push
> forward the release of static packages.

I don't think I've ever built statically on Windows.

> the graphics effects are off, no shadows, no layer, no elevation, etc.

This sounds very similar to what I saw with linuxdeployqt a while back:

https://github.com/probonopd/linuxdeployqt/issues/280

I've sinced moved to Qbs, and for a while was building statically on Linux and 
it solved all of the issues I had. Recently users started running into issues 
with missing ICU libs:

https://github.com/mitchcurtis/slate/issues/112

So I figured that if I'm gonna have to bundle ICU with a statically built app, 
I may as well try linuxdeployqt again to see if it works, and just link 
dynamically. Turns out it was pretty easy to fix the Qbs files to get it 
working:

https://github.com/mitchcurtis/slate/commit/4bede2be54a194f9bc033d56e4df3d300065415a

So now I'm back to linking the app dynamically on all platforms... guess that 
doesn't really help you much, but that is my experience with the deployment 
process so far.

If I recall correctly, there are reasons why we don't do static builds in CI 
and offer packages for it, but I can't remember what they are. I'm not involved 
in that stuff, so I can't really help.

However, if you have issues with Qt Quick Controls 2 in statically built apps, 
please create bug reports.

> 
> El vie., 19 abr. 2019 a las 20:31, Carlos Enrique Pérez Sánchez
> (mailto:ceperez1...@gmail.com> >) escribió:
> 
> 
>   By the way. I have made no changes to my .pro file after build my
> static version of Qt. The reason is that the Qt Doc says 
> (https://doc.qt.io/qt-
> 5/plugins-howto.html#static-plugins):
> 
>   Plugins can be linked statically into your application. If you
> build the static version of Qt, this is the only option for including Qt's
> predefined plugins. Using static plugins makes the deployment less error-
> prone, but has the disadvantage that no functionality from plugins can be
> added without a complete rebuild and redistribution of the application.
> 
>   To link plugins statically, you need to add the required plugins
> to your build using QTPLUGIN.
> 
>   In the .pro file for your application, you need the following
> entry:
> 
> 
> QTPLUGIN += qjpeg \
> 
> qgif \
> 
> qkrcodecs
> 
> 
> 
>   qmake automatically adds the plugins to QTPLUGIN that are
> typically needed by the Qt modules used (see QT <http://../qmake/qmake-
> variable-reference.html#qt> ), while more specialized plugins need to be
> added manually.
> 
>   So, according with this, I have no need of importing Qt plugind
> related to Qt Quick Controls 2. Also, I have checked that the
> qmlimportscanner works appropriatelly.
> 
> 
>   The page Deploying Qt Quick Controls 2 Applications says the
> following about static linking:
> 
>   For dynamically built applications, it is not necessary to 
> import
> a specific style that should be usable by that application. For statically 
> built
> applications, Qt's build system must be involved to ensure that QML plugins
> function as expected. Specifically, qmake uses qmlimportscanner to scan the
> QML files in your application for import statements. For this reason, any
> styles that should be usable by a statically built application must explicitly
> import that style. Where the import occurs is up to the developer, but it is
> recommended to follow the approach mentioned in the Deploying an
> Application with Several Styles <http://qtquickcontrols2-
> deployment.html#deploying-an-application-with-several-styles>  section, so
> that only the minimum set of files that are necessary for a particular device
> are deployed.
> 
> 
>   So, they should be built QQC2 statically before (because if not,
> document that makes no sense) and they says that the only requirement is
> explicitly importing the style plugin. Sadly, that does not work for me.
> 
> 
>   El vie., 19 abr. 2019 a las 19:45, Carlos Enrique Pérez Sánchez
> (mailto:ceperez1...@gmail.com> >) escribió:
> 
> 
>   Thanks, Thiago. I will build Qt statically today on Windows,
> and I will try using the system 

Re: [Development] A deployment tool for Linux

[Mitch Curtis]

I think it's better to have a tool that does *something* with a documented, 
limited scope than offer nothing at all.

Then again, I know very little about shipping applications on Linux. I've 
either been building statically (which it turns out you still need to bundle 
libs that are dynamically linked like ICU) or using linuxdeployqt, and I only 
bother supporting Ubuntu because that's what I use.

On 4/10/19, 8:35 PM, "André Pönitz"  wrote:

On Wed, Apr 10, 2019 at 08:13:01AM +0000, Mitch Curtis wrote:
> What do people think about having a deployment tool for Linux?

I, as a person, think that a "deployment tool for Linux" is 
something that spits out packages in half a dozen "native"
distribution package formats.

Collecting "resources that the application uses (like [...]
graphics, [...]" *and dependencies* would be a (important)
step, but not all that it takes.

Andre'


___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] A deployment tool for Linux

[Mitch Curtis]

> -Original Message-
> From: Development  On Behalf Of
> Dan Leinir Turthra Jensen
> Sent: Wednesday, 10 April 2019 11:23 AM
> To: development@qt-project.org; Khuram Ali 
> Subject: Re: [Development] A deployment tool for Linux
> 
> Handily, there has been a concerted effort to create linuxdeploy, which is a
> pluginified and much cleaned up version of linuxdeployqt :)
> https://github.com/linuxdeploy/linuxdeploy

Great! I created a suggestion there:

https://github.com/linuxdeploy/linuxdeploy/issues/73

Though I'm honestly not sure what the practical differences between these two 
are, especially for the average user who just wants to simply deploy their 
application. I've only used linuxdeployqt myself.

> On Wednesday, 10 April 2019 10:15:27 BST Khuram Ali via Development
> wrote:
> > Hi,
> > I think, it is a good idea to have an official deployment tool as we
> > have for windows. linuxdeployqt works but as mentioned earlier slower
> and older.
> > The things can get a bit better.  Regards,Khuram Ali
> >
> >
> > -Ursprüngliche Mitteilung-
> > Von: Mitch Curtis 
> > An: Bogdan Vatra ; development@qt-
> project.org
> >  Verschickt: Mi, 10. Apr. 2019 10:27
> > Betreff: Re: [Development] A deployment tool for Linux
> >
> > > -Original Message-----
> > > From: Bogdan Vatra 
> > > Sent: Wednesday, 10 April 2019 10:22 AM
> > > To: development@qt-project.org
> > > Cc: Mitch Curtis 
> > > Subject: Re: [Development] A deployment tool for Linux
> > >
> > > Hi,
> > >
> > >  Personally I think it's a great idea. I used linuxdeployqt myself
> > > and it
> > >
> > > worked. The only problem I saw it was the speed, it takes quite a
> > > lot to complete (e.g. it took a few minutes, while androiddelopqt
> > > takes less than
> > > 10 seconds). But witl some love I'm pretty sure it can be improved a lot.
> > Yeah I noticed that too.. thought it was a bit odd considering that
> > file operations are usually very quick compared to Windows, whereas
> > windeployqt is actually faster.
> > > Cheers,
> > > BogDan.
> > >
> > > În ziua de miercuri, 10 aprilie 2019, la 11:13:01 EEST, Mitch Curtis
> > > a
> scris:
> > > > What do people think about having a deployment tool for Linux?
> > > > There is an existing community tool based on macdeployqt:
> > > >
> > > > https://github.com/probonopd/linuxdeployqt/
> > > >
> > > > The author has considered the idea in the past:
> > > >
> > > > https://github.com/probonopd/linuxdeployqt/issues/84
> > > >
> > > > A Jira suggestion to track it:
> > > >
> > > > https://bugreports.qt.io/browse/QTBUG-74940
> > > >
> > > > ___
> > > > Development mailing list
> > > > Development@qt-project.org
> > > > https://lists.qt-project.org/listinfo/development
> >
> > ___
> > Development mailing list
> > Development@qt-project.org
> > https://lists.qt-project.org/listinfo/development
> 
> 
> --
> ..dan / leinir..
> http://leinir.dk/
> 
> 
> ___
> Development mailing list
> Development@qt-project.org
> https://lists.qt-project.org/listinfo/development
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] A deployment tool for Linux

[Mitch Curtis]

> -Original Message-
> From: Bogdan Vatra 
> Sent: Wednesday, 10 April 2019 10:22 AM
> To: development@qt-project.org
> Cc: Mitch Curtis 
> Subject: Re: [Development] A deployment tool for Linux
> 
> Hi,
> 
>   Personally I think it's a great idea. I used linuxdeployqt myself and it
> worked. The only problem I saw it was the speed, it takes quite a lot to
> complete (e.g. it took a few minutes, while androiddelopqt takes less than 10
> seconds). But witl some love I'm pretty sure it can be improved a lot.

Yeah I noticed that too.. thought it was a bit odd considering that file 
operations are usually very quick compared to Windows, whereas windeployqt is 
actually faster.

> Cheers,
> BogDan.
> 
> 
> În ziua de miercuri, 10 aprilie 2019, la 11:13:01 EEST, Mitch Curtis a scris:
> > What do people think about having a deployment tool for Linux? There
> > is an existing community tool based on macdeployqt:
> >
> > https://github.com/probonopd/linuxdeployqt/
> >
> > The author has considered the idea in the past:
> >
> > https://github.com/probonopd/linuxdeployqt/issues/84
> >
> > A Jira suggestion to track it:
> >
> > https://bugreports.qt.io/browse/QTBUG-74940
> >
> > ___
> > Development mailing list
> > Development@qt-project.org
> > https://lists.qt-project.org/listinfo/development
> 
> 

___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

[Development] A deployment tool for Linux

[Mitch Curtis]

What do people think about having a deployment tool for Linux? There is an 
existing community tool based on macdeployqt:

https://github.com/probonopd/linuxdeployqt/

The author has considered the idea in the past:

https://github.com/probonopd/linuxdeployqt/issues/84

A Jira suggestion to track it:

https://bugreports.qt.io/browse/QTBUG-74940

___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Supporting helper functions in auto tests by providing throwing Qt Test macros

[Mitch Curtis]

> -Original Message-
> From: Giuseppe D'Angelo 
> Sent: Friday, 5 April 2019 12:39 AM
> To: Mitch Curtis ; development@qt-project.org
> Subject: Re: [Development] Supporting helper functions in auto tests by
> providing throwing Qt Test macros
> 
> Il 03/04/19 13:58, Mitch Curtis ha scritto:
> >>> I have a question regarding this particular implementation, that is,
> >>> why adding dedicated testing functions? Can't you "simply" change the
> >>> currently existing QVERIFY/QCOMPARE to throw exceptions in case of
> >>> failure, instead of returning from the current test function? This
> >>> would achieve major consistency -- simply use the same functions
> >> everywhere, no matter what.
> >>
> >> To me, a change like this (making the existing macros throw) seems more
> like
> >> a Qt 6 thing, but I could be wrong. I only went with new macros because I
> >> was afraid of breaking stuff, but yeah, just changing the existing ones
> would
> >> be ideal.
> 
> If you expect Qt 6 to be as much source compatible with Qt 5 as
> possible, then you can make this change right now as much you can make
> it in Qt 6.
> 
> So, let's discuss: what breaks if you make today's macros throw instead
> of return?

To take the obvious one first: anyone using their own custom macros in helpers 
shouldn't be affected (that's me, currently).

Anyone using Qt macros as they're supposed to be used shouldn't be affected so 
long as we correctly catch the exceptions that we throw. :)

Anyone (incorrectly) using Qt macros in helpers shouldn't be affected so long 
as exceptions are enabled; their tests will just correctly terminate early upon 
failures in those helpers now.

Anyone who is throwing exceptions as part of their tests could be affected, I 
suppose, though your point about handling exceptions correctly and/or the 
opt-in suggestion (e.g. a QTEST_THROWING_MAIN) seems like it would cover it.

Any tests with exceptions explicitly disabled would fail to compile. That might 
be the biggest issue?

> 
> >>
> >>> This idea isn't failproof, as:
> >>>
> >>> 1) it requires the exception to propagate through a direct
> >>> QMetaObject::invoke (that is, whatever mechanism testlib uses to
> >>> invoke the test functions); but that should be already supported and
> >> tested, even.
> >>
> >> Hmm, I hadn't thought about invoke()... hopefully that's not an
> (unsolvable)
> >> issue, otherwise it kinda ruins this whole idea.
> 
> As I said, I believe these codepaths support exceptions (but it's not
> exactly documented). If they don't we can should fix them to do so.
> 
> 
> >>> 2) it causes a minor SC in case the user was doing it wrong --
> >>> "catching all", without rethrowing an unknown exception type. Before,
> >>> a failing test would simply return. With this idea, it would throw,
> >>> and the exception could be caught by the catch all and not used to
> >>> block the execution of the current test function.
> >>>
> >>> The last can be solved in a very simple way (e.g. make this mechanism
> >>> opt-in; and also provide something to the user to test if the current
> >>> catch-all is a Qt test failure, via std::current_exception()).
> >>
> >> What kind of opt-in mechanism did you have in mind?
> 
> Anything that is suitable -- env variables, a different macro to create
> the test's main, something to set in your initTestCase(), a CONFIG
> switch in your .pro, etc.
> 
> Cheers,
> --
> Giuseppe D'Angelo | giuseppe.dang...@kdab.com | Senior Software
> Engineer
> KDAB (France) S.A.S., a KDAB Group company
> Tel. France +33 (0)4 90 84 08 53, http://www.kdab.com
> KDAB - The Qt, C++ and OpenGL Experts

___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Supporting helper functions in auto tests by providing throwing Qt Test macros

[Mitch Curtis]

> -Original Message-
> From: Edward Welbourne
> Sent: Thursday, 4 April 2019 10:51 AM
> To: Mitch Curtis 
> Cc: development@qt-project.org; Joerg Bornemann
> 
> Subject: Re: [Development] Supporting helper functions in auto tests by
> providing throwing Qt Test macros
> 
> Edward Welbourne (Wednesday, 3 April 2019 5:07 PM)
> >> It's probably worth having a macro with which to wrap code, that'll
> >> catch any exception it raises, add the current location to what'll be
> >> output to log the failure and then rethrows.  This would give us the
> >> extra file/line information that your proposed macro gives, compared
> >> to a naive throw/catch solution (where the failure throws and
> >> TestLib's driver system catches, reporting the helper but not its
> >> caller).
> 
> Mitch Curtis (4 April 2019 08:43)
> > What would the effective difference be from QCHECK_EXCEPTION in the
> > proposed patch, in terms of behaviour and output?
> 
> Probably very little - I haven't closely reviewed your QCHECK_EXCEPTION
> patch, nor am I used to using C++ exceptions.  However, in an exception-
> based QTest, QCHECK_EXCEPTION would re-raise the exception it caught
> (after logging where it caught it) rather than returning; and this would mean
> that a helper could apply it also to places where the helper calls a 
> sub-helper
> (see below) to get a full stack-trace for the failure.
> 
> >> I think the idea of rewriting TestLib (including the existing QFAIL,
> >> QCOMPARE, QVERIFY and friends) to use exceptions in Qt6 is a good way
> >> forward; adding some convenience macro for currentTestFailed() checks
> >> is probably sufficient to make helper functions easier to use until
> >> then.
> 
> > The currentTestFailed() macro is a nice idea, but it's not sufficient
> > if your helpers call other functions, because then you have to wrap
> > every call site of those functions with the macro.
> 
> If you're going to have helpers calling sub-helpers in this way, your 
> rationale
> for the primary test function having QCHECK_EXCEPTION add data about its
> call-site of the helper surely applies also to the helper's call to the 
> sub-helper,
> so surely you want to do the same kinds of wrapping with
> QCHECK_EXCEPTION in the helper.  Of course, if you leave it out at some
> layer in an exception-based solution, it only loses you knowledge of part of
> your stack-trace.
> 
> Then again, if you omit a currentTestFailed() check in a helper's call to the
> sub-helper, you just get the rest of the helper run, despite some part of the
> test code having failed already.  That can be a major problem if later parts 
> of
> the helper rely on the sub-helper's success; but "I rely on its success" is
> exactly what you express by wrapping code in the QCHECK macro.  (And, of
> course, this macro can do logging of its call-site just the same as the
> exception-based one can.)
> 
> Whatever we do in Qt5, though, should be designed to be compatible with
> Qt 6 switching to an exception-based QTest; that would surely be a better
> way forward, if we can pull it off,
> 
>   Eddy.

The nice thing about the exception solution is that users can decide whether 
they want to wrap all helper calls in QCHECK_EXCEPTION to get complete stack 
traces for failures, or if they don't want to use it at all, resulting in 
neater code but slightly more difficult traces. If they didn't use 
QCHECK_EXCEPTION at all (and we made sure we caught exceptions correctly in the 
test runner), they'd get output like this:

   FAIL!  : tst_App::openClose(ImageType) 'animationPanel->isVisible()' 
returned FALSE. ()
  Loc: [/home/mitch/dev/slate/tests/shared/testhelper.cpp(1990)]
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Supporting helper functions in auto tests by providing throwing Qt Test macros

[Mitch Curtis]

> -Original Message-
> From: Edward Welbourne
> Sent: Wednesday, 3 April 2019 5:07 PM
> To: Mitch Curtis 
> Cc: development@qt-project.org; Joerg Bornemann
> 
> Subject: Re: [Development] Supporting helper functions in auto tests by
> providing throwing Qt Test macros
> 
> On 4/2/19 5:14 PM, Mitch Curtis wrote:
> > >> As described in https://bugreports.qt.io/browse/QTBUG-66320,
> > >> currently Qt users are on their own if they want to call helper
> > >> functions that can fail a test. The reason is documented:
> > >>
> > >>  Note: This macro can only be used in a test function that is
> > >>  invoked by the test framework.
> 
> Edward Welbourne (3 April 2019 12:07 PM)
> > This note is not strictly true.  You can use it in any function that 
> > returns void.
> > However, the *caller* won't return in response to it, which means it
> > doesn't work *fully* in a helper.
> 
> Mitch Curtis (3 April 2019 12:27) replied:
> > It's true enough that we would never recommend users to use it in a
> > helper function, hence the note.
> 
> There is a whole world of difference between "can only be used in" and "is
> not recommended for use outside".  The note is incorrect: if you use these
> macros inside a helper function, they do cause the test system to know the
> test has failed.  They merely don't cause the caller of the helper to return
> prematurely, unless the helper checks for whether they failed.

It doesn't really matter if they've always been documented that way. Users 
should follow the documentation, not the implementation.

> It's probably worth having a macro with which to wrap code, that'll catch any
> exception it raises, add the current location to what'll be output to log the
> failure and then rethrows.  This would give us the extra file/line information
> that your proposed macro gives, compared to a naive throw/catch solution
> (where the failure throws and TestLib's driver system catches, reporting the
> helper but not its caller).

What would the effective difference be from QCHECK_EXCEPTION in the proposed 
patch, in terms of behaviour and output?

> I think the idea of rewriting TestLib (including the existing QFAIL, QCOMPARE,
> QVERIFY and friends) to use exceptions in Qt6 is a good way forward; adding
> some convenience macro for currentTestFailed() checks is probably sufficient
> to make helper functions easier to use until then.

The currentTestFailed() macro is a nice idea, but it's not sufficient if your 
helpers call other functions, because then you have to wrap every call site of 
those functions with the macro.

>   Eddy.
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Supporting helper functions in auto tests by providing throwing Qt Test macros

[Mitch Curtis]

> -Original Message-
> From: Development  On Behalf Of
> Robin Burchell
> Sent: Wednesday, 3 April 2019 12:53 PM
> To: development@qt-project.org
> Subject: Re: [Development] Supporting helper functions in auto tests by
> providing throwing Qt Test macros
> 
> On Tue, Apr 2, 2019, at 5:17 PM, Mitch Curtis wrote:
> > Quoting the commit message here:
> >
> > WIP: Add _THROW variants to testlib macros
> >
> > This allows using Qt Test macros in helper functions, avoiding the need
> > to write a lot of boilerplate code as seen with alternative approaches.
> 
> Allowing other functions to terminate a test would be great, but I wonder if
> it's worth considering changing the "regular" macros to terminate tests
> through an exception it throws internally, thus avoiding the need to
> introduce a new set of macros.
> 
> You could of course introduce a new macro specifically to throw (and I think
> that would be a good idea to automatically gather __FILE__ and __LINE__ in
> a non-messy way), but this way one could just use the regular macros we
> already know and love in new ways.
> 
> It would mean that tests would need to support exceptions unconditionally,
> but since it's "just" test code, perhaps this isn't that big a problem.

Just replying to say that Robin and I discussed this on IRC and I think it 
would be better than introducing new macros, so long as it's actually 
acceptable to do so.

> --
>   Robin Burchell
>   ro...@crimson.no
> ___
> Development mailing list
> Development@qt-project.org
> https://lists.qt-project.org/listinfo/development
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Supporting helper functions in auto tests by providing throwing Qt Test macros

[Mitch Curtis]

Resending to the list...

> -Original Message-
> From: Mitch Curtis
> Sent: Wednesday, 3 April 2019 1:58 PM
> To: 'Giuseppe D'Angelo' 
> Subject: RE: [Development] Supporting helper functions in auto tests by
> providing throwing Qt Test macros
> 
> > -Original Message-
> > From: Development  On Behalf
> Of
> > Giuseppe D'Angelo via Development
> > Sent: Wednesday, 3 April 2019 1:21 PM
> > To: development@qt-project.org
> > Subject: Re: [Development] Supporting helper functions in auto tests
> > by providing throwing Qt Test macros
> >
> > Hi,
> >
> > Il 02/04/19 17:14, Mitch Curtis ha scritto:
> > > Quoting the commit message here:
> > >
> > >  WIP: Add _THROW variants to testlib macros
> > >
> > >  This allows using Qt Test macros in helper functions, avoiding the 
> > > need
> > >  to write a lot of boilerplate code as seen with alternative 
> > > approaches.
> >
> > I may like the overall approach. However, this would imply that such
> > tests require exceptions / RTTI turned on inside QtTestLib / user
> > code; is it "OK" in the grand scheme of things?
> 
> From my testing, user tests already support exceptions by default, so I guess
> it only affects cases where they have explicitly disabled them?
> 
> For Qt auto tests, exceptions are already enabled by default. The exception
> is testlib selftests, where we need to use CONFIG += exceptions. Quoting
> the comment that Robin found:
> 
> "note that we now load qt_build_config.prf instead of just qmodule.pri,
> which means that exceptions_off is set everywhere. we forcibly re-enable
> them for testcases to minimize the deviation from default 3rd party usage.
> testlib selftests are not qt testcases, so the one that needs exceptions needs
> to enable them explicitly."
> 
> https://code.qt.io/cgit/qt/qtbase.git/commit/?id=6226fcdc
> 
> Whether or not it's acceptable to force users to turn on exception support in
> their tests... I don't know.
> 
> > I have a question regarding this particular implementation, that is,
> > why adding dedicated testing functions? Can't you "simply" change the
> > currently existing QVERIFY/QCOMPARE to throw exceptions in case of
> > failure, instead of returning from the current test function? This
> > would achieve major consistency -- simply use the same functions
> everywhere, no matter what.
> 
> To me, a change like this (making the existing macros throw) seems more like
> a Qt 6 thing, but I could be wrong. I only went with new macros because I
> was afraid of breaking stuff, but yeah, just changing the existing ones would
> be ideal.
> 
> > This idea isn't failproof, as:
> >
> > 1) it requires the exception to propagate through a direct
> > QMetaObject::invoke (that is, whatever mechanism testlib uses to
> > invoke the test functions); but that should be already supported and
> tested, even.
> 
> Hmm, I hadn't thought about invoke()... hopefully that's not an (unsolvable)
> issue, otherwise it kinda ruins this whole idea.
> 
> > 2) it causes a minor SC in case the user was doing it wrong --
> > "catching all", without rethrowing an unknown exception type. Before,
> > a failing test would simply return. With this idea, it would throw,
> > and the exception could be caught by the catch all and not used to
> > block the execution of the current test function.
> >
> > The last can be solved in a very simple way (e.g. make this mechanism
> > opt-in; and also provide something to the user to test if the current
> > catch-all is a Qt test failure, via std::current_exception()).
> 
> What kind of opt-in mechanism did you have in mind?
> 
> >
> > My 2 c,
> > --
> > Giuseppe D'Angelo | giuseppe.dang...@kdab.com | Senior Software
> > Engineer KDAB (France) S.A.S., a KDAB Group company Tel. France +33
> > (0)4
> > 90 84 08 53, http://www.kdab.com KDAB - The Qt, C++ and OpenGL Experts

___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Supporting helper functions in auto tests by providing throwing Qt Test macros

[Mitch Curtis]

> -Original Message-
> From: Edward Welbourne
> Sent: Wednesday, 3 April 2019 12:07 PM
> To: Joerg Bornemann ; Mitch Curtis
> 
> Cc: development@qt-project.org
> Subject: Re: [Development] Supporting helper functions in auto tests by
> providing throwing Qt Test macros
> 
> On 4/2/19 5:14 PM, Mitch Curtis wrote:
> >> As described in https://bugreports.qt.io/browse/QTBUG-66320,
> >> currently Qt users are on their own if they want to call helper
> >> functions that can fail a test. The reason is documented:
> >>
> >>  Note: This macro can only be used in a test function that is
> >>  invoked by the test framework.
> 
> This note is not strictly true.  You can use it in any function that returns 
> void.
> However, the *caller* won't return in response to it, which means it doesn't
> work *fully* in a helper.

It's true enough that we would never recommend users to use it in a helper 
function, hence the note.

Tests should be able to assume that any code that comes after a call to a 
helper means that the helper succeeded. That assumption fails if you were to 
use e.g. QVERIFY in that helper and it failed. I actually wrote that in my 
initial email, but I removed it before sending it because I didn't think anyone 
would be pedantic enough to warrant it.

___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Supporting helper functions in auto tests by providing throwing Qt Test macros

[Mitch Curtis]

> -Original Message-
> From: Joerg Bornemann
> Sent: Wednesday, 3 April 2019 9:55 AM
> To: Mitch Curtis ; development@qt-project.org
> Subject: Re: [Development] Supporting helper functions in auto tests by
> providing throwing Qt Test macros
> 
> On 4/2/19 5:14 PM, Mitch Curtis wrote:
> 
> > As described in https://bugreports.qt.io/browse/QTBUG-66320, currently
> Qt users are on their own if they want to call helper functions that can fail 
> a
> test. The reason is documented:
> >
> >  Note: This macro can only be used in a test function that is invoked by
> the test framework.
> >
> > A common workaround for this is to make the helper function return a bool
> indicating success or failure, and pass in a QString reference which is set to
> the failure message (if any).
> >
> > I don't know how many people reading this have written comprehensive
> auto tests for an application, but not having helper functions is just not an
> option if you want maintainable code.
> 
> This is massively annoying, and also a reason for
>- either writing longish macros that should be functions instead
>- duplicated code in tests.
> 
> > I looked into this briefly during the last hackathon we had, and from what I
> found, throwing an exception was the best approach:
> >
> > https://codereview.qt-project.org/#/c/248490/
> 
> To me this looks promising. I wonder if qtestlib could catch a dedicated
> QTestException instead to avoid the need of the QCHECK_EXCEPTION macro.

That's definitely an option, it just means that you no longer get the 
additional, more specific warning at the location of the call site of the 
helper, which can make finding the exact location of the failure a bit 
confusing if the test calls the helper several times.

For example, this:

   FAIL!  : tst_App::openClose(ImageType) 'animationPanel->isVisible()' 
returned FALSE. ()
  Loc: [/home/mitch/dev/slate/tests/shared/testhelper.cpp(1990)]
   WARNING: tst_App::openClose(ImageType) createNewProject(projectType)
  Loc: [/home/mitch/dev/slate/tests/auto/tst_app.cpp(258)]
  
might become this:

   FAIL!  : tst_App::openClose(ImageType) 'animationPanel->isVisible()' 
returned FALSE. ()
  Loc: [/home/mitch/dev/slate/tests/shared/testhelper.cpp(1990)]
  
On the other hand... we could keep the QCHECK_EXCEPTION macro but make it 
optional to use it, so those who wanted the more exact failure location could 
get it, and those who don't don't need to bother with it. 

> 
> Cheers,
> 
> Joerg
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

[Development] Supporting helper functions in auto tests by providing throwing Qt Test macros

[Mitch Curtis]

As described in https://bugreports.qt.io/browse/QTBUG-66320, currently Qt users 
are on their own if they want to call helper functions that can fail a test. 
The reason is documented:

Note: This macro can only be used in a test function that is invoked by the 
test framework.

A common workaround for this is to make the helper function return a bool 
indicating success or failure, and pass in a QString reference which is set to 
the failure message (if any).

I don't know how many people reading this have written comprehensive auto tests 
for an application, but not having helper functions is just not an option if 
you want maintainable code.

I looked into this briefly during the last hackathon we had, and from what I 
found, throwing an exception was the best approach:

https://codereview.qt-project.org/#/c/248490/

Quoting the commit message here:

WIP: Add _THROW variants to testlib macros

This allows using Qt Test macros in helper functions, avoiding the need
to write a lot of boilerplate code as seen with alternative approaches.

The output for a failed test where a helper was called:

   FAIL!  : tst_App::openClose(ImageType) 'animationPanel->isVisible()' 
returned FALSE. ()
  Loc: [/home/mitch/dev/slate/tests/shared/testhelper.cpp(1990)]
   WARNING: tst_App::openClose(ImageType) createNewProject(projectType)
  Loc: [/home/mitch/dev/slate/tests/auto/tst_app.cpp(258)]

The first two lines is the location of the failure in the helper,
and the second two are the location of the call site of the helper.

TODO:
- Look into ways of reducing the output or making it clear that one
  part is the failure site and the other is the call site
- Add tests
  - Test that uncaught exception (i.e. missing QCHECK_EXCEPTION) is caught
and handled by the test runner

Oh, and throwing an exception like this should be fine since it's not 
travelling through Qt code.

I'm curious what other people think about this idea?
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Switching from create_changelog.pl to createchangelog for change log generation

[Mitch Curtis]

> -Original Message-
> From: Development  On Behalf Of
> Shawn Rutledge
> Sent: Tuesday, 2 April 2019 1:46 PM
> To: development@qt-project.org
> Subject: Re: [Development] Switching from create_changelog.pl to
> createchangelog for change log generation
> 
> 
> > On 2 Apr 2019, at 11:40, Mitch Curtis  wrote:
> > ...
> > 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_ch
> > angelog.pl [2]
> > https://code.qt.io/cgit/qt/qtqa.git/tree/src/createchangelog
> >  dev.txt>___
> > 
> > Development mailing list
> > Development@qt-project.org
> > https://lists.qt-project.org/listinfo/development
> 
> Yeah thanks to Simon for starting that and for writing it in go.  ;-)
> 
> I added that feature to get all the bugs as well as the changelog entries: if 
> a
> Fixes or Task-number is found, it queries Jira for the bug subject line, and
> also includes the descriptive part of the commit message.  The result is
> verbose, but I prefer condensing it down rather than having to open up bugs
> individually in a browser whenever the commit message doesn’t tell the
> whole story.  Of course I also remove non-user-facing entries like doc fixes,
> fixes to really short-term regressions that didn’t get into a release, deep
> internal stuff etc.  And I have to reorganize them because the tool doesn’t
> detect which fixes are to QtQuick and which are to QtQML for example (let
> alone any finer-grained categories), although it could maybe be enhanced by
> looking at which files got changed.

Thanks!

> I found one more issue though when I was re-generating the 5.9.8
> changelog: it got confused that there were tags on newer branches.  I had to
> delete all the 5.12.x, 5.11.x and 5.10.x tags from my local checkout so that 
> it
> would see that 5.9.8 is the newest.  But I’m sure that can be fixed.
> 
> After that, we could indeed try using it for the mass changelog generation, as
> long as the other maintainers are OK with the verbosity that it generates.

Hmm, OK, so it's not quite ready to be used yet.

> ___
> Development mailing list
> Development@qt-project.org
> https://lists.qt-project.org/listinfo/development
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

[Development] Switching from create_changelog.pl to createchangelog for change log generation

[Mitch Curtis]

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 
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 

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 

Re: [Development] Qt Quick Templates 2 from C++

[Mitch Curtis]

I'm mostly going off what JP had in mind, which are the following:

- https://bugreports.qt.io/browse/QTBUG-67062: Add full/public theming support 
for QQC2 styles
- https://bugreports.qt.io/browse/QTBUG-73944: Make QQuickControl public
- https://bugreports.qt.io/browse/QTBUG-66829: Add IconImage to QtQuick core

At some point I plan on doing these. Patches are welcome too. :)

On 3/4/19, 7:02 PM, "Pier Luigi Fiorini"  wrote:

Mitch, do you have plans?

Il giorno gio 14 feb 2019 alle ore 20:12 drwho  ha 
scritto:


On 2019-02-14 5:45 a.m., Pier Luigi Fiorini wrote:
> Hi,
>
> I'd like to know if you have plans of making Qt Quick Templates 2 a 
> public API and allow people to write new controls with C++ without 
> using a private library.

+1 for this and also for a public api for c++ Qt Quick Controls 2 
widgets.  Our management killed our Qt desktop app in favor of HTML 5 
electron garbage.

Jon

___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development






-- 
https://liri.io






___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] QtQuick.Layouts and content margins

[Mitch Curtis]

> -Original Message-
> From: Development  On Behalf Of
> Alberto Mardegan
> Sent: Monday, 25 February 2019 1:05 PM
> To: development@qt-project.org
> Subject: Re: [Development] QtQuick.Layouts and content margins
> 
> On 25/02/19 11:23, Mitch Curtis wrote:
> > So would it look something like this?
> >
> > // implicit size is 118 x 64
> > ColumnLayout {
> > defaultLeftMargin: 12
> > defaultRightMargin: 12
> > defaultBottomMargin: 12
> > defaultTopMargin: 12
> >
> > // implicit size is 100 x 40
> > Button {
> > Layout.leftMargin: 6 // override default
> > }
> > }
> 
> Yes. Sounds good? :-)

My only issue with it is that I don't know if it will see much use outside of 
your use case. Usually if all items in a layout have the same margins, you 
would just apply those margins to the layout managing them instead. While I 
appreciate that that won't work in your case (because the Layout might not be 
within another, so the attached margin properties won't have any effect, and 
anchor margins are not included in its implicit size), I do wonder if there are 
other approaches you could take. What other options have you considered? What 
about just making the API that provides the style's margins available to the 
user so they can do it themselves?

Also, it would be good if you could provide some examples of other (more 
common) use cases that would benefit from this.

CCing Jan Arve since he wrote the code.

> Ciao,
>   Alberto
> 
> --
> http://www.mardy.it - Geek in un lingua international
> ___
> Development mailing list
> Development@qt-project.org
> https://lists.qt-project.org/listinfo/development
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] QtQuick.Layouts and content margins

[Mitch Curtis]

> -Original Message-
> From: Development  On Behalf Of
> Alberto Mardegan
> Sent: Sunday, 24 February 2019 12:29 PM
> To: development@qt-project.org
> Subject: [Development] QtQuick.Layouts and content margins
> 
> Hi there!
>   I'm working on a desktop style for QtQuick.Controls 2 [1], and I'm currently
> investigating the issue of layouts. My current approach is to define my own
> ColumnLayout element like this:
> 
> ==
> import QtQuick.Layouts 1.2
> import it.mardy.Desktop.private 1.0
> 
> ColumnLayout {
> anchors {
> leftMargin: Style.layoutLeftMargin
> topMargin: Style.layoutTopMargin
> rightMargin: Style.layoutRightMargin
> bottomMargin: Style.layoutBottomMargin
> }
> spacing: Style.layoutVerticalSpacing } ==
> 
> where the Style element is a singleton which retrieves the default layout
> margins encoded in the QStyle.
> 
> Now, there's are a couple of problems with this solution: if the user of my
> layout does not set the "anchors.fill" property, but instead positions the
> layout using "x", "y", "width" or "heigh" properties, the margins will be
> ignored.
> The other (bigger) problem is that the implicit size of my layout is
> wrong: it should include the margins!
> 
> My proposal is to add a set of "margins" properties to QtQuick.Layout's
> items, which would set the default content margins for all child items that
> don't explicitly set their own via the attached Layout properties.
> These margins would also be taken into account when computing the implicit
> size of the layout.

So would it look something like this?

// implicit size is 118 x 64
ColumnLayout {
defaultLeftMargin: 12
defaultRightMargin: 12
defaultBottomMargin: 12
defaultTopMargin: 12

// implicit size is 100 x 40
Button {
Layout.leftMargin: 6 // override default
}
}

> If this looks like a good idea, I can try and propose a patch.
> 
> Ciao,
>   Alberto
> 
> [1]: https://gitlab.com/mardy/qqc2-desktop
> 
> --
> http://www.mardy.it - Geek in un lingua international
> ___
> Development mailing list
> Development@qt-project.org
> https://lists.qt-project.org/listinfo/development
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Maintainers, your action needed: Qt 5.12.2 changes files

[Mitch Curtis]

> -Original Message-
> From: Development  On Behalf Of
> Shawn Rutledge
> Sent: Thursday, 21 February 2019 1:45 PM
> To: development@qt-project.org
> Subject: Re: [Development] Maintainers, your action needed: Qt 5.12.2
> changes files
> 
> 
> > On 21 Feb 2019, at 12:47, Cristián Maureira-Fredes  fre...@qt.io> wrote:
> >
> > Hello,
> >
> > so, we agree the Go one (qtqa) is the recommended one?
> >
> > Time ago, I was directed to this one:
> > http://code.qt.io/cgit/qtsdk/qtsdk.git/tree/packaging-tools/create_cha
> > ngelog.pl and ended up suggesting this one as a replacement for the Qt
> > for Python project: https://codereview.qt-project.org/#/c/252162/
> >
> > I understand it is better to focus on one script and improve it so
> > that's why I would like to know which is the preferred option.
> 
> I wanted to automate the manual work I’d been doing for every release to
> get most of the bug fixes listed in the changelog (including those which don’t
> have changelog entries in the commit message); and I’d rather write Go than
> Perl, so I did a couple of patches on that tool.  (The last change is just now
> integrated.)  It works for me, but it intentionally strays on the side of “too
> much information.”  It combines the git commit message with the Jira bug
> description, so those entries always needs editing to get a concise changelog
> message.  For me that’s fine, because neither Jira bug descriptions nor
> commit messages are written in the right style for a changelog, but at least 
> all
> the information gets into the file so that I don’t have to individually look 
> up
> bugs on Jira to find out what certain changes were really about (as long as 
> the
> subject is descriptive enough).
> 
> So I don’t know if every maintainer would like to work that way; maybe some
> would rather stray on the side of having the generation mostly automated
> and not adding every bug fix?  But in practice it seems e.g. the qtbase
> changelog has always needed plenty of manual editing.  So having the
> changelog a bit rough at first won’t be any more work than what’s been
> going on.
> 
> https://codereview.qt-project.org/#/c/253930/ PS2 is currently showing
> exactly the output of this tool, so you can compare PS1 to PS2 to see the
> difference.
> 
> The boilerplate does need a little work.  So far I didn’t think we would
> actually use this tool for the whole log, I just wanted to use it to get some
> more entries to blend into the existing log.  But if we want to use it for 
> real,
> fixing it up a little more won’t be hard.

I think this is a good addition. I also found myself looking up bug reports to 
see how else I could phrase the message. At a minimum the tense has to be fixed 
for each entry ("Fix" or other verb => "Fixed") anyway.

> ___
> Development mailing list
> Development@qt-project.org
> https://lists.qt-project.org/listinfo/development
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Maintainers, your action needed: Qt 5.12.2 changes files

[Mitch Curtis]

> -Original Message-
> From: Cristián Maureira-Fredes
> Sent: Thursday, 21 February 2019 12:47 PM
> To: Mitch Curtis ; Jani Heikkinen ;
> development@qt-project.org
> Subject: Re: [Development] Maintainers, your action needed: Qt 5.12.2
> changes files
> 
> Hello,
> 
> so, we agree the Go one (qtqa) is the recommended one?

I think we need to wait to see what Jani says, but I added a section to the Qt 
5 Releasing page in anticipation. :D

https://wiki.qt.io/Qt5Releasing#Change_log_generation

> Time ago, I was directed to this one:
> http://code.qt.io/cgit/qtsdk/qtsdk.git/tree/packaging-
> tools/create_changelog.pl
> and ended up suggesting this one as a replacement for the Qt for Python
> project: https://codereview.qt-project.org/#/c/252162/
> 
> I understand it is better to focus on one script and improve it so that's why 
> I
> would like to know which is the preferred option.
> 
> Cheers
> 
> ________
> From: Development  on behalf of
> Mitch Curtis 
> Sent: 21 February 2019 11:46
> To: Jani Heikkinen; development@qt-project.org
> Subject: Re: [Development] Maintainers, your action needed: Qt 5.12.2
> changes files
> 
> > -Original Message-
> > From: Jani Heikkinen
> > Sent: Thursday, 21 February 2019 11:06 AM
> > To: Mitch Curtis ; development@qt-project.org
> > Subject: RE: [Development] Maintainers, your action needed: Qt 5.12.2
> > changes files
> >
> > > -Original Message-
> > > From: Mitch Curtis 
> > > Sent: torstai 21. helmikuuta 2019 11.21
> > > To: Mitch Curtis ; Jani Heikkinen
> > > ; development@qt-project.org
> > > Subject: RE: [Development] Maintainers, your action needed: Qt
> > > 5.12.2 changes files
> > >
> > >
> > >
> > > > -Original Message-
> > > > From: Development  On
> Behalf
> > > Of
> > > > Mitch Curtis
> > > > Sent: Thursday, 21 February 2019 9:33 AM
> > > > To: Jani Heikkinen ;
> > > > development@qt-project.org
> > > > Subject: Re: [Development] Maintainers, your action needed: Qt
> > > > 5.12.2 changes files
> > > >
> > > > > -Original Message-
> > > > > From: Development  On
> > Behalf
> > > > Of
> > > > > Jani Heikkinen
> > > > > Sent: Thursday, 21 February 2019 9:19 AM
> > > > > To: development@qt-project.org
> > > > > Subject: [Development] Maintainers, your action needed: Qt
> > > > > 5.12.2 changes files
> > > > >
> > > > > Hi,
> > > > > Initial ones here: https://codereview.qt-
> > > > >
> project.org/#/q/message:%22Add+changes+file+for+Qt+5.12.2%22,n,z
> > > > >
> > > > > Please take it over, do needed modifications and get '+2' during
> > > > > this
> > > week.
> > > >
> > > > Do we have a script that generates the change logs? I see that
> > > > qtbase has entries for bug fixes with the task number:
> > > >
> > > > http://code.qt.io/cgit/qt/qtbase.git/tree/dist/changes-5.12.1/?h=v5.
> > > > 12
> > > > .1
> > > >
> > > > I'd like to get the same for the modules that I maintain. I'm
> > > > guessing that one was done manually, but I'd like to try to
> > > > automate it (even if it still requires some manual editing afterwards).
> > > >
> > > > I checked qtrepotools.git but didn't find anything. Simon created
> > > > one, but says that it's not the same one in use by the release team:
> > > >
> > > > http://code.qt.io/cgit/qt/qtqa.git/tree/src/createchangelog
> > >
> > > Replying to myself to say that this tool works really well, and is
> > > very easy to use (especially with
> > > https://codereview.qt-project.org/#/c/253973/). Can the initial
> > > change logs
> > be created with it?
> >
> > We will test this and use it in coming releases if it works better
> > that current one
> 
> For what it's worth, the only negative difference I saw was that it
> (createchangelog) generates this:
> 
> Qt 5.12.2 is a bug-fix release. It maintains both forward and backward
> compatibility (source and binary) with Qt 5.12.1.
> 
> whereas the current one generates this:
> 
> Qt 5.12.2 is a bug-fix release. It maintains both forward and backward
> compatibility (source and binary) with Qt 5.12.0 through 5.12.1.
> 
> Doesn't seem that important though?
> 
> > br,
> > Jani
> >
> > >
> > > > > br,
> > > > > Jani Heikkinen
> > > > > Release Manager
> > > > > ___
> > > > > Development mailing list
> > > > > Development@qt-project.org
> > > > > https://lists.qt-project.org/listinfo/development
> > > > ___
> > > > Development mailing list
> > > > Development@qt-project.org
> > > > https://lists.qt-project.org/listinfo/development
> ___
> Development mailing list
> Development@qt-project.org
> https://lists.qt-project.org/listinfo/development
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Maintainers, your action needed: Qt 5.12.2 changes files

[Mitch Curtis]

> -Original Message-
> From: Jani Heikkinen
> Sent: Thursday, 21 February 2019 11:06 AM
> To: Mitch Curtis ; development@qt-project.org
> Subject: RE: [Development] Maintainers, your action needed: Qt 5.12.2
> changes files
> 
> > -Original Message-
> > From: Mitch Curtis 
> > Sent: torstai 21. helmikuuta 2019 11.21
> > To: Mitch Curtis ; Jani Heikkinen
> > ; development@qt-project.org
> > Subject: RE: [Development] Maintainers, your action needed: Qt 5.12.2
> > changes files
> >
> >
> >
> > > -Original Message-
> > > From: Development  On Behalf
> > Of
> > > Mitch Curtis
> > > Sent: Thursday, 21 February 2019 9:33 AM
> > > To: Jani Heikkinen ;
> > > development@qt-project.org
> > > Subject: Re: [Development] Maintainers, your action needed: Qt
> > > 5.12.2 changes files
> > >
> > > > -Original Message-
> > > > From: Development  On
> Behalf
> > > Of
> > > > Jani Heikkinen
> > > > Sent: Thursday, 21 February 2019 9:19 AM
> > > > To: development@qt-project.org
> > > > Subject: [Development] Maintainers, your action needed: Qt 5.12.2
> > > > changes files
> > > >
> > > > Hi,
> > > > Initial ones here: https://codereview.qt-
> > > > project.org/#/q/message:%22Add+changes+file+for+Qt+5.12.2%22,n,z
> > > >
> > > > Please take it over, do needed modifications and get '+2' during
> > > > this
> > week.
> > >
> > > Do we have a script that generates the change logs? I see that
> > > qtbase has entries for bug fixes with the task number:
> > >
> > > http://code.qt.io/cgit/qt/qtbase.git/tree/dist/changes-5.12.1/?h=v5.
> > > 12
> > > .1
> > >
> > > I'd like to get the same for the modules that I maintain. I'm
> > > guessing that one was done manually, but I'd like to try to automate
> > > it (even if it still requires some manual editing afterwards).
> > >
> > > I checked qtrepotools.git but didn't find anything. Simon created
> > > one, but says that it's not the same one in use by the release team:
> > >
> > > http://code.qt.io/cgit/qt/qtqa.git/tree/src/createchangelog
> >
> > Replying to myself to say that this tool works really well, and is
> > very easy to use (especially with
> > https://codereview.qt-project.org/#/c/253973/). Can the initial change logs
> be created with it?
> 
> We will test this and use it in coming releases if it works better that 
> current
> one

For what it's worth, the only negative difference I saw was that it 
(createchangelog) generates this:

Qt 5.12.2 is a bug-fix release. It maintains both forward and backward
compatibility (source and binary) with Qt 5.12.1.

whereas the current one generates this:

Qt 5.12.2 is a bug-fix release. It maintains both forward and backward
compatibility (source and binary) with Qt 5.12.0 through 5.12.1.

Doesn't seem that important though?

> br,
> Jani
> 
> >
> > > > br,
> > > > Jani Heikkinen
> > > > Release Manager
> > > > ___
> > > > Development mailing list
> > > > Development@qt-project.org
> > > > https://lists.qt-project.org/listinfo/development
> > > ___
> > > Development mailing list
> > > Development@qt-project.org
> > > https://lists.qt-project.org/listinfo/development
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Maintainers, your action needed: Qt 5.12.2 changes files

[Mitch Curtis]

> -Original Message-
> From: Development  On Behalf Of
> Mitch Curtis
> Sent: Thursday, 21 February 2019 9:33 AM
> To: Jani Heikkinen ; development@qt-project.org
> Subject: Re: [Development] Maintainers, your action needed: Qt 5.12.2
> changes files
> 
> > -Original Message-
> > From: Development  On Behalf
> Of
> > Jani Heikkinen
> > Sent: Thursday, 21 February 2019 9:19 AM
> > To: development@qt-project.org
> > Subject: [Development] Maintainers, your action needed: Qt 5.12.2
> > changes files
> >
> > Hi,
> > Initial ones here: https://codereview.qt-
> > project.org/#/q/message:%22Add+changes+file+for+Qt+5.12.2%22,n,z
> >
> > Please take it over, do needed modifications and get '+2' during this week.
> 
> Do we have a script that generates the change logs? I see that qtbase has
> entries for bug fixes with the task number:
> 
> http://code.qt.io/cgit/qt/qtbase.git/tree/dist/changes-5.12.1/?h=v5.12.1
> 
> I'd like to get the same for the modules that I maintain. I'm guessing that 
> one
> was done manually, but I'd like to try to automate it (even if it still 
> requires
> some manual editing afterwards).
> 
> I checked qtrepotools.git but didn't find anything. Simon created one, but
> says that it's not the same one in use by the release team:
> 
> http://code.qt.io/cgit/qt/qtqa.git/tree/src/createchangelog

Replying to myself to say that this tool works really well, and is very easy to 
use (especially with https://codereview.qt-project.org/#/c/253973/). Can the 
initial change logs be created with it?

> > br,
> > Jani Heikkinen
> > Release Manager
> > ___
> > Development mailing list
> > Development@qt-project.org
> > https://lists.qt-project.org/listinfo/development
> ___
> Development mailing list
> Development@qt-project.org
> https://lists.qt-project.org/listinfo/development
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Maintainers, your action needed: Qt 5.12.2 changes files

[Mitch Curtis]

> -Original Message-
> From: Development  On Behalf Of
> Jani Heikkinen
> Sent: Thursday, 21 February 2019 9:19 AM
> To: development@qt-project.org
> Subject: [Development] Maintainers, your action needed: Qt 5.12.2 changes
> files
> 
> Hi,
> Initial ones here: https://codereview.qt-
> project.org/#/q/message:%22Add+changes+file+for+Qt+5.12.2%22,n,z
> 
> Please take it over, do needed modifications and get '+2' during this week.

Do we have a script that generates the change logs? I see that qtbase has 
entries for bug fixes with the task number:

http://code.qt.io/cgit/qt/qtbase.git/tree/dist/changes-5.12.1/?h=v5.12.1

I'd like to get the same for the modules that I maintain. I'm guessing that one 
was done manually, but I'd like to try to automate it (even if it still 
requires some manual editing afterwards).

I checked qtrepotools.git but didn't find anything. Simon created one, but says 
that it's not the same one in use by the release team:

http://code.qt.io/cgit/qt/qtqa.git/tree/src/createchangelog

> br,
> Jani Heikkinen
> Release Manager
> ___
> Development mailing list
> Development@qt-project.org
> https://lists.qt-project.org/listinfo/development
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Qt QML Maintainer change

[Mitch Curtis]

> -Original Message-
> From: Development  On Behalf Of
> Simon Hausmann
> Sent: Monday, 18 February 2019 2:25 PM
> To: development@qt-project.org
> Subject: [Development] Qt QML Maintainer change
> 
> Hi,
> 
> I'd like to step down as the maintainer of the Qt QML module and pass the
> torch on to Ulf Hermann.
> 
> He has been contributing to the module since 2013 with countless features,
> bug fixes, reviews and re-designs. He's absolutely awesome to work with
> and his lines break sharply at 100 characters ;-)
> 
> 
> Simon

Thank you for all of your help with QML engine stuff, Simon!

+1 for Ulf, he seems to know what he's doing. :D
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Mailing list archive annoyance

[Mitch Curtis]

> -Original Message-
> From: Development  On Behalf Of
> Christian Gagneraud
> Sent: Wednesday, 30 January 2019 10:30 AM
> To: interest ; development  project.org>
> Subject: [Development] Mailing list archive annoyance
> 
> Hi all,
> 
> I do not know what is going on with the mailing list archive, but this is 
> getting
> frustrating.
> Trying to move forward and keep positive, i would like to report on
> a(nother) use case here: https://bugreports.qt.io/browse/QTBUG-71225
> This bug report starts with a couple of links to the Qt Interest ML archive, 
> in
> an attempt to give some background.This qt.io Jira ticket is linked into our
> own bug tracking system. Yet, all these mailing list archive hyperlinks yield 
> a
> so-called HTTP 404.This is quite annoying. History seems to be gone for ever.
> 
> Can you guys recover the mailing list archive, like nobody will ever notice
> what has happened? Can you do that? Yes or No?
> 
> Or should we switch (back) the Qt mailing list management to the
> community?
> 
> Who is in charge of the qt-project.org domain?

It's being looked into apparently:

https://bugreports.qt.io/browse/QTQAINFRA-2553

> Chris
> ___
> Development mailing list
> Development@qt-project.org
> https://lists.qt-project.org/listinfo/development
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Proposal: New branch model

[Mitch Curtis]

> -Original Message-
> From: Development  On Behalf Of
> Jedrzej Nowacki
> Sent: Monday, 28 January 2019 3:54 PM
> To: Robert Loehning 
> Cc: development@qt-project.org
> Subject: Re: [Development] Proposal: New branch model
> 
> On Monday, January 28, 2019 2:38:44 PM CET Robert Loehning wrote:
> > Am 28.01.2019 um 14:09 schrieb Jedrzej Nowacki:
> >
> > > On Friday, January 25, 2019 3:23:36 PM CET Robert Loehning wrote:
> > >
> > >>> Testing whether the bug that I’m fixing exists in dev or not is
> > >>> part of the drill of fixing bug, isn’t it? Why would you spend
> > >>> time on fixing something in 5.12 without checking whether the
> > >>> issue is still present in the latest codebase? Perhaps the issue
> > >>> has been fixed already, just without the author considering it
> > >>> relevant for 5.12 (perhaps for good reasons).
> > >>
> > >> Why would somebody who maintains a project on Qt5 but made the
> > >> decision to not migrate it to Qt6 care about fixing the latter?
> > >>
> > >>
> > >>
> > >> Cheers,
> > >> Robert
> > >
> > >
> > > Project that is not being updated is not maintained. Not maintained
> > > projects
>  should not take part of the mainstream.
> > >
> > > Cheers,
> > >
> > >Jędrek
> > >
> > >
> > >
> >
> >
> > I mean an external project which is based on Qt, like some commercial
> > application. Say they decided - for good or bad reasons - that they
> > will not migrate to Qt 6, but they require a fix in Qt 5. They even
> > provide this fix, but why would they care about making it work in Qt 6?
> >
> > Cheers,
> > Robert
> 
> We have the same problem right now, just in the opposite direction. One
> want to fix version 5.9, why the person should help with merging and solving
> problems in 5.12? At least the problem would be visible in gerrit as an not
> staged change.

Don't changes have to go to 5.12 first and then be backported to 5.9 with the 
current model?
 
> Cheers,
>   Jędrek
> 
> 
> ___
> Development mailing list
> Development@qt-project.org
> https://lists.qt-project.org/listinfo/development
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Archiving is working

[Mitch Curtis]

> -Original Message-
> From: Development  On Behalf Of
> Giuseppe D'Angelo via Development
> Sent: Friday, 25 January 2019 7:23 PM
> To: development@qt-project.org
> Subject: Re: [Development] Archiving is working
> 
> Il 25/01/19 18:41, Edward Welbourne ha scritto:
> > The pages have all been updated and had their URLs changed.
> > Or are you trying to tell me something else ?
> > I'm not sure I fully understand.
> 
> Yes. And that's the problem. It *MUST NOT* happen. Links to mails in the
> mailing list are found in commit messages, on the bugtracker, and so on.
> Breaking them is a big no-no-no.

Another +1. I don't want my commit messages to become useless because of broken 
mailing list archive links. I'm pretty sure I also linked to a mailing list 
thread when I did a bulk Qt 4 jira task cleanup, so if that link is now broken 
it's broken in hundreds of comments.

___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Qt modules, API changes and Qt 6

[Mitch Curtis]

> -Original Message-
> From: Development  On Behalf Of
> Frederik Gladhorn
> Sent: Friday, 25 January 2019 2:12 PM
> To: development@qt-project.org
> Subject: [Development] Qt modules, API changes and Qt 6
> 
> Hi all,
> 
> I'd like to start another discussion around our development workflow.
> We arrived at our current model of Qt modules (in the git repository sense)
> and using qt5.git as a container for all of them through a series of steps and
> changes. Mix in the evolution of the testing environment over time and we
> have something that has grown in interesting ways.
> 
> I will try to describe the problem in this mail. I also have discussed with a
> bunch of people (inside The Qt Company) about potential solutions. After
> brainstorming and some back and forth, we had five suggestions on a
> whiteboard and picked our favorite. In a separate mail I'll try to describe
> these and what we concluded with as our favorite. All of this is up for
> discussion, so I'm hoping for someone to come up with even better ideas.
> 
> 
> The problem:
> 
> qt5.git serves several purposes today, for example:
> - it contains a few binaries needed for Windows development
> - it gives a definition of which modules make up a Qt release
> - it collects sets of revisions which work together (because they were tested
> with each other)
> - it has a bit of build system infrastructure to build all of this
> 
> In my opinion there are a few issues with what we have:
> - updating qt5.git (and thus making releases) is cumbersome
> - it's unclear for many people what a module is tested against in the CI
>   (its dependencies are checked out at the revisions specified in qt5.git, not
> the latest revisions of the corresponding branch)
> - we have more products, such as Qt for Automotive, Automation, Device
> Creation, should those have qt5-special-purpose repositories?
> - modules outside of qt5.git get different treatment, making it hard to
> include new modules
> 
> In the light of Qt 6, there is also the question of how we can allow making
> source incompatible changes in an easy fashion.
> Why is it hard to do source incompatible changes? Let's say we want to
> rename a function in qtbase. qtdeclarative is the only user of that function 
> in
> our code-base. Today we can do that in five easy steps:
> 
> 1) add function with new name in qtbase, do not remove the old one yet
> 2) update qt5.git
> 3+4) move qtdeclarative to the new function name; remove the old
> 3+function from
> qtbase
> 5) after 3 and 4 are in, update qt5.git
> 
> Five commits, two of which are qt5.git updates, is a lot to ask for. And this 
> is
> assuming that the contributor knows of this work-flow and does everything
> by the unwritten book. In the unhappy case, we do an attempt of changing
> qtbase directly, then we notice qt5.git doesn't update and we need to bring
> back the old function name first. Another aspect is that even after 5, if this
> happened to be a branch other than dev, we might face all of these
> problems while doing merges to the next branch again (been there, done
> that, and so has Liang).
> 
> This has led to a mess in how we create releases and how we test things. It
> creates a very hard and artificial line of what's part of the core product and
> what is outside and testing in the CI is also majorly influenced by this.
> Modules are not self-contained (since the fine-grained dependencies are
> specified in qt5.git). We don't know how to cleanly handle dependencies for
> modules outside. We have trouble getting some of the releases out, since Qt
> for Device Creation follows slightly different routines than Qt for 
> Application
> Development
> 
> On a semi-related note, running git-bisect on anything but qtbase is a
> science, hard enough to at least put me off.

Indeed. For anyone who might be interested, I've found the best way to bisect 
leaf modules like qtquickcontrols2 (which relies on qtdeclarative and qtbase) 
is to use qt5.git submodule updates:

1. Clone qt5.git, init only the modules you're interested in.
2. Look for qt5.git submodule updates (e.g. by searching in Gerrit) that 
happened before and after the issue started happening. Use these as the 
good/bad commits for the bisect.
3. Run "git submodule update --init qtbase qtxmlpatterns qtdeclarative" 
(passing in each module you're interested in) after each bisect round to 
checkout the relevant submodule commits for that qt5.git commit.
4. Wipe the Qt build, configure and build it, then test.
5. Once you've found the bad qt5.git commit, look through (bisect if possible) 
the range of commits for that in the relevant submodules.

This is super slow, but it's the most reliable way, avoiding compiler errors 
etc. that you get from mixing and matching commits across modules. Luckily it's 
not always necessary.

> Cheers,
> Frederik
> 
> 
> 
> ___
> Development mailing list
> Development@qt-project.org
> 

Re: [Development] Proposal: New branch model

[Mitch Curtis]

> -Original Message-
> From: Development  On Behalf Of
> Jedrzej Nowacki
> Sent: Wednesday, 23 January 2019 4:51 PM
> To: development@qt-project.org
> Subject: [Development] Proposal: New branch model
> 
> Hi,
> 
>   It is time to rethink our branch model. We are approaching Qt6
> development and I'm worried that what we have now, will simply not scale.
> As you know, our branch model is mainly(*) based on merging from stable up
> to development branches. In general, it is a very good model, which make
> sure that release branches are not getting obsolete too quickly, that most of
> the fixes are in the right places, that every commit is only once in the git
> history. It is a very clean model. It is also a very slow model, with a single
> point of failure.
> 
>   It is hard to maintain:
>   My impression is that the current model works great for a single release
> branch, but we have: 5.6 5.9 5.12 and soon we will have 5.13, that is without
> counting temporary patch level branches. Merging through them is hard, we
> already had to use "cherry-pick mode" in some places. When we add to the
> picture dev and qt6 branches, merging will be very, very hard. It is 
> practically
> a full time job to update qt5 repository and coordinate all the merges now
> (thank you Liang!), shortly after qt6 branch opening amount of work will be
> much bigger.
>   It is slow:
>   The merges take time. We produce a lot of code, we have a lot of tests that
> needs to pass. Even single failure delays merge propagation by at least one
> day. If by bad luck, the merge contains some API incompatible changes an
> intermediate jump through Qt5 integration is required, that adds at least 3
> days of delay.
> 
>   --
> 
>   Proposal in short: let's use cherry-pick mode everywhere.
> 
>   All(**) changes would go to dev. From which they would be automatically
> cherry-picked by a bot to other branches. The decision to which branch
> cherry- pick, would be taken based on a tag in the commit message. We
> could add a footer that marks the change risk level as in quip-5 
> (http://quips-
> qt-io.herokuapp.com/quip-0005.html), so for example "dev", "stable", "LTS".
> By default everything would be cherry-picked to qt6 branch unless "no-
> future" tag would be given. Of course we can bike-shed about the tag
> names.
> 
>   Advantages:
>   - no waiting for merges, a fix can be used right away after integration

Sounds nice!

>   - faster propagation of fixes targeting all branches, as there are no merges
> of merges
>   - simpler for new contributors, always push to dev
>   - in most cases a reviewer does no need to know what the current version
> number is
>   - conflict resolution is distributed and affects mostly the author of the
> change

Do I understand this correctly: conflicts would happen when the initial patch 
is pushed to dev and on each subsequent cherry-pick that the bot pushes?

>   - documents a change intent, which may be useful for people keeping own
> forks
>   - over time with increased amount of conflicts old branches, in natural way,
> stay untouched

What does this mean?

>   Disadvantages:
>   - git history would be a bit wilder, "git branch --contains" would not work

This would be a bit of a pain for me personally, as I use this command often to 
e.g. know if I have a certain fix.

Would there be an alternative command?

>   - commit messages in some branches would have kind of ugly footer as an
> effect of "cherry-pick -x"
>   - there is a chance, that some cherry-picked commits may be left forgotten
> in gerrit after a failed integration
> 
>   Bot details:
> 
>   The bot would listen only for changes in dev, in some unusual cases one
> could target an other branch directly, but bot would not trigger automatic
> cherry-pick(***). The bot would wait for a successful dev integration before
> creating cherry-picked changes. The bot would use cherry-pick -x to annotate
> the origin patch. After the cherry-pick creation, it would push it to gerrit,
> +2 and stage once. It would be up to the author to re-stage in case of
> flakiness. In case of a cherry-pick conflict it should push unresolved 
> conflict to
> gerrit and add all reviewers and author to handle the issue.
> 
> The list below shows branch targets for automatic cherry-pick based on given
> tag.
> 
> dev (qt6)
> stable (qt6, 5.13)
> stable, no-future (5.13)
> LTS (qt6, 5.13, 5.12)
> LTS-strict (qt6, 5.13, 5.12, 5.9)
> LTS, no-future (5.13, 5.12)
> 
> That is assuming that we have branches: qt6  dev  5.13  5.13.q  5.12  5.12.w
> 5.9  5.9.e  5.6  5.6.r
> I think we should assume that patch level branches, as well LTS in very strict
> state, are handled manually.
> 
> 
>   Creation of new branches:
> We would branch more or less as usual. The only difference from the current
> system is that we would not need the back merge / soft branching anymore,
> but of course we could keep it.
> 
> 

Re: [Development] Stepping down as the Qt Quick Controls 2 maintainer

[Mitch Curtis]

Thanks JP!

It's going to be hard to follow in your footsteps, but I'll do my best. :)

Thanks to those who +1'd as well.

On 1/22/19, 2:51 PM, "Frederik Gladhorn"  wrote:

Hi,

It's been a while, so I'd like to congratulate Mitch on becoming maintainer 
for Controls 2 :)

I'll update the wiki.

Cheers,
Frederik


On mandag 26. november 2018 19:39:03 CET J-P Nurmi wrote:
> Hi all,
> 
> As you may have noticed, I haven't been actively working on Qt Quick
> Controls 2 since last summer. I haven't had time to contribute, nor
> fulfill my maintainer duties. I would therefore like to step down, and
    > propose Mitch Curtis as the new maintainer of the Qt Quick Controls 2
> module. Mitch participated in QQC2 development early on, and is a
> natural choice as the new QQC2 maintainer.
> 
> --
> J-P Nurmi
> ___
> Development mailing list
> developm...@lists.qt-project.org
> https://lists.qt-project.org/listinfo/development






___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development