From philippeb8 at gmail.com Tue May 1 01:17:49 2018 From: philippeb8 at gmail.com (Phil Bouchard) Date: Mon, 30 Apr 2018 19:17:49 -0400 Subject: [Development] Fornux C++ Superset In-Reply-To: References: <1675379.mWTH3mOQWM@tjmaciei-mobl1> <4388948.g8Bl6hTZpn@tjmaciei-mobl1> Message-ID: On 04/25/2018 08:02 AM, Phil Bouchard wrote: > Support for nested structures is easy to fix and will just take a day or > two to do so. For example: > > struct A > { >   struct B >   { >   }; > }; > > Will be converted into the following so that I can have their > specialization in a top-level namespace: > > struct A__B > { > }; > > struct A > { > }; > > Since there is no hidden catch then I will tell you right now that: > - NULL C pointers will need to be typed > - pointer casts to their encompassing structure needs to use > _containerof() macro > - C-style array parameters needs to be converted to pointers > - Types instantiated in the same statement need not be different (Ex.: > int * i, j[4]; // needs to be 2 different statements) > > That's about it. It took me 1 week to adapt "libarchive" to follow the > aforementioned rules: > https://github.com/philippeb8/libarchive/commit/5858b5c047301123ffdf05f247f7d191829d5a9b I just tried to support nested structures and given nested structures and template specializations aren't commutative then it's not possible to support them if you want to respect the access scope at the same time. If you give up the nested declaration and therefore the access scope privileges then it'll be fine. Ex: struct A { static int i; struct B { } b; // can access i }; // Would be converted to: struct A__B { }; struct A { static int i; A__B b; // cannot access i }; The day the C++ language will support nested forward declarations correctly then it'll be possible but not for now. Ex.: struct A::B::C; Honestly it took me 1 week to patch libarchive and Fornux C++ Superset was able to fix the leaks they were living with for the last 3 years. Regards, -Phil From michael.corcoran at outlook.com Tue May 1 02:44:08 2018 From: michael.corcoran at outlook.com (Michael Corcoran) Date: Tue, 1 May 2018 00:44:08 +0000 Subject: [Development] Fornux C++ Superset In-Reply-To: References: <1675379.mWTH3mOQWM@tjmaciei-mobl1> <4388948.g8Bl6hTZpn@tjmaciei-mobl1> , Message-ID: On 05/01/2018 11:18 AM, Phil Bouchard wrote: > I just tried to support nested structures and given nested structures > and template specializations aren't commutative then it's not possible > to support them if you want to respect the access scope at the same > time. If you give up the nested declaration and therefore the access > scope privileges then it'll be fine. Ex: ... > The day the C++ language will support nested forward declarations > correctly then it'll be possible but not for now. ... > Regards, > -Phil It's not really a "superset" if it doesn't support all of the features of the original language, much less core features such as nested structs... You may like to revisit that naming choice. Mike -------------- next part -------------- An HTML attachment was scrubbed... URL: From philippeb8 at gmail.com Tue May 1 15:27:26 2018 From: philippeb8 at gmail.com (Phil Bouchard) Date: Tue, 1 May 2018 13:27:26 +0000 (UTC) Subject: [Development] Fornux C++ Superset References: <1675379.mWTH3mOQWM@tjmaciei-mobl1> <4388948.g8Bl6hTZpn@tjmaciei-mobl1> , Message-ID: Michael Corcoran wrote: > On 05/01/2018 11:18 AM, Phil Bouchard wrote: >> I just tried to support nested structures and given nested structures >> and template specializations aren't commutative then it's not possible >> to support them if you want to respect the access scope at the same >> time. If you give up the nested declaration and therefore the access >> scope privileges then it'll be fine. Ex: > ... >> The day the C++ language will support nested forward declarations >> correctly then it'll be possible but not for now. > ... >> Regards, >> -Phil > > It's not really a "superset" if it doesn't support all of the features of > the original language, much less core features such as nested structs... > You may like to revisit that naming choice. I agree but I will first see what I can do with the C++ ISO standards. On the other hand I am more targeting QML because QWidgets are fine already so I assume: - QML compiler converts QML into C++ - Fornux C++ Superset could then inject its memory manager - Compile the resulting code It’s just a matter of making sure QML doesn’t use nested structures. Regards, -Phil From Oliver.Wolff at qt.io Wed May 2 07:59:24 2018 From: Oliver.Wolff at qt.io (Oliver Wolff) Date: Wed, 2 May 2018 07:59:24 +0200 Subject: [Development] Proposing Oliver Wolff as platform maintainer for UWP In-Reply-To: References: Message-ID: <75cca4f0-856f-f617-49ee-ac19ce793dc7@qt.io> Thanks for the trust everyone. On 30/04/2018 10:54, Alex Blasche wrote: > Congratulations to Oliver. The wiki was updated. > > -- > Alex > >> -----Original Message----- >> From: Development [mailto:development- >> bounces+alexander.blasche=qt.io at qt-project.org] On Behalf Of Maurice >> Kalinowski >> Sent: Monday, 9 April 2018 14:18 >> To: development at qt-project.org >> Subject: [Development] Proposing Oliver Wolff as platform maintainer for UWP >> >> Hi, >> >> As some might have recognized my focus inside the Qt Company has shifted >> from WinRT/UWP towards our Automation related offering. While I still review >> many patches for this platform, my effort in terms of active development have >> significantly reduced. >> >> Consequently, I would like to propose Oliver Wolff to take over the role as >> platform maintainer. Oliver has been part of the team for years and (besides lots >> of other things) has been taking care of the networking parts. In addition to >> that, he has been "shadow-maintaining" the port over the last year, so this >> would rather reflect reality. >> >> https://codereview.qt- >> project.org/#/q/owner:%22Oliver+Wolff+%253Coliver.wolff%2540qt.io%253E% >> 22,n,z >> >> BR, >> Maurice >> >> P.S.: Perhaps he manages to get sufficient agreement to be mentioned on the >> maintainer list, contrary to me when I took it over from Andrew :) >> >> -- >> Maurice Kalinowski >> Principal Software Engineer >> >> The Qt Company GmbH >> Rudower Chaussee 13 >> D-12489 Berlin >> maurice.kalinowski at 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 at qt-project.org >> http://lists.qt-project.org/mailman/listinfo/development > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development From alexander.blasche at qt.io Wed May 2 08:34:20 2018 From: alexander.blasche at qt.io (Alex Blasche) Date: Wed, 2 May 2018 06:34:20 +0000 Subject: [Development] Proposing David Faure as maintainer of Qt Models In-Reply-To: References: <8b471cbefc01fe740d34bcd82bd021e3@kdab.com>, Message-ID: It was pointed out to me that this vote has come due. The usual response is to update Jira components and the maintainer wiki. Neither of these have a category for this. What is the conclusion here? Do we need a new entry in the wiki and Jira? If so what would be the name for it. -- Alex ________________________________________ From: Development on behalf of Stephen Kelly Sent: Sunday, 1 April 2018 8:18:24 PM To: development at qt-project.org Subject: Re: [Development] Proposing David Faure as maintainer of Qt Models Sérgio Martins wrote: > Hi, > > > Although the wiki says Qt Models don't have a maintainer I'd say David > Faure has been an unofficial maintainer. > David is one of the top contributors to model related code and is > someone you'll always want to add as reviewer. > > He's well known in the community and already maintains QtXmlPatterns, Qt > mimetypes and Qt3Support. > > Disclaimer: David works with me at KDAB. > (And if you're wondering if KDAB has any plans for this module, the > answer is no. In fact I hope it remains low change volume). > > > Finally, a big thanks to the previous maintainer, Stephen Kelly, who did > a great job, both on Qt and KDE models! +1 for David from me too! Greetings, Steve. _______________________________________________ Development mailing list Development at qt-project.org http://lists.qt-project.org/mailman/listinfo/development From lars.knoll at qt.io Wed May 2 08:37:54 2018 From: lars.knoll at qt.io (Lars Knoll) Date: Wed, 2 May 2018 06:37:54 +0000 Subject: [Development] Proposing David Faure as maintainer of Qt Models In-Reply-To: References: <8b471cbefc01fe740d34bcd82bd021e3@kdab.com> Message-ID: I'd say we add one line for qtbase/Qt Core/Item models in the maintainer wiki. 'Item models' would probably also be the best name for Jira. Cheers, Lars > On 2 May 2018, at 08:34, Alex Blasche wrote: > > It was pointed out to me that this vote has come due. The usual response is to update Jira components and the maintainer wiki. Neither of these have a category for this. What is the conclusion here? Do we need a new entry in the wiki and Jira? If so what would be the name for it. > > -- > Alex > > ________________________________________ > From: Development on behalf of Stephen Kelly > Sent: Sunday, 1 April 2018 8:18:24 PM > To: development at qt-project.org > Subject: Re: [Development] Proposing David Faure as maintainer of Qt Models > > Sérgio Martins wrote: > >> Hi, >> >> >> Although the wiki says Qt Models don't have a maintainer I'd say David >> Faure has been an unofficial maintainer. >> David is one of the top contributors to model related code and is >> someone you'll always want to add as reviewer. >> >> He's well known in the community and already maintains QtXmlPatterns, Qt >> mimetypes and Qt3Support. >> >> Disclaimer: David works with me at KDAB. >> (And if you're wondering if KDAB has any plans for this module, the >> answer is no. In fact I hope it remains low change volume). >> >> >> Finally, a big thanks to the previous maintainer, Stephen Kelly, who did >> a great job, both on Qt and KDE models! > > +1 for David from me too! > > Greetings, > > Steve. > > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development From Ch.Ehrlicher at gmx.de Wed May 2 08:45:45 2018 From: Ch.Ehrlicher at gmx.de (Christian Ehrlicher) Date: Wed, 2 May 2018 08:45:45 +0200 Subject: [Development] Proposing David Faure as maintainer of Qt Models In-Reply-To: References: <8b471cbefc01fe740d34bcd82bd021e3@kdab.com> Message-ID: An HTML attachment was scrubbed... URL: From lars.knoll at qt.io Wed May 2 08:49:46 2018 From: lars.knoll at qt.io (Lars Knoll) Date: Wed, 2 May 2018 06:49:46 +0000 Subject: [Development] Proposing David Faure as maintainer of Qt Models In-Reply-To: References: <8b471cbefc01fe740d34bcd82bd021e3@kdab.com> Message-ID: <5841A2F6-3EB0-4956-8039-5B6C5F64C1EA@qt.io> That's different from the item models. Cheers, Lars On 2 May 2018, at 08:45, Christian Ehrlicher > wrote: Hi, There is already a component "Widgets: Itemviews" which should be renamed then. Christian Gesendet: Mittwoch, 02. Mai 2018 um 08:37 Uhr Von: "Lars Knoll" > An: "Alex Blasche" > Cc: "Qt development mailing list" > Betreff: Re: [Development] Proposing David Faure as maintainer of Qt Models I'd say we add one line for qtbase/Qt Core/Item models in the maintainer wiki. 'Item models' would probably also be the best name for Jira. Cheers, Lars _______________________________________________ Development mailing list Development at qt-project.org http://lists.qt-project.org/mailman/listinfo/development -------------- next part -------------- An HTML attachment was scrubbed... URL: From thiago.macieira at intel.com Wed May 2 09:22:07 2018 From: thiago.macieira at intel.com (Thiago Macieira) Date: Wed, 2 May 2018 00:22:07 -0700 Subject: [Development] Proposing David Faure as maintainer of Qt Models In-Reply-To: <5841A2F6-3EB0-4956-8039-5B6C5F64C1EA@qt.io> References: <8b471cbefc01fe740d34bcd82bd021e3@kdab.com> <5841A2F6-3EB0-4956-8039-5B6C5F64C1EA@qt.io> Message-ID: <3652984.8vIQL7VNPs@tjmaciei-mobl1> On Tuesday, 1 May 2018 23:49:46 PDT Lars Knoll wrote: > That's different from the item models. Not to me, no. All the bug reports I get related to the item models I immediately reassign to "Widgets: Itemviews". [...] > There is already a component "Widgets: Itemviews" which should be renamed > then. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From lars.knoll at qt.io Wed May 2 09:24:39 2018 From: lars.knoll at qt.io (Lars Knoll) Date: Wed, 2 May 2018 07:24:39 +0000 Subject: [Development] Proposing David Faure as maintainer of Qt Models In-Reply-To: <3652984.8vIQL7VNPs@tjmaciei-mobl1> References: <8b471cbefc01fe740d34bcd82bd021e3@kdab.com> <5841A2F6-3EB0-4956-8039-5B6C5F64C1EA@qt.io> <3652984.8vIQL7VNPs@tjmaciei-mobl1> Message-ID: Currently that's true. But if we have separate maintainers for the item models and views, we might want to split it. Cheers, Lars > On 2 May 2018, at 09:22, Thiago Macieira wrote: > > On Tuesday, 1 May 2018 23:49:46 PDT Lars Knoll wrote: >> That's different from the item models. > > Not to me, no. All the bug reports I get related to the item models I > immediately reassign to "Widgets: Itemviews". > > [...] >> There is already a component "Widgets: Itemviews" which should be renamed >> then. > > > -- > Thiago Macieira - thiago.macieira (AT) intel.com > Software Architect - Intel Open Source Technology Center > > > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development From thiago.macieira at intel.com Wed May 2 09:29:18 2018 From: thiago.macieira at intel.com (Thiago Macieira) Date: Wed, 2 May 2018 00:29:18 -0700 Subject: [Development] Consistently flaky test QTabWidget test Message-ID: <5139579.3heMJ1KdjW@tjmaciei-mobl1> 8 out of 8 integrations attempted in both qtbase/dev and qtbase/5.11 yesterday resulted in FAIL! : tst_QTabWidget::paintEventCount() Compared values are not the same Actual (tab2->count): 2 Expected (1) : 1 Loc: [tst_qtabwidget.cpp(573)] [on macOS 10.12] This test *is* flaky because it succeeded in one of the retries, but apparently failed the other 16 runs. Can someone take a look? -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From thiago.macieira at intel.com Wed May 2 09:46:40 2018 From: thiago.macieira at intel.com (Thiago Macieira) Date: Wed, 2 May 2018 00:46:40 -0700 Subject: [Development] Consistently flaky test QTabWidget test In-Reply-To: <5139579.3heMJ1KdjW@tjmaciei-mobl1> References: <5139579.3heMJ1KdjW@tjmaciei-mobl1> Message-ID: <14669909.jY2413iC0M@tjmaciei-mobl1> On Wednesday, 2 May 2018 00:29:18 PDT Thiago Macieira wrote: > 8 out of 8 integrations attempted in both qtbase/dev and qtbase/5.11 > yesterday resulted in Make that 9 of 9. I'll stop trying to stage anything in qtbase until further notice. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From Michael.Bruning at qt.io Wed May 2 10:00:38 2018 From: Michael.Bruning at qt.io (Michael Bruning) Date: Wed, 2 May 2018 08:00:38 +0000 Subject: [Development] =?utf-8?q?Nominating_J=C3=BCri_Valdmann_for_Approv?= =?utf-8?q?er_status?= In-Reply-To: References: Message-ID: <81D7E6D8-A929-4112-A32F-E80A4A61AC9B@qt.io> +1 absolutely. Best, Michael > On 27. Apr 2018, at 10:58, Michal Klocek wrote: > > Hi > > I would like to nominate Jüri Valdmann for Approver. > > He joined The Qt Company more than one year ago and he's been doing most > of his excellent work for QtWebEngine. > > You can see his contributions here: > > https://codereview.qt-project.org/#/q/owner:%22J%C3%BCri%20Valdmann%22,n,z > > Br > > Michal > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development From Richard.Gustavsen at qt.io Wed May 2 10:11:52 2018 From: Richard.Gustavsen at qt.io (Richard Gustavsen) Date: Wed, 2 May 2018 08:11:52 +0000 Subject: [Development] Consistently flaky test QTabWidget test In-Reply-To: <14669909.jY2413iC0M@tjmaciei-mobl1> References: <5139579.3heMJ1KdjW@tjmaciei-mobl1>, <14669909.jY2413iC0M@tjmaciei-mobl1> Message-ID: I'll take a look! -Richard ________________________________ Fra: Development på vegne av Thiago Macieira Sendt: 2. mai 2018 09:46:40 Til: development at qt-project.org Emne: Re: [Development] Consistently flaky test QTabWidget test On Wednesday, 2 May 2018 00:29:18 PDT Thiago Macieira wrote: > 8 out of 8 integrations attempted in both qtbase/dev and qtbase/5.11 > yesterday resulted in Make that 9 of 9. I'll stop trying to stage anything in qtbase until further notice. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center _______________________________________________ Development mailing list Development at qt-project.org http://lists.qt-project.org/mailman/listinfo/development -------------- next part -------------- An HTML attachment was scrubbed... URL: From kari.oikarinen at qt.io Wed May 2 10:27:17 2018 From: kari.oikarinen at qt.io (Kari Oikarinen) Date: Wed, 2 May 2018 11:27:17 +0300 Subject: [Development] Consistently flaky test QTabWidget test In-Reply-To: References: <5139579.3heMJ1KdjW@tjmaciei-mobl1> <14669909.jY2413iC0M@tjmaciei-mobl1> Message-ID: Hi! I'm also taking a look at it. It's my change that broke it. The issue is that the test is getting some extra paint events on macOS. Previously it had a qWait(1000) that waited over them. Here's a change to add it back and stop blocking other integrations: https://codereview.qt-project.org/#/c/227976/ -- Kari On 02.05.2018 11:11, Richard Gustavsen wrote: > I'll take a look! > > > -Richard > > ------------------------------------------------------------------------ > *Fra:* Development > på vegne av > Thiago Macieira > *Sendt:* 2. mai 2018 09:46:40 > *Til:* development at qt-project.org > *Emne:* Re: [Development] Consistently flaky test QTabWidget test > On Wednesday, 2 May 2018 00:29:18 PDT Thiago Macieira wrote: >> 8 out of 8 integrations attempted in both qtbase/dev and qtbase/5.11 >> yesterday resulted in > > Make that 9 of 9. > > I'll stop trying to stage anything in qtbase until further notice. > > -- > Thiago Macieira - thiago.macieira (AT) intel.com >   Software Architect - Intel Open Source Technology Center > > > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development > > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development > From frederik.gladhorn at qt.io Wed May 2 11:09:40 2018 From: frederik.gladhorn at qt.io (Frederik Gladhorn) Date: Wed, 02 May 2018 11:09:40 +0200 Subject: [Development] Consistently flaky test QTabWidget test In-Reply-To: <5139579.3heMJ1KdjW@tjmaciei-mobl1> References: <5139579.3heMJ1KdjW@tjmaciei-mobl1> Message-ID: <1816519.r8LSTkasc4@frederik-thinkcentre-m93p> On onsdag 2. mai 2018 09.29.18 CEST Thiago Macieira wrote: > 8 out of 8 integrations attempted in both qtbase/dev and qtbase/5.11 > yesterday resulted in > > FAIL! : tst_QTabWidget::paintEventCount() Compared values are not the same > Actual (tab2->count): 2 > Expected (1) : 1 > Loc: [tst_qtabwidget.cpp(573)] > [on macOS 10.12] > > This test *is* flaky because it succeeded in one of the retries, but > apparently failed the other 16 runs. > > Can someone take a look? For anyone investigating, we have a bit of support in analyzing: https://testresults.qt.io/grafana/d/000000009/coin-single-test-details? orgId=1&var-project=qt%2Fqtbase&var-testcase=tests%2Fauto%2Fwidgets%2Fwidgets %2Fqtabwidget&var-testfunction=All&var-branch=5.11&var-branch=dev&var- inter=24h I hope that helps (it pretty clearly shows that it's been a recent regression). Thanks Kari for taking care of it :) This one seems already under control, but generally, let's base things on data if we can. This should give an overview over flaky tests in general: https://testresults.qt.io/grafana/d/000000007/coin-flaky-tests Cheers, Frederik From sami.nurmenniemi at qt.io Wed May 2 11:28:32 2018 From: sami.nurmenniemi at qt.io (Sami Nurmenniemi) Date: Wed, 2 May 2018 09:28:32 +0000 Subject: [Development] CI stabilization status Message-ID: Hi all, Additional effort was put in stabilizing the CI in the beginning of the February. Highlights of the improvements so far are: * Top flaky test cases have been fixed or blacklisted * This was initially the number one reason for randomly failing integrations * Mostly done for qtbase * JIRA tickets created for the blacklisted tests * Coin improvements * Secondary Coin instance running for testing qt5 builds agains Coin master branch * Garbage collection of old build artifacts for reducing disk usage on Coin host * The last cancelled qt5 builds are protected * Agent heartbeat added, builds no longer fail if VM or KVM host crashes * Refactoring asynchronous code from Python threads to asyncio * Reduced Gerrit connection attempts * Improved robustness of CI for CI tests * Fixed deadlocks causing integrations to hang * Infra * More KVM host machines deployed (previously 20, now 33 hosts) * Network bandwidth on KVM host machines increased from 1 Gbit/s to 10 Gbit/s * Provisioning * Changes specific for one OS no longer require provisioning all of them * OS package repositories are mirrored to reduce external network usage * Automatic updates on guest VMs disabled to reduce variance of external components * CI system monitoring page added to Grafana * Simple list of red/green hearts (you have to be logged in to see these) * Detects problems before they start affecting the CI stability Problems we are still facing: * KVM hosts crashing (kernel bug with nfs cache) * Configure step hanging during build, mostly happens on macOS * Random flaky test failures on other components than qtbase * Some leftovers to iron out from the Coin refactoring Best Regards, Sami -------------- next part -------------- An HTML attachment was scrubbed... URL: From Tobias.Hunger at qt.io Wed May 2 12:14:14 2018 From: Tobias.Hunger at qt.io (Tobias Hunger) Date: Wed, 2 May 2018 10:14:14 +0000 Subject: [Development] Proposing Orgad Shaneh as Maintainer of Version Control modules in Qt Creator Message-ID: Hello, I want to propose Orgad Shaneh as maintainer of the version control related modules in Qt Creator. So far I have been handling that responsibility, but since I took over the project-related Qt Creator plugins, I had way too little time on my hands to take a lead in the version management related code. Orgad has been working in those modules, he did a lion's share of the reviews involved and he added functionality during that time and he is willing to take on the responsibility involved. So I would like formally propose Orgad as maintainer of the version management code. I am sure he will take good care of the code, especially of the vcsbase and git plugins. Best Regards, Tobias -- Tobias Hunger, Senior Software Engineer | The Qt Company The Qt Company GmbH, Rudower Chaussee 13, D-12489 Berlin Geschäftsführer: Mika Pälsi, Juha Varelius, Mika Harjuaho. Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 144331 B From nikolai.kosjar at qt.io Wed May 2 12:16:23 2018 From: nikolai.kosjar at qt.io (Nikolai Kosjar) Date: Wed, 2 May 2018 12:16:23 +0200 Subject: [Development] Proposing Orgad Shaneh as Maintainer of Version Control modules in Qt Creator In-Reply-To: References: Message-ID: +1! :) On 05/02/2018 12:14 PM, Tobias Hunger wrote: > Hello, > > I want to propose Orgad Shaneh as maintainer of the version control related modules in Qt Creator. > > So far I have been handling that responsibility, but since I took over the project-related Qt Creator plugins, I had way too little time on my hands to take a lead in the version management related code. > > Orgad has been working in those modules, he did a lion's share of the reviews involved and he added functionality during that time and he is willing to take on the responsibility involved. So I would like formally propose Orgad as maintainer of the version management code. I am sure he will take good care of the code, especially of the vcsbase and git plugins. > > Best Regards, > Tobias > > -- > Tobias Hunger, Senior Software Engineer | The Qt Company > The Qt Company GmbH, Rudower Chaussee 13, D-12489 Berlin > Geschäftsführer: Mika Pälsi, Juha Varelius, Mika Harjuaho. Sitz der > Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 144331 B > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development > From Jaroslaw.Kobus at qt.io Wed May 2 13:03:31 2018 From: Jaroslaw.Kobus at qt.io (Jaroslaw Kobus) Date: Wed, 2 May 2018 11:03:31 +0000 Subject: [Development] Proposing Orgad Shaneh as Maintainer of Version Control modules in Qt Creator In-Reply-To: References: Message-ID: Of course +1 ________________________________ From: Development on behalf of Tobias Hunger Sent: Wednesday, May 2, 2018 12:14:14 PM To: qt-creator at qt-project.org; development at qt-project.org Subject: [Development] Proposing Orgad Shaneh as Maintainer of Version Control modules in Qt Creator Hello, I want to propose Orgad Shaneh as maintainer of the version control related modules in Qt Creator. So far I have been handling that responsibility, but since I took over the project-related Qt Creator plugins, I had way too little time on my hands to take a lead in the version management related code. Orgad has been working in those modules, he did a lion's share of the reviews involved and he added functionality during that time and he is willing to take on the responsibility involved. So I would like formally propose Orgad as maintainer of the version management code. I am sure he will take good care of the code, especially of the vcsbase and git plugins. Best Regards, Tobias -- Tobias Hunger, Senior Software Engineer | The Qt Company The Qt Company GmbH, Rudower Chaussee 13, D-12489 Berlin Geschäftsführer: Mika Pälsi, Juha Varelius, Mika Harjuaho. Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 144331 B _______________________________________________ Development mailing list Development at qt-project.org http://lists.qt-project.org/mailman/listinfo/development -------------- next part -------------- An HTML attachment was scrubbed... URL: From philippeb8 at gmail.com Wed May 2 13:09:33 2018 From: philippeb8 at gmail.com (Phil Bouchard) Date: Wed, 2 May 2018 07:09:33 -0400 Subject: [Development] Fornux C++ Superset In-Reply-To: References: <1675379.mWTH3mOQWM@tjmaciei-mobl1> <4388948.g8Bl6hTZpn@tjmaciei-mobl1> Message-ID: On 05/01/2018 09:27 AM, Phil Bouchard wrote: > Michael Corcoran wrote: >> It's not really a "superset" if it doesn't support all of the features of >> the original language, much less core features such as nested structs... >> You may like to revisit that naming choice. > > I agree but I will first see what I can do with the C++ ISO standards. I already submitted the request: https://groups.google.com/a/isocpp.org/forum/?fromgroups#!topic/std-proposals/M0G7AhsggmE Regards, -Phil From sergio.martins at kdab.com Wed May 2 13:49:55 2018 From: sergio.martins at kdab.com (=?UTF-8?Q?S=C3=A9rgio_Martins?=) Date: Wed, 02 May 2018 12:49:55 +0100 Subject: [Development] Proposing David Faure as maintainer of Qt Models In-Reply-To: References: <8b471cbefc01fe740d34bcd82bd021e3@kdab.com> <5841A2F6-3EB0-4956-8039-5B6C5F64C1EA@qt.io> <3652984.8vIQL7VNPs@tjmaciei-mobl1> Message-ID: <31bc3e0d56ac22cb1ae40a3c36b43c33@kdab.com> On 2018-05-02 08:24, Lars Knoll wrote: > Currently that's true. But if we have separate maintainers for the > item models and views, we might want to split it. Yes, please split. "Item Models" is also used with QtQuick so makes sense to separate it from QWidgets. Regrads, -- Sérgio Martins | sergio.martins at kdab.com | Senior Software Engineer Klarälvdalens Datakonsult AB, a KDAB Group company Tel: Sweden (HQ) +46-563-540090, USA +1-866-777-KDAB(5322) KDAB - The Qt, C++ and OpenGL Experts From Eike.Ziller at qt.io Wed May 2 13:56:00 2018 From: Eike.Ziller at qt.io (Eike Ziller) Date: Wed, 2 May 2018 11:56:00 +0000 Subject: [Development] Proposing Orgad Shaneh as Maintainer of Version Control modules in Qt Creator In-Reply-To: References: Message-ID: +1 Orgad is doing a great job, about time that we make that defacto state official! :) > On 2. May 2018, at 12:14, Tobias Hunger wrote: > > Hello, > > I want to propose Orgad Shaneh as maintainer of the version control related modules in Qt Creator. > > So far I have been handling that responsibility, but since I took over the project-related Qt Creator plugins, I had way too little time on my hands to take a lead in the version management related code. > > Orgad has been working in those modules, he did a lion's share of the reviews involved and he added functionality during that time and he is willing to take on the responsibility involved. So I would like formally propose Orgad as maintainer of the version management code. I am sure he will take good care of the code, especially of the vcsbase and git plugins. > > Best Regards, > Tobias > > -- > Tobias Hunger, Senior Software Engineer | The Qt Company > The Qt Company GmbH, Rudower Chaussee 13, D-12489 Berlin > Geschäftsführer: Mika Pälsi, Juha Varelius, Mika Harjuaho. Sitz der > Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 144331 B > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development -- Eike Ziller Principal Software Engineer The Qt Company GmbH Rudower Chaussee 13 D-12489 Berlin eike.ziller at 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 From alexander.blasche at qt.io Wed May 2 14:18:54 2018 From: alexander.blasche at qt.io (Alex Blasche) Date: Wed, 2 May 2018 12:18:54 +0000 Subject: [Development] Jira changes going forward Message-ID: Hi, there are quite a few changes to Jira on my todo list. Some of them result from some internal TQtC process changes (related to public requirements mgmt) and others were put forward by individuals with a keen interest in improving things (thank you for that). Unfortunately some of proposals will break existing setups (especially filters). Since there are a lot of changes I chose to use gerrit for the discussion. A long mail is not able to provide the means to update and review the latest consensus. Please have a look at https://codereview.qt-project.org/#/c/225694/ The patch is not intended to be merged. It merely exists to facilitate the community discussion. However I might document some of the outcomes (especially process outcomes) somewhere later on. Thank you for your feedback. -- Alex From Richard.Gustavsen at qt.io Wed May 2 14:19:51 2018 From: Richard.Gustavsen at qt.io (Richard Gustavsen) Date: Wed, 2 May 2018 12:19:51 +0000 Subject: [Development] Consistently flaky test QTabWidget test In-Reply-To: <1816519.r8LSTkasc4@frederik-thinkcentre-m93p> References: <5139579.3heMJ1KdjW@tjmaciei-mobl1>, <1816519.r8LSTkasc4@frederik-thinkcentre-m93p> Message-ID: tst_QWindow::requestUpdate is also causing problems. Two patches to solve that: https://codereview.qt-project.org/#/c/228024/ https://codereview.qt-project.org/#/c/228027/ -Richard ________________________________ Fra: Development på vegne av Frederik Gladhorn Sendt: 2. mai 2018 11:09:40 Til: development at qt-project.org Kopi: Thiago Macieira Emne: Re: [Development] Consistently flaky test QTabWidget test On onsdag 2. mai 2018 09.29.18 CEST Thiago Macieira wrote: > 8 out of 8 integrations attempted in both qtbase/dev and qtbase/5.11 > yesterday resulted in > > FAIL! : tst_QTabWidget::paintEventCount() Compared values are not the same > Actual (tab2->count): 2 > Expected (1) : 1 > Loc: [tst_qtabwidget.cpp(573)] > [on macOS 10.12] > > This test *is* flaky because it succeeded in one of the retries, but > apparently failed the other 16 runs. > > Can someone take a look? For anyone investigating, we have a bit of support in analyzing: https://testresults.qt.io/grafana/d/000000009/coin-single-test-details? orgId=1&var-project=qt%2Fqtbase&var-testcase=tests%2Fauto%2Fwidgets%2Fwidgets %2Fqtabwidget&var-testfunction=All&var-branch=5.11&var-branch=dev&var- inter=24h I hope that helps (it pretty clearly shows that it's been a recent regression). Thanks Kari for taking care of it :) This one seems already under control, but generally, let's base things on data if we can. This should give an overview over flaky tests in general: https://testresults.qt.io/grafana/d/000000007/coin-flaky-tests Cheers, Frederik _______________________________________________ Development mailing list Development at qt-project.org http://lists.qt-project.org/mailman/listinfo/development -------------- next part -------------- An HTML attachment was scrubbed... URL: From Morten.Sorvig at qt.io Wed May 2 15:07:21 2018 From: Morten.Sorvig at qt.io (=?utf-8?B?TW9ydGVuIFPDuHJ2aWc=?=) Date: Wed, 2 May 2018 13:07:21 +0000 Subject: [Development] QTest qWaitForWindowExposed and qWaitForWindowActive (was: Consistently flaky test QTabWidget test) In-Reply-To: <5139579.3heMJ1KdjW@tjmaciei-mobl1> References: <5139579.3heMJ1KdjW@tjmaciei-mobl1> Message-ID: > On 2 May 2018, at 09:29, Thiago Macieira wrote: > > FAIL! : tst_QTabWidget::paintEventCount() Compared values are not the same > Actual (tab2->count): 2 > Expected (1) : 1 > Loc: [tst_qtabwidget.cpp(573)] > [on macOS 10.12] Hi, I recently investigated a similar issue as to the one described here, where tests where failing due to extra paint events. This resulted in a couple of patches to stabilize tests, and discussions on how to proceed, all of which is documented on QTBUG-61967. (I unfortunately failed to share the outcome of the discussions beyond posting on that bug, which I’m rectifying now). To recap: * WindowExposed occurs when the window becomes visible on screen and is about to draw the first frame. * WindowActive occurs if/when the platform makes the window active, which may trigger a repaint to make widgets etc have the “active” styling. WindowActive may occur either before or after Exposed, depending on platform (plugin) implementation and/or platform timing outside of our control. This means that a test that waits for Exposed before starting to count paint events may have the count erroneously increased when the Active event arrives. It could be argued that WindowActive a sub-state of WindowExposed and that the platform plugin should enforce the ordering, but in the end we settled on keeping them separate. This means tests might want to wait for both: QTest::qWaitForWindowExposed(window); QTest::qWaitForWindowActive(window); // Now count paint events. This is obviously a bit unwieldy so we want to improve the API as well: watch QTBUG-61967 for updates. Morten From philippeb8 at gmail.com Wed May 2 22:45:46 2018 From: philippeb8 at gmail.com (Phil Bouchard) Date: Wed, 2 May 2018 20:45:46 +0000 (UTC) Subject: [Development] Fornux C++ Superset References: <1675379.mWTH3mOQWM@tjmaciei-mobl1> <4388948.g8Bl6hTZpn@tjmaciei-mobl1> , Message-ID: Phil Bouchard wrote: On the other hand I am more targeting QML because QWidgets are fine already so I assume: - QML compiler converts QML into C++ - Fornux C++ Superset could then inject its memory manager - Compile the resulting code It’s just a matter of making sure QML doesn’t use nested structures. So what do you think Qt? Are you: 1) Not interested or whatsoever 2) Interested to give a trial version a shot 3) You get the idea already and might consider it Regards, -Phil From thiago.macieira at intel.com Wed May 2 23:03:41 2018 From: thiago.macieira at intel.com (Thiago Macieira) Date: Wed, 2 May 2018 14:03:41 -0700 Subject: [Development] Fornux C++ Superset In-Reply-To: References: Message-ID: <18605229.90UMlxMT5d@tjmaciei-mobl1> On Wednesday, 2 May 2018 13:45:46 PDT Phil Bouchard wrote: > So what do you think Qt? Are you: > > 1) Not interested or whatsoever > 2) Interested to give a trial version a shot > 3) You get the idea already and might consider it Probably (1). -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From philippeb8 at gmail.com Thu May 3 01:38:41 2018 From: philippeb8 at gmail.com (Phil Bouchard) Date: Wed, 2 May 2018 23:38:41 +0000 (UTC) Subject: [Development] Fornux C++ Superset References: <18605229.90UMlxMT5d@tjmaciei-mobl1> Message-ID: Thiago Macieira wrote: > On Wednesday, 2 May 2018 13:45:46 PDT Phil Bouchard wrote: >> So what do you think Qt? Are you: >> >> 1) Not interested or whatsoever >> 2) Interested to give a trial version a shot >> 3) You get the idea already and might consider it > > Probably (1). Ok well live long and prosper! Regards, -Phil From alexander.blasche at qt.io Thu May 3 07:36:43 2018 From: alexander.blasche at qt.io (Alex Blasche) Date: Thu, 3 May 2018 05:36:43 +0000 Subject: [Development] Proposing David Faure as maintainer of Qt Models In-Reply-To: References: <8b471cbefc01fe740d34bcd82bd021e3@kdab.com> <5841A2F6-3EB0-4956-8039-5B6C5F64C1EA@qt.io> <3652984.8vIQL7VNPs@tjmaciei-mobl1>, Message-ID: I added the "Item Models" component to Jira and the maintainer wiki, -- ALex ________________________________________ From: Development on behalf of Lars Knoll Sent: Wednesday, 2 May 2018 9:24:39 AM To: Qt development mailing list Subject: Re: [Development] Proposing David Faure as maintainer of Qt Models Currently that's true. But if we have separate maintainers for the item models and views, we might want to split it. Cheers, Lars > On 2 May 2018, at 09:22, Thiago Macieira wrote: > > On Tuesday, 1 May 2018 23:49:46 PDT Lars Knoll wrote: >> That's different from the item models. > > Not to me, no. All the bug reports I get related to the item models I > immediately reassign to "Widgets: Itemviews". > > [...] >> There is already a component "Widgets: Itemviews" which should be renamed >> then. > > > -- > Thiago Macieira - thiago.macieira (AT) intel.com > Software Architect - Intel Open Source Technology Center > > > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development _______________________________________________ Development mailing list Development at qt-project.org http://lists.qt-project.org/mailman/listinfo/development From andre.hartmann at iseg-hv.de Thu May 3 08:29:18 2018 From: andre.hartmann at iseg-hv.de (=?UTF-8?Q?Andr=c3=a9_Hartmann?=) Date: Thu, 3 May 2018 08:29:18 +0200 Subject: [Development] Proposing Orgad Shaneh as Maintainer of Version Control modules in Qt Creator In-Reply-To: References: Message-ID: +1. Orgad is doing great work (everywhere in Creator, not only in the VCS intregration). Disclaimer: I'm no maintainer. Regards, André Am 02.05.2018 um 13:03 schrieb Jaroslaw Kobus: > Of course +1 > > ------------------------------------------------------------------------ > *From:* Development > on behalf of > Tobias Hunger > *Sent:* Wednesday, May 2, 2018 12:14:14 PM > *To:* qt-creator at qt-project.org; development at qt-project.org > *Subject:* [Development] Proposing Orgad Shaneh as Maintainer of Version > Control modules in Qt Creator > Hello, > > I want to propose Orgad Shaneh as maintainer of the version control > related modules in Qt Creator. > > So far I have been handling that responsibility, but since I took over > the project-related Qt Creator plugins, I had way too little time on my > hands to take a lead in the version management related code. > > Orgad has been working in those modules, he did a lion's share of the > reviews involved and he added functionality during that time and he is > willing to take on the responsibility involved. So I would like formally > propose Orgad as maintainer of the version management code. I am sure he > will take good care of the code, especially of the vcsbase and git plugins. > > Best Regards, > Tobias > > -- > Tobias Hunger, Senior Software Engineer | The Qt Company > The Qt Company GmbH, Rudower Chaussee 13, D-12489 Berlin > Geschäftsführer: Mika Pälsi, Juha Varelius, Mika Harjuaho. Sitz der > Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB > 144331 B > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development > > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development > -- Dipl.-Ing. (FH) André Hartmann Softwareentwicklung / Software Development E-Mail: andre.hartmann at iseg-hv.de | Tel: +49 351 26996-43 | Fax: +49 351 26996-21 iseg Spezialelektronik GmbH - HIGH VOLTAGE. EXACTLY. iseg-hv.de | iseg-hv.com | download.iseg-hv.com Bautzner Landstr. 23, 01454 Radeberg / Rossendorf, Germany Geschäftsführer / Managing directors: Dr. Frank Gleisberg, Dr. Joachim Pöthig Amtsgericht / Lower district court: Dresden HRB 16250 Umsatzsteuer-Id: / VAT-ID: DE812508942 News / Information https://iseg-hv.com/en/products/control#isegControl2 isegControl2 - Unified Control Software https://iseg-hv.com/en/products/detail/EHS EHS FLEX - Customize and keep the price https://iseg-hv.com/en/products/detail/EHS EHS STACK - Perfect for GEM Detectors https://iseg-hv.com/files/iseg-high-voltage-power-supplies.pdf NEW! Product catalog 2017 / 2018 released https://iseg-hv.com/en/products/detail/NHR NHR - NIM HV-Supply with reversible polarity Links https://www.linkedin.com/company/12726924 iseg on LINKEDIN | Let's stay connected! https://www.youtube.com/channel/UC5AL-ZgOqSim_1gYNnndyzQ iseg on YOUTUBE | Tutorials and more ... https://www.twitter.com/iseg_hv iseg on TWITTER | please follow! https://iseg-hv.com/files/iseg-high-voltage-power-supplies.pdf iseg CATALOG | download product catalog as PDF http://download.iseg-hv.com/ iseg DOWNLOADS | manuals, software, firmware and more... Diese E-Mail enthält vertrauliche und/oder rechtlich geschützte Informationen. Wenn Sie nicht der richtige Adressat sind oder diese E-Mail irrtümlich erhalten haben, informieren Sie bitte sofort den Absender und vernichten Sie diese Mail. Das unerlaubte Kopieren sowie die unbefugte Weitergabe dieser Mail ist nicht gestattet. This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and destroy this e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden. From lars.knoll at qt.io Thu May 3 08:31:54 2018 From: lars.knoll at qt.io (Lars Knoll) Date: Thu, 3 May 2018 06:31:54 +0000 Subject: [Development] Proposing Orgad Shaneh as Maintainer of Version Control modules in Qt Creator In-Reply-To: References: Message-ID: <62A17E28-526B-412B-B04D-2417EC060166@qt.io> +1. Thanks Orgad, for stepping up and all the great work you're doing :) Cheers, Lars > On 2 May 2018, at 13:56, Eike Ziller wrote: > > +1 > > Orgad is doing a great job, about time that we make that defacto state official! :) > >> On 2. May 2018, at 12:14, Tobias Hunger wrote: >> >> Hello, >> >> I want to propose Orgad Shaneh as maintainer of the version control related modules in Qt Creator. >> >> So far I have been handling that responsibility, but since I took over the project-related Qt Creator plugins, I had way too little time on my hands to take a lead in the version management related code. >> >> Orgad has been working in those modules, he did a lion's share of the reviews involved and he added functionality during that time and he is willing to take on the responsibility involved. So I would like formally propose Orgad as maintainer of the version management code. I am sure he will take good care of the code, especially of the vcsbase and git plugins. >> >> Best Regards, >> Tobias >> >> -- >> Tobias Hunger, Senior Software Engineer | The Qt Company >> The Qt Company GmbH, Rudower Chaussee 13, D-12489 Berlin >> Geschäftsführer: Mika Pälsi, Juha Varelius, Mika Harjuaho. Sitz der >> Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 144331 B >> >> _______________________________________________ >> Development mailing list >> Development at qt-project.org >> http://lists.qt-project.org/mailman/listinfo/development > > -- > Eike Ziller > Principal Software Engineer > > The Qt Company GmbH > Rudower Chaussee 13 > D-12489 Berlin > eike.ziller at 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 at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development From announce at qt-project.org Thu May 3 13:01:54 2018 From: announce at qt-project.org (List for announcements regarding Qt releases and development) Date: Thu, 3 May 2018 11:01:54 +0000 Subject: [Development] [Announce] Qt Creator 4.6.1 released Message-ID: We are happy to announce the release of Qt Creator 4.6.1! https://blog.qt.io/blog/2018/05/03/qt-creator-4-6-1-released/ -- Eike Ziller Principal Software Engineer The Qt Company GmbH Rudower Chaussee 13 D-12489 Berlin eike.ziller at 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 _______________________________________________ Announce mailing list Announce at qt-project.org http://lists.qt-project.org/mailman/listinfo/announce From robert.loehning at qt.io Thu May 3 19:15:53 2018 From: robert.loehning at qt.io (=?UTF-8?Q?Robert_L=c3=b6hning?=) Date: Thu, 3 May 2018 19:15:53 +0200 Subject: [Development] Proposing Orgad Shaneh as Maintainer of Version Control modules in Qt Creator In-Reply-To: References: Message-ID: Am 02.05.2018 um 13:56 schrieb Eike Ziller: > +1 > > Orgad is doing a great job, about time that we make that defacto state official! :) Just what I wanted to say. :-) +1 > >> On 2. May 2018, at 12:14, Tobias Hunger wrote: >> >> Hello, >> >> I want to propose Orgad Shaneh as maintainer of the version control related modules in Qt Creator. >> >> So far I have been handling that responsibility, but since I took over the project-related Qt Creator plugins, I had way too little time on my hands to take a lead in the version management related code. >> >> Orgad has been working in those modules, he did a lion's share of the reviews involved and he added functionality during that time and he is willing to take on the responsibility involved. So I would like formally propose Orgad as maintainer of the version management code. I am sure he will take good care of the code, especially of the vcsbase and git plugins. >> >> Best Regards, >> Tobias >> >> -- >> Tobias Hunger, Senior Software Engineer | The Qt Company >> The Qt Company GmbH, Rudower Chaussee 13, D-12489 Berlin >> Geschäftsführer: Mika Pälsi, Juha Varelius, Mika Harjuaho. Sitz der >> Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 144331 B >> >> _______________________________________________ >> Development mailing list >> Development at qt-project.org >> http://lists.qt-project.org/mailman/listinfo/development > From aclight at gmail.com Thu May 3 19:16:13 2018 From: aclight at gmail.com (Adam Light) Date: Thu, 03 May 2018 17:16:13 +0000 Subject: [Development] [Announce] Qt Creator 4.6.1 released In-Reply-To: References: Message-ID: On Thu, May 3, 2018 at 4:02 AM List for announcements regarding Qt releases and development wrote: > We are happy to announce the release of Qt Creator 4.6.1! > > https://blog.qt.io/blog/2018/05/03/qt-creator-4-6-1-released/ > > I downloaded the Macintosh version and when I try to open it, the OS tells me that the application isn't signed: [image: image.png] I know how to get around this, but I shouldn't have to, and I don't recall needing to do this in the past. Is there a problem signing the application? Thanks Adam -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image.png Type: image/png Size: 120684 bytes Desc: not available URL: From Eike.Ziller at qt.io Fri May 4 10:21:43 2018 From: Eike.Ziller at qt.io (Eike Ziller) Date: Fri, 4 May 2018 08:21:43 +0000 Subject: [Development] [Announce] Qt Creator 4.6.1 released In-Reply-To: References: Message-ID: <1C71A485-15EC-4703-B92E-294EC3971A93@qt.io> Hm, "codesign -dvvv” says Authority=Developer ID Application: The Qt Company Oy (A5GTH44LYL) etc. but “codesign --verify -vvvv” complains. Looks like we managed to sign the debug information before we remove it from the app bundle. So, nothing really bad happened ;) but of course I’ll look into fixing this. Sorry for the inconvenience. Br, Eike > On 3. May 2018, at 19:16, Adam Light wrote: > > > > On Thu, May 3, 2018 at 4:02 AM List for announcements regarding Qt releases and development wrote: > We are happy to announce the release of Qt Creator 4.6.1! > > https://blog.qt.io/blog/2018/05/03/qt-creator-4-6-1-released/ > > > I downloaded the Macintosh version and when I try to open it, the OS tells me that the application isn't signed: > > > > I know how to get around this, but I shouldn't have to, and I don't recall needing to do this in the past. Is there a problem signing the application? > > Thanks > Adam > > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development -- Eike Ziller Principal Software Engineer The Qt Company GmbH Rudower Chaussee 13 D-12489 Berlin eike.ziller at 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 From pgorszkowski at gmail.com Sat May 5 19:32:05 2018 From: pgorszkowski at gmail.com (Przemyslaw Gorszkowski) Date: Sat, 5 May 2018 19:32:05 +0200 Subject: [Development] [Qt-creator] Proposing Orgad Shaneh as Maintainer of Version Control modules in Qt Creator In-Reply-To: <62A17E28-526B-412B-B04D-2417EC060166@qt.io> References: <62A17E28-526B-412B-B04D-2417EC060166@qt.io> Message-ID: +1 On Thu, May 3, 2018 at 8:31 AM, Lars Knoll wrote: > +1. > > Thanks Orgad, for stepping up and all the great work you're doing :) > > Cheers, > Lars > > > On 2 May 2018, at 13:56, Eike Ziller wrote: > > > > +1 > > > > Orgad is doing a great job, about time that we make that defacto state > official! :) > > > >> On 2. May 2018, at 12:14, Tobias Hunger wrote: > >> > >> Hello, > >> > >> I want to propose Orgad Shaneh as maintainer of the version control > related modules in Qt Creator. > >> > >> So far I have been handling that responsibility, but since I took over > the project-related Qt Creator plugins, I had way too little time on my > hands to take a lead in the version management related code. > >> > >> Orgad has been working in those modules, he did a lion's share of the > reviews involved and he added functionality during that time and he is > willing to take on the responsibility involved. So I would like formally > propose Orgad as maintainer of the version management code. I am sure he > will take good care of the code, especially of the vcsbase and git plugins. > >> > >> Best Regards, > >> Tobias > >> > >> -- > >> Tobias Hunger, Senior Software Engineer | The Qt Company > >> The Qt Company GmbH, Rudower Chaussee 13, D-12489 Berlin > >> Geschäftsführer: Mika Pälsi, Juha Varelius, Mika Harjuaho. Sitz der > >> Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB > 144331 B > >> > >> _______________________________________________ > >> Development mailing list > >> Development at qt-project.org > >> http://lists.qt-project.org/mailman/listinfo/development > > > > -- > > Eike Ziller > > Principal Software Engineer > > > > The Qt Company GmbH > > Rudower Chaussee 13 > > D-12489 Berlin > > eike.ziller at 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 at qt-project.org > > http://lists.qt-project.org/mailman/listinfo/development > > _______________________________________________ > Qt-creator mailing list > Qt-creator at qt-project.org > http://lists.qt-project.org/mailman/listinfo/qt-creator > -- Best regards/Pozdrawiam Przemyslaw Gorszkowski -------------- next part -------------- An HTML attachment was scrubbed... URL: From tony.sarajarvi at qt.io Sun May 6 18:51:55 2018 From: tony.sarajarvi at qt.io (=?iso-8859-1?Q?Tony_Saraj=E4rvi?=) Date: Sun, 6 May 2018 16:51:55 +0000 Subject: [Development] Small CI update Message-ID: Hi Now as no-one is building anything, I'll perform a slight update on our infra. I'll switch over openNebula to another instance where we define hardware a bit differently. This means I'll have to move over the hosts from ONE to another and while they are being moved, the performance is reduced. All should be ok by tomorrow morning. -Tony -------------- next part -------------- An HTML attachment was scrubbed... URL: From jani.heikkinen at qt.io Tue May 8 12:06:23 2018 From: jani.heikkinen at qt.io (Jani Heikkinen) Date: Tue, 8 May 2018 10:06:23 +0000 Subject: [Development] Qt 5.11.0 RC released In-Reply-To: References: Message-ID: Hi, We have released Qt 5.11.0 RC today. It is still online delivery only and you can get it via online installer as an update to existing installation or just doing fresh installation & selecting 5.11 rc from 'preview' section. Delta to beta4 release can be found as an attachment. Target is to release these packages as Qt 5.11.0 22nd of May; a bit earlier than originally planned. So please inform me immediately if there is something badly broken. But remember: We won't do rc2 without really good reasons and if we need to release rc2 we will take in only fix for issue(s) which is causing rc2 and nothing else. So please don't try to push anything else in '5.11.0' anymore. br, Jani Heikkinen Release Manager -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: delta_qt511-beta4-qt511-rc.txt URL: From announce at qt-project.org Tue May 8 12:07:10 2018 From: announce at qt-project.org (List for announcements regarding Qt releases and development) Date: Tue, 8 May 2018 10:07:10 +0000 Subject: [Development] [Announce] Qt 5.11.0 RC released In-Reply-To: References: , Message-ID: Hi, We have released Qt 5.11.0 RC today. It is still online delivery only and you can get it via online installer as an update to existing installation or just doing fresh installation & selecting 5.11 rc from 'preview' section. br, Jani Heikkinen Release Manager _______________________________________________ Announce mailing list Announce at qt-project.org http://lists.qt-project.org/mailman/listinfo/announce From oleg.shalnev at gmail.com Tue May 8 15:36:21 2018 From: oleg.shalnev at gmail.com (Oleg Shalnev) Date: Tue, 08 May 2018 13:36:21 +0000 Subject: [Development] Strange behavior of cmake with Qt5.11.0 Message-ID: Good day! Neither cmake, nor qtcreator can't normal work with Qt5.11.0 Error processing cmake project file with error > CMake Error at ______________/CMakeLists.txt:28 (qt5_use_modules): > Unknown CMake command "qt5_use_modules". Linux __ 4.15.0-20-generic #21-Ubuntu SMP Tue Apr 24 06:16:15 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux cmake version 3.10.2 Qt 5.11.0-RC With Qt.5.10.1 All Ok Where can I read about this new cmake trick? Thanks a lot -- Oleg Shalnev (Kalpa Integration Initiative) ---------------------------------------------- e-mail : oleg at kalpa.ru , oleg.shalnev at gmail.com cell,Viber,WhatsUp,Telegram : +7 (918) 741 7217 -------------- next part -------------- An HTML attachment was scrubbed... URL: From hsnemrecetin at gmail.com Tue May 8 15:57:59 2018 From: hsnemrecetin at gmail.com (Emre Cetin) Date: Tue, 8 May 2018 16:57:59 +0300 Subject: [Development] QT included RTEMS Message-ID: Hi all, I have a project about compiling any QT demo with RTEMS Raspberry Pi1 BSP. I am trying with qt-everywhere-src-5.10-1 is it proper? I will use -linuxfb option and I am trying to use -xplatform option but how can I configure qmake.conf and qplatformdefs.h exectly for Rtems? Can you give me some advice ? With best regards, Emre -------------- next part -------------- An HTML attachment was scrubbed... URL: From edward.welbourne at qt.io Tue May 8 18:21:15 2018 From: edward.welbourne at qt.io (Edward Welbourne) Date: Tue, 8 May 2018 16:21:15 +0000 Subject: [Development] Recent QUIP activity Message-ID: Hi all, As ever, you can see current QUIP-related reviews at https://codereview.qt-project.org/#/q/status:open+project:meta/quips,n,z and find the (just now updated) current state of all QUIPs (with most of those changes) at: https://quips-qt-io.herokuapp.com Most recently active first: * QUIP 11: Jani has begun describing the release process * QUIP 10: I'm describing the API reviews before releases * QUIP 1 & template: Adding a template and refining Status * QUIP 99: Frederik is driving a discussion of QML versioning * QUIP 9: Ville is Evolving QList * QUIP 8: High-DPI Support The last two haven't had much activity lately. The QML versioning needs some creative ideas. QUIP 1: in the course of review of a template I added to make it easier to prepare QUIP-10, Ossi objected that the list of Status values (defined by QUIP-1) had more entries than we need. After some discussion, we've decided to prune the QUIP lifecycle, at least until someone can give us a good reason to make it more complicated again. So I'm modifying QUIP-1 to only have three status values: Active, Superseded and Withdrawn. See discussion on the review for how we got there. QUIP 10: I mentioned this in March. We have to decide who has the ultimate authority: naively, that would be each module's maintainer; but not every module has one and some modules have several. I've supposed, in reviews to date, that whoever gives the final +2 believes they have suitable authority, if only by virtue of the +1s they can see already. Who do folk think should have the final say on an API review ? QUIP 11: This is a new QUIP, please pay it a visit: Jani is describing our release process. If you think it can be improved, this is the place for suggestions. We might settle on honestly describing our existing process in the QUIP itself, but suggestions made here may help us to improve it in future. Here's the new review: * https://codereview.qt-project.org/228450 Please take a look at these QUIP changes and help us to give a better account of how we aim to do what we do, Eddy. From thiago.macieira at intel.com Tue May 8 20:40:41 2018 From: thiago.macieira at intel.com (Thiago Macieira) Date: Tue, 8 May 2018 11:40:41 -0700 Subject: [Development] QEasingCurve saving to QDataStream Message-ID: <4816326.HYkAc0Lba0@tjmaciei-mobl1> Does anyone remember the implementation details for this class? If so, can you help with https://bugreports.qt.io/browse/QTBUG-68181 ? I can clearly see parameters that are not properly saved to the stream, but I don't know which parameters need to be saved and which ones are computed only. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From Ch.Ehrlicher at gmx.de Tue May 8 21:42:37 2018 From: Ch.Ehrlicher at gmx.de (Christian Ehrlicher) Date: Tue, 8 May 2018 21:42:37 +0200 Subject: [Development] QEasingCurve saving to QDataStream In-Reply-To: <4816326.HYkAc0Lba0@tjmaciei-mobl1> References: <4816326.HYkAc0Lba0@tjmaciei-mobl1> Message-ID: <3989915d-b53d-61a9-598c-ffa9aea076ee@gmx.de> Am 08.05.2018 um 20:40 schrieb Thiago Macieira: > Does anyone remember the implementation details for this class? If so, can you > help with https://bugreports.qt.io/browse/QTBUG-68181 ? > > I can clearly see parameters that are not properly saved to the stream, but I > don't know which parameters need to be saved and which ones are computed only. I'm not sure if it helps but from my pov it would be enough to additionally save _bezierCurves when the type is QEasingCurve::BezierSpline and _bezierCurves and _tcbPoints when the type is QEasingCurve::TCBSpline. HTH, Christian From jani.heikkinen at qt.io Wed May 9 13:00:51 2018 From: jani.heikkinen at qt.io (Jani Heikkinen) Date: Wed, 9 May 2018 11:00:51 +0000 Subject: [Development] HEADS UP: Branching from '5.9' to '5.9.6' started Message-ID: Hi, We have soft branched '5.9.6' from '5.9' already today. This was done a bit earlier than informed but don't worry; final downmerge from '5.9' to '5.9.6' will happen Tue 22.5.2018 as planned. So there is now plenty of time to finalize ongoing changes in '5.9' and start using '5.9.6' for new changes targeted to Qt 5.9.6 release. Plan is to get Qt 5.9.6 out at the beginning of June br, Jani From d3faultdotxbe at gmail.com Wed May 9 13:37:59 2018 From: d3faultdotxbe at gmail.com (d3fault) Date: Wed, 9 May 2018 04:37:59 -0700 Subject: [Development] Why waste energy supporting Python? In-Reply-To: <676871524664490@web3g.yandex.ru> References: <676871524664490@web3g.yandex.ru> Message-ID: On 4/25/18, Konstantin Tokarev wrote: > 1. C++ is not modern, not safe, and by far not simple language > (despite having a lot of strengths in different areas) > https://www.youtube.com/watch?v=hEx5DNLWGgA From kevin.funk at kdab.com Wed May 9 16:56:29 2018 From: kevin.funk at kdab.com (Kevin Funk) Date: Wed, 09 May 2018 16:56:29 +0200 Subject: [Development] Strange behavior of cmake with Qt5.11.0 In-Reply-To: References: Message-ID: <6460526.tozhlOBF5o@kerberos> On Tuesday, 8 May 2018 15:36:21 CEST Oleg Shalnev wrote: > Good day! > Neither cmake, nor qtcreator can't normal work with Qt5.11.0 > Error processing cmake project file with error > > > CMake Error at ______________/CMakeLists.txt:28 (qt5_use_modules): > > Unknown CMake command "qt5_use_modules". Heya, The qt5_use_modules() function was deprecated since ages and finally got removed with Qt 5.11.0 [1]. But indeed, we're lacking a release note entry for that. Will add that. See this StackOverflow questions for a solution & explanation: https://stackoverflow.com/questions/31172156/what-to-use-instead-of-qt5-use-modules Or the first paragraph here from Qt's CMake manual: http://doc.qt.io/qt-5/cmake-manual.html Regards, Kevin [1] https://bugreports.qt.io/browse/QTBUG-63519 > Linux __ 4.15.0-20-generic #21-Ubuntu SMP Tue Apr 24 06:16:15 UTC 2018 > x86_64 x86_64 x86_64 GNU/Linux > cmake version 3.10.2 > Qt 5.11.0-RC > > With Qt.5.10.1 All Ok > Where can I read about this new cmake trick? > > Thanks a lot -- Kevin Funk | kevin.funk at kdab.com | Lead Sales Engineer KDAB (Deutschland) GmbH, a KDAB Group company Tel: +49-30-521325470 KDAB - The Qt, C++ and OpenGL Experts -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 5322 bytes Desc: not available URL: From aapo.keskimolo at qt.io Wed May 9 17:49:04 2018 From: aapo.keskimolo at qt.io (=?utf-8?B?QWFwbyBLZXNraW3DtmzDtg==?=) Date: Wed, 9 May 2018 15:49:04 +0000 Subject: [Development] Coin maintenance notification In-Reply-To: References: Message-ID: Coin will be down between 10-14 (EEST) on the coming Friday 11 May 2018 due to production update. The production update will clean old cached artifacts which will cause rebuilding of new builds. -----Original Message----- From: Aapo Keskimölö Sent: Thursday, April 26, 2018 10:32 AM To: development at qt-project.org Subject: RE: Coin maintenance notification Coin is back in operation and the storage should be fixed, now. Please check your staged commits. -----Original Message----- From: Aapo Keskimölö Sent: torstai 26. huhtikuuta 2018 9.28 To: 'development at qt-project.org' Subject: Coin maintenance notification The Coin service will go down until we fix the broken storage. We apologize for the inconvenience. Kind regards/Ystävällisin terveisin, Aapo Keskimölö From oleg.shalnev at gmail.com Thu May 10 07:55:51 2018 From: oleg.shalnev at gmail.com (Oleg Shalnev) Date: Thu, 10 May 2018 05:55:51 +0000 Subject: [Development] Strange behavior of cmake with Qt5.11.0 In-Reply-To: <6460526.tozhlOBF5o@kerberos> References: <6460526.tozhlOBF5o@kerberos> Message-ID: Thanks a lot! ср, 9 мая 2018 г. в 17:56, Kevin Funk : > On Tuesday, 8 May 2018 15:36:21 CEST Oleg Shalnev wrote: > > Good day! > > Neither cmake, nor qtcreator can't normal work with Qt5.11.0 > > Error processing cmake project file with error > > > > > CMake Error at ______________/CMakeLists.txt:28 (qt5_use_modules): > > > Unknown CMake command "qt5_use_modules". > > Heya, > > The qt5_use_modules() function was deprecated since ages and finally got > removed with Qt 5.11.0 [1]. But indeed, we're lacking a release note entry > for > that. Will add that. > > See this StackOverflow questions for a solution & explanation: > > https://stackoverflow.com/questions/31172156/what-to-use-instead-of-qt5-use-modules > > Or the first paragraph here from Qt's CMake manual: > http://doc.qt.io/qt-5/cmake-manual.html > > Regards, > Kevin > > > [1] https://bugreports.qt.io/browse/QTBUG-63519 > > > > Linux __ 4.15.0-20-generic #21-Ubuntu SMP Tue Apr 24 06:16:15 UTC 2018 > > x86_64 x86_64 x86_64 GNU/Linux > > cmake version 3.10.2 > > Qt 5.11.0-RC > > > > With Qt.5.10.1 All Ok > > Where can I read about this new cmake trick? > > > > Thanks a lot > > > -- > Kevin Funk | kevin.funk at kdab.com | Lead Sales Engineer > KDAB (Deutschland) GmbH, a KDAB Group company > Tel: +49-30-521325470 > KDAB - The Qt, C++ and OpenGL Experts -- Oleg Shalnev (Kalpa Integration Initiative) ---------------------------------------------- e-mail : oleg at kalpa.ru , oleg.shalnev at gmail.com cell,Viber,WhatsUp,Telegram : +7 (918) 741 7217 -------------- next part -------------- An HTML attachment was scrubbed... URL: From maxwell130631 at gmail.com Thu May 10 15:28:04 2018 From: maxwell130631 at gmail.com (James Maxwell) Date: Thu, 10 May 2018 15:28:04 +0200 Subject: [Development] Please Provide a QSGCircleNode and QSGLineNode Message-ID: Hi, I am developing a plotting library for use in QML and want to do the backend in c++. I think for many people it would be a good feature if you would provide something like a QSGCircleNode or a QSGLineNode by default. Drawing lines with a QSGGeometryNode and GL_LINE_STRIP is not really an option as anti-aliasing is missing and the line-width is limited to 10 pixels. And if I have to do all of this on my own, then QT does not offer much of an advantage compared to doing it in OpenGL directly. If you don't want to spend time on this, already giving the QQuickRectangle a public c++ api would be a progress as one could also use it to draw line-segments or circles. Best regards, Maxwell -------------- next part -------------- An HTML attachment was scrubbed... URL: From aapo.keskimolo at qt.io Fri May 11 15:47:24 2018 From: aapo.keskimolo at qt.io (=?utf-8?B?QWFwbyBLZXNraW3DtmzDtg==?=) Date: Fri, 11 May 2018 13:47:24 +0000 Subject: [Development] Coin maintenance notification In-Reply-To: References: Message-ID: We are still busy with rebuilding cache binaries for the main branches of qt5/pyside/qtwebkit/qt3dstudio. The service should be back in operation within the next 1-2 hours. -----Original Message----- From: Aapo Keskimölö Sent: Wednesday, May 9, 2018 5:49 PM To: development at qt-project.org Subject: Coin maintenance notification Coin will be down between 10-14 (EEST) on the coming Friday 11 May 2018 due to production update. The production update will clean old cached artifacts which will cause rebuilding of new builds. -----Original Message----- From: Aapo Keskimölö Sent: Thursday, April 26, 2018 10:32 AM To: development at qt-project.org Subject: RE: Coin maintenance notification Coin is back in operation and the storage should be fixed, now. Please check your staged commits. -----Original Message----- From: Aapo Keskimölö Sent: torstai 26. huhtikuuta 2018 9.28 To: 'development at qt-project.org' Subject: Coin maintenance notification The Coin service will go down until we fix the broken storage. We apologize for the inconvenience. Kind regards/Ystävällisin terveisin, Aapo Keskimölö From aapo.keskimolo at qt.io Fri May 11 17:07:25 2018 From: aapo.keskimolo at qt.io (=?utf-8?B?QWFwbyBLZXNraW3DtmzDtg==?=) Date: Fri, 11 May 2018 15:07:25 +0000 Subject: [Development] Coin maintenance notification In-Reply-To: References: Message-ID: The coin service is now listening to changes from Gerrit. We removed large amounts of old binaries and some modules might require to be rebuilt for that reason. -----Original Message----- From: Aapo Keskimölö Sent: Friday, May 11, 2018 3:47 PM To: 'development at qt-project.org' Subject: RE: Coin maintenance notification We are still busy with rebuilding cache binaries for the main branches of qt5/pyside/qtwebkit/qt3dstudio. The service should be back in operation within the next 1-2 hours. -----Original Message----- From: Aapo Keskimölö Sent: Wednesday, May 9, 2018 5:49 PM To: development at qt-project.org Subject: Coin maintenance notification Coin will be down between 10-14 (EEST) on the coming Friday 11 May 2018 due to production update. The production update will clean old cached artifacts which will cause rebuilding of new builds. -----Original Message----- From: Aapo Keskimölö Sent: Thursday, April 26, 2018 10:32 AM To: development at qt-project.org Subject: RE: Coin maintenance notification Coin is back in operation and the storage should be fixed, now. Please check your staged commits. -----Original Message----- From: Aapo Keskimölö Sent: torstai 26. huhtikuuta 2018 9.28 To: 'development at qt-project.org' Subject: Coin maintenance notification The Coin service will go down until we fix the broken storage. We apologize for the inconvenience. Kind regards/Ystävällisin terveisin, Aapo Keskimölö From philippeb8 at gmail.com Sun May 13 23:26:45 2018 From: philippeb8 at gmail.com (Phil Bouchard) Date: Sun, 13 May 2018 17:26:45 -0400 Subject: [Development] Fornux C++ Superset In-Reply-To: References: <1675379.mWTH3mOQWM@tjmaciei-mobl1> <4388948.g8Bl6hTZpn@tjmaciei-mobl1> Message-ID: On 04/26/2018 12:35 AM, Phil Bouchard wrote: > On 04/25/2018 12:36 PM, Edward Welbourne wrote: >>> memory leaks are the most difficult problems to solve. >> >> Well, no, they're not. >> I've fixed *lots and lots* of memory leaks. >> Some of them were a little tricky: most were trivial. >> I can *see* memory leaks just by reading code. >> It's one of the reasons code review makes memory leaks rare. >> That and nice sensible disciplines like RAII. >> >> Use-after-free is usually harder to solve than a leak. >> Deadlocks are almost always harder to solve. > > You're right: > 1) Deadlocks are much more difficult to find > 2) Then comes the use-after-free but they can be easily detected by > throwing an exception with root_ptr > 3) Then we have the memory leaks... I made a mistake here: use-after-free problems are actually easily solved by FCXXSS because it discards all explicit calls to "delete" and implicitly use them where they belong. So it's impossible to face that problem. In fact I have prepared a summary of our discussion and you can see the execution of my previous example in real-time here: https://youtu.be/vZL5X2FlZKU Regards, -Phil From nassian at bitshift-dynamics.com Mon May 14 00:35:08 2018 From: nassian at bitshift-dynamics.com (Alexander Nassian) Date: Mon, 14 May 2018 00:35:08 +0200 Subject: [Development] Fornux C++ Superset In-Reply-To: References: <1675379.mWTH3mOQWM@tjmaciei-mobl1> <4388948.g8Bl6hTZpn@tjmaciei-mobl1> Message-ID: <42ADF164-FE52-4CEC-8740-63E159029C0C@bitshift-dynamics.com> OMFG, besides that these are not the most difficult problems in programming, ... that computer voice that just reads what the presentation says. Youtube Videos are not the messias, if it’s just a written down text, publish it as text. Why a voice that reads 1:1 what is visible on the screen? If you would‘ve slow it down you would at least get money from ads :D > Am 13.05.2018 um 23:26 schrieb Phil Bouchard : > >> On 04/26/2018 12:35 AM, Phil Bouchard wrote: >> On 04/25/2018 12:36 PM, Edward Welbourne wrote: >>>> memory leaks are the most difficult problems to solve. >>> >>> Well, no, they're not. >>> I've fixed *lots and lots* of memory leaks. >>> Some of them were a little tricky: most were trivial. >>> I can *see* memory leaks just by reading code. >>> It's one of the reasons code review makes memory leaks rare. >>> That and nice sensible disciplines like RAII. >>> >>> Use-after-free is usually harder to solve than a leak. >>> Deadlocks are almost always harder to solve. >> You're right: >> 1) Deadlocks are much more difficult to find >> 2) Then comes the use-after-free but they can be easily detected by throwing an exception with root_ptr >> 3) Then we have the memory leaks... > > I made a mistake here: use-after-free problems are actually easily solved by FCXXSS because it discards all explicit calls to "delete" and implicitly use them where they belong. So it's impossible to face that problem. > > In fact I have prepared a summary of our discussion and you can see the execution of my previous example in real-time here: > https://youtu.be/vZL5X2FlZKU > > > Regards, > -Phil > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development -- — bitshift dynamics GmbH Neudorfer Str. 1, 79541 Lörrach Registergericht: Amtsgericht Freiburg i. Breisgau, HRB 713747 Geschäftsführer: Alexander Nassian, Markus Pfaffinger http://www.bitshift-dynamics.de Zentrale: +49 762158673 - 0 Fax: +49 7621 58673 - 90 Allgemeine Anfragen: info at bitshift-dynamics.com Technischer Support: support at bitshift-dynamics.com Buchhaltung: invoice at bitshift-dynamics.com From philippeb8 at gmail.com Mon May 14 00:45:18 2018 From: philippeb8 at gmail.com (Phil Bouchard) Date: Sun, 13 May 2018 18:45:18 -0400 Subject: [Development] Fornux C++ Superset In-Reply-To: <42ADF164-FE52-4CEC-8740-63E159029C0C@bitshift-dynamics.com> References: <1675379.mWTH3mOQWM@tjmaciei-mobl1> <4388948.g8Bl6hTZpn@tjmaciei-mobl1> <42ADF164-FE52-4CEC-8740-63E159029C0C@bitshift-dynamics.com> Message-ID: On 05/13/2018 06:35 PM, Alexander Nassian wrote: > OMFG, besides that these are not the most difficult problems in programming, ... that computer voice that just reads what the presentation says. Youtube Videos are not the messias, if it’s just a written down text, publish it as text. Why a voice that reads 1:1 what is visible on the screen? If you would‘ve slow it down you would at least get money from ads :D Some people are auditory while other are visual. And a synthesized voice because I skip the squelch detection process of the background noice coming from a human recorded voice. Regards, -Phil From annulen at yandex.ru Mon May 14 12:22:17 2018 From: annulen at yandex.ru (Konstantin Tokarev) Date: Mon, 14 May 2018 13:22:17 +0300 Subject: [Development] Fornux C++ Superset In-Reply-To: References: <1675379.mWTH3mOQWM@tjmaciei-mobl1> <4388948.g8Bl6hTZpn@tjmaciei-mobl1> <42ADF164-FE52-4CEC-8740-63E159029C0C@bitshift-dynamics.com> Message-ID: <1292791526293337@web48j.yandex.ru> 14.05.2018, 01:45, "Phil Bouchard" : > On 05/13/2018 06:35 PM, Alexander Nassian wrote: >>  OMFG, besides that these are not the most difficult problems in programming, ... that computer voice that just reads what the presentation says. Youtube Videos are not the messias, if it’s just a written down text, publish it as text. Why a voice that reads 1:1 what is visible on the screen? If you would‘ve slow it down you would at least get money from ads :D > > Some people are auditory while other are visual. And a synthesized voice > because I skip the squelch detection process of the background noice > coming from a human recorded voice. You just need to buy a good mic and a good sound card to get rid of noise. You can also suppress noise by applying filter, any recording software can do that. -- Regards, Konstantin From philippeb8 at gmail.com Mon May 14 13:29:35 2018 From: philippeb8 at gmail.com (Phil Bouchard) Date: Mon, 14 May 2018 07:29:35 -0400 Subject: [Development] Fornux C++ Superset In-Reply-To: <1292791526293337@web48j.yandex.ru> References: <1675379.mWTH3mOQWM@tjmaciei-mobl1> <4388948.g8Bl6hTZpn@tjmaciei-mobl1> <42ADF164-FE52-4CEC-8740-63E159029C0C@bitshift-dynamics.com> <1292791526293337@web48j.yandex.ru> Message-ID: On 05/14/2018 06:22 AM, Konstantin Tokarev wrote: > > > 14.05.2018, 01:45, "Phil Bouchard" : >> On 05/13/2018 06:35 PM, Alexander Nassian wrote: >>>  OMFG, besides that these are not the most difficult problems in programming, ... that computer voice that just reads what the presentation says. Youtube Videos are not the messias, if it’s just a written down text, publish it as text. Why a voice that reads 1:1 what is visible on the screen? If you would‘ve slow it down you would at least get money from ads :D >> >> Some people are auditory while other are visual. And a synthesized voice >> because I skip the squelch detection process of the background noice >> coming from a human recorded voice. > > You just need to buy a good mic and a good sound card to get rid of noise. > > You can also suppress noise by applying filter, any recording software can do that. I do have a professional microphone but I still need to use some filtering software. Here is the proof I have tried it in the past and Tamara's voice was distorted: https://youtu.be/0aBrmRS1TRQ (BTW you can also see I am the first one who came up with the: "Make America Great Again" slogan -- 2:58) But thanks for your advice, I will do what you suggest in the future. Regards, -Phil From erkam.murat.bozkurt at gmail.com Tue May 15 22:03:19 2018 From: erkam.murat.bozkurt at gmail.com (Erkam Murat Bozkurt) Date: Tue, 15 May 2018 23:03:19 +0300 Subject: [Development] ThreadStack Project: an innovative open-source software for multi-thread computing Message-ID: I have developed a new open source software as a result of a scientific research and I want to share my study with scientists and/or software developers. ThreadStack is an innovative software which produces a class library for C++ multi-thread programming and the outcome of the ThreadStack acts as an autonomous management system for the thread synchronization tasks. ThreadStack has a nice and useful graphical user interface and includes a short tutorial and code examples. ThreadStack offers a new way for multi-thread computing and it uses a meta program in order to produce an application specific thread synchronization library. Therefore, the programmer must read the tutorial to be able to use the software. The tutorial includes the main designs of the program. Not surprisingly, application development with the ThreadStack is much more easy than the classical C++ threading libraries thanks to the its autonomous management system. Currently, ThreadStack runs only on Linux based operating systems. In the near future, it will be runnable for the other operating systems. An academic journal submission has been performed for the study and the scientific introduction of the project will be readable from an academic journal as soon as possible. I believe that I can improve my knowledge and my software may be better with your advices. ThreadStack can be downloaded from sourcefource and link is given in below. https://sourceforge.net/projects/threadstack/ threadstack.help at gmail.com I am waiting your valuable comments. Thanks and best regards. Erkam Murat Bozkurt, M. Sc Control Systems Engineering. Istanbul / Turkey -------------- next part -------------- An HTML attachment was scrubbed... URL: From tuukka.turunen at qt.io Wed May 16 11:20:45 2018 From: tuukka.turunen at qt.io (Tuukka Turunen) Date: Wed, 16 May 2018 09:20:45 +0000 Subject: [Development] Code contributions via bug reports and forum posts Message-ID: <945D6EC6-98E1-4D00-8468-136A42B1F84F@qt.io> Hi, Contribution of source code is now allowed via Qt systems such as bug reports and forums. Traditionally all source code contributions to the Qt Project are governed via Contribution License Agreement (CLA), except possibility given to the commercial license holders to provide bug fixes and similar small modifications that The Qt Company has pushed into Qt. We have now updated the Qt Account service terms to more clearly state that source code can be contributed via the Qt systems. The preferred way to contribute source code to the Qt Project is still via the CLA, according to the contribution guidelines. But sometimes a user who has not accepted the CLA has a patch that would, for example, fix a bug in Qt. Providing such a patch is now also possible via the Qt systems, for example via the bug reports or forum posts. Please check a blog post for more information: http://blog.qt.io/blog/2018/05/16/code-contributions-via-bug-reports-forum-posts/ Note that any existing source code in the systems is not covered, only items pushed from now on. Yours, Tuukka -------------- next part -------------- An HTML attachment was scrubbed... URL: From thiago.macieira at intel.com Wed May 16 18:06:59 2018 From: thiago.macieira at intel.com (Thiago Macieira) Date: Wed, 16 May 2018 09:06:59 -0700 Subject: [Development] Code contributions via bug reports and forum posts In-Reply-To: <945D6EC6-98E1-4D00-8468-136A42B1F84F@qt.io> References: <945D6EC6-98E1-4D00-8468-136A42B1F84F@qt.io> Message-ID: <3442451.H4V6bSfSvk@tjmaciei-mobl1> On Wednesday, 16 May 2018 02:20:45 PDT Tuukka Turunen wrote: > Contribution of source code is now allowed via Qt systems such as bug > reports and forums. Traditionally all source code contributions to the Qt > Project are governed via Contribution License Agreement (CLA), except > possibility given to the commercial license holders to provide bug fixes > and similar small modifications that The Qt Company has pushed into Qt. We > have now updated the Qt Account service terms to more clearly state that > source code can be contributed via the Qt systems. The preferred way to > contribute source code to the Qt Project is still via the CLA, according to > the contribution guidelines. But sometimes a user who has not accepted the > CLA has a patch that would, for example, fix a bug in Qt. Providing such a > patch is now also possible via the Qt systems, for example via the bug > reports or forum posts. > > Please check a blog post for more information: > http://blog.qt.io/blog/2018/05/16/code-contributions-via-bug-reports-forum-> posts/ "n addition to the license above in Section 3 granted to the Content, you as User may decide to give The Qt Company input or feedback (including but not limited to software code) on the Services or relating to your Subscription (“Feedback”). You grant to The Qt Company ..." Please note this grants The Qt Company this right, presumably because that "Feedback" is submitted to a web service they control. For other people in the Qt Project, nothing changes: you (and I) are not allowed to pick up patches submitted to the bug reporting system or forums and apply it to Qt no more than we are allowed to pick up patches submitted to Stack Overflow or pastebin.com. To all users: please continue submitting contributions through the contribution system as much as you can. Submitting patches via the bug reporting tool may not work if the assignee or maintainer in question does not work for the Qt Company and there's no one who does that is willing to accept the responsibility of submitting it on your behalf. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From thiago.macieira at intel.com Wed May 16 18:19:17 2018 From: thiago.macieira at intel.com (Thiago Macieira) Date: Wed, 16 May 2018 09:19:17 -0700 Subject: [Development] Urgent help needed: determining endianness at compile time in INTEGRITY Message-ID: <2109918.4Po2X9OpSh@tjmaciei-mobl1> We've got a change blocked because some third-party code is unable to find a macro that determines the endianness of the target while compiling with GHS's compiler for INTEGRITY. Can someone help? Any of the following would help: (a) documentation link stating what macro is set (b) a simple test program in C that shows how to determine the endianness at compile time (c) a function that does 64-bit host-to-network and back conversions on INTEGRITY (d) an actual patch to TinyCBOR - https://github.com/intel/tinycbor (file src/compilersupport_p.h) Please note that Qt doesn't seem to have a problem -- qprocessordetection.h has an #error and it's not triggering. So it would seem Qt has a solution. I have not looked at the code because I need to submit to the third-party and I need therefore MIT-licensed solutions. A Qt Company employee could open qprocessordetection.h and determine how it makes this work -- the only other copyright holder of relevance in that file is Intel. For reference, TinyCBOR already tries these tests: __BYTE_ORDER__ == __ORDER_BIG_ENDIAN__ __BYTE_ORDER == __BIG_ENDIAN BYTE_ORDER == BIG_ENDIAN defined(__ARMEB__) || defined(__MIPSEB__) || defined(__sparc__) __BYTE_ORDER__ == __ORDER_LITTLE_ENDIAN__ __BYTE_ORDER == __LITTLE_ENDIAN BYTE_ORDER == LITTLE_ENDIAN defined(__ARMEL__) || defined(__i386) || defined(__i386__) || defined(__x86_64) || defined(__x86_64__) || \ defined(__amd64) || defined(__MIPSEL__) It's possible it's one of those and there's something else wrong. I don't have access to the toolchain and therefore can't test to see what it is. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From oswald.buddenhagen at qt.io Wed May 16 18:31:56 2018 From: oswald.buddenhagen at qt.io (Oswald Buddenhagen) Date: Wed, 16 May 2018 18:31:56 +0200 Subject: [Development] Code contributions via bug reports and forum posts In-Reply-To: <3442451.H4V6bSfSvk@tjmaciei-mobl1> References: <945D6EC6-98E1-4D00-8468-136A42B1F84F@qt.io> <3442451.H4V6bSfSvk@tjmaciei-mobl1> Message-ID: <20180516163156.GA28059@nubble.lan> On Wed, May 16, 2018 at 09:06:59AM -0700, Thiago Macieira wrote: > Please note this grants The Qt Company this right, presumably because > that "Feedback" is submitted to a web service they control. > uh? it does because it's submitted to a service which has these TOS. you could put the same terms on a site *you* control, and the benefactor would still be tqtc. > For other people in the Qt Project, nothing changes: you (and I) are > not allowed to pick up patches submitted to the bug reporting system > or forums and apply it to Qt no more than we are allowed to pick up > patches submitted to Stack Overflow or pastebin.com. > that's nonsense. you wouldn't be using the code for your own purposes, but just acting as a proxy, re-submitting the code under terms the author has already accepted, including attribution. IANAL, blah blah blah. From thiago.macieira at intel.com Wed May 16 18:46:57 2018 From: thiago.macieira at intel.com (Thiago Macieira) Date: Wed, 16 May 2018 09:46:57 -0700 Subject: [Development] Code contributions via bug reports and forum posts In-Reply-To: <20180516163156.GA28059@nubble.lan> References: <945D6EC6-98E1-4D00-8468-136A42B1F84F@qt.io> <3442451.H4V6bSfSvk@tjmaciei-mobl1> <20180516163156.GA28059@nubble.lan> Message-ID: <4032094.MckV1LNiH1@tjmaciei-mobl1> On Wednesday, 16 May 2018 09:31:56 PDT Oswald Buddenhagen wrote: > On Wed, May 16, 2018 at 09:06:59AM -0700, Thiago Macieira wrote: > > Please note this grants The Qt Company this right, presumably because > > that "Feedback" is submitted to a web service they control. > > uh? it does because it's submitted to a service which has these TOS. you > could put the same terms on a site *you* control, and the benefactor > would still be tqtc. The point is that the grant is being made to The Qt Company and the grant only applies because it is done by using a service that TQtC controls. > > For other people in the Qt Project, nothing changes: you (and I) are > > not allowed to pick up patches submitted to the bug reporting system > > or forums and apply it to Qt no more than we are allowed to pick up > > patches submitted to Stack Overflow or pastebin.com. > > that's nonsense. you wouldn't be using the code for your own purposes, > but just acting as a proxy, re-submitting the code under terms the > author has already accepted, including attribution. > > IANAL, blah blah blah. My IANAL reading is that I'm not allowed. I don't see anywhere in the Qt Account agreement that says a third party is allowed to pick up the code and submit it through the CLA. Or, in my case, through the CCLA that applies between Intel and The Qt Company. So I will continue not to do it. Patches to JIRA will continue to be ignored and will mostly go unread in the first place. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From oswald.buddenhagen at qt.io Wed May 16 19:02:42 2018 From: oswald.buddenhagen at qt.io (Oswald Buddenhagen) Date: Wed, 16 May 2018 19:02:42 +0200 Subject: [Development] Code contributions via bug reports and forum posts In-Reply-To: <4032094.MckV1LNiH1@tjmaciei-mobl1> References: <945D6EC6-98E1-4D00-8468-136A42B1F84F@qt.io> <3442451.H4V6bSfSvk@tjmaciei-mobl1> <20180516163156.GA28059@nubble.lan> <4032094.MckV1LNiH1@tjmaciei-mobl1> Message-ID: <20180516170242.GA31325@nubble.lan> On Wed, May 16, 2018 at 09:46:57AM -0700, Thiago Macieira wrote: > On Wednesday, 16 May 2018 09:31:56 PDT Oswald Buddenhagen wrote: > > On Wed, May 16, 2018 at 09:06:59AM -0700, Thiago Macieira wrote: > > > Please note this grants The Qt Company this right, presumably because > > > that "Feedback" is submitted to a web service they control. > > > > uh? it does because it's submitted to a service which has these TOS. you > > could put the same terms on a site *you* control, and the benefactor > > would still be tqtc. > > The point is that the grant is being made to The Qt Company and the grant only > applies because it is done by using a service that TQtC controls. > no, it *doesn't*. your interpretation is absurd. > > > For other people in the Qt Project, nothing changes: you (and I) are > > > not allowed to pick up patches submitted to the bug reporting system > > > or forums and apply it to Qt no more than we are allowed to pick up > > > patches submitted to Stack Overflow or pastebin.com. > > > > that's nonsense. you wouldn't be using the code for your own purposes, > > but just acting as a proxy, re-submitting the code under terms the > > author has already accepted, including attribution. > > > > IANAL, blah blah blah. > > My IANAL reading is that I'm not allowed. I don't see anywhere in the Qt > Account agreement that says a third party is allowed to pick up the code and > submit it through the CLA. > you wouldn't be submitting it under CLA (though you need it for purely technical reasons). qt employees obviously also don't submit under the CLA (because the code is already owned by tqtc) even though we use the same technical process. also note that the TOS grant of rights is essentially the same as the central grant in the CLA, just a bit less verbose. From thiago.macieira at intel.com Wed May 16 19:40:23 2018 From: thiago.macieira at intel.com (Thiago Macieira) Date: Wed, 16 May 2018 10:40:23 -0700 Subject: [Development] Code contributions via bug reports and forum posts In-Reply-To: <20180516170242.GA31325@nubble.lan> References: <945D6EC6-98E1-4D00-8468-136A42B1F84F@qt.io> <4032094.MckV1LNiH1@tjmaciei-mobl1> <20180516170242.GA31325@nubble.lan> Message-ID: <1984304.hNEVTbi4z4@tjmaciei-mobl1> On Wednesday, 16 May 2018 10:02:42 PDT Oswald Buddenhagen wrote: > > My IANAL reading is that I'm not allowed. I don't see anywhere in the Qt > > Account agreement that says a third party is allowed to pick up the code > > and submit it through the CLA. > > you wouldn't be submitting it under CLA (though you need it for > purely technical reasons). qt employees obviously also don't submit > under the CLA (because the code is already owned by tqtc) even though we > use the same technical process. You have not convinced me enough. I will continue to ignore patches in JIRA. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From coroberti at gmail.com Wed May 16 19:56:32 2018 From: coroberti at gmail.com (coroberti .) Date: Wed, 16 May 2018 20:56:32 +0300 Subject: [Development] [Interest] Code contributions via bug reports and forum posts In-Reply-To: <945D6EC6-98E1-4D00-8468-136A42B1F84F@qt.io> References: <945D6EC6-98E1-4D00-8468-136A42B1F84F@qt.io> Message-ID: Hi, This is a very positive and long anticipated development. Excellent! Kind regards, Robert On Wed, May 16, 2018 at 12:20 PM, Tuukka Turunen wrote: > > > Hi, > > > > Contribution of source code is now allowed via Qt systems such as bug > reports and forums. Traditionally all source code contributions to the Qt > Project are governed via Contribution License Agreement (CLA), except > possibility given to the commercial license holders to provide bug fixes and > similar small modifications that The Qt Company has pushed into Qt. We have > now updated the Qt Account service terms to more clearly state that source > code can be contributed via the Qt systems. The preferred way to contribute > source code to the Qt Project is still via the CLA, according to the > contribution guidelines. But sometimes a user who has not accepted the CLA > has a patch that would, for example, fix a bug in Qt. Providing such a patch > is now also possible via the Qt systems, for example via the bug reports or > forum posts. > > > > Please check a blog post for more information: > http://blog.qt.io/blog/2018/05/16/code-contributions-via-bug-reports-forum-posts/ > > > > Note that any existing source code in the systems is not covered, only items > pushed from now on. > > > > Yours, > > > > Tuukka > > > > > > > _______________________________________________ > Interest mailing list > Interest at qt-project.org > http://lists.qt-project.org/mailman/listinfo/interest > From Kimmo.Ollila at qt.io Thu May 17 08:26:27 2018 From: Kimmo.Ollila at qt.io (Kimmo Ollila) Date: Thu, 17 May 2018 06:26:27 +0000 Subject: [Development] Urgent help needed: determining endianness at compile time in INTEGRITY In-Reply-To: <2109918.4Po2X9OpSh@tjmaciei-mobl1> References: <2109918.4Po2X9OpSh@tjmaciei-mobl1> Message-ID: Hi, >From INTEGRITY documentation I found the following macros: Endianness Macros One of these symbols is always defined to specify the endianness of the target processor. __BIG_ENDIAN__ Big Endian byte order. __LITTLE_ENDIAN__ Little Endian byte order. I tested and these are working. Best regards, Kimmo Ollila -----Original Message----- From: Development On Behalf Of Thiago Macieira Sent: keskiviikkona 16. toukokuuta 2018 19.19 To: development at qt-project.org Subject: [Development] Urgent help needed: determining endianness at compile time in INTEGRITY We've got a change blocked because some third-party code is unable to find a macro that determines the endianness of the target while compiling with GHS's compiler for INTEGRITY. Can someone help? Any of the following would help: (a) documentation link stating what macro is set (b) a simple test program in C that shows how to determine the endianness at compile time (c) a function that does 64-bit host-to-network and back conversions on INTEGRITY (d) an actual patch to TinyCBOR - https://github.com/intel/tinycbor (file src/compilersupport_p.h) Please note that Qt doesn't seem to have a problem -- qprocessordetection.h has an #error and it's not triggering. So it would seem Qt has a solution. I have not looked at the code because I need to submit to the third-party and I need therefore MIT-licensed solutions. A Qt Company employee could open qprocessordetection.h and determine how it makes this work -- the only other copyright holder of relevance in that file is Intel. For reference, TinyCBOR already tries these tests: __BYTE_ORDER__ == __ORDER_BIG_ENDIAN__ __BYTE_ORDER == __BIG_ENDIAN BYTE_ORDER == BIG_ENDIAN defined(__ARMEB__) || defined(__MIPSEB__) || defined(__sparc__) __BYTE_ORDER__ == __ORDER_LITTLE_ENDIAN__ __BYTE_ORDER == __LITTLE_ENDIAN BYTE_ORDER == LITTLE_ENDIAN defined(__ARMEL__) || defined(__i386) || defined(__i386__) || defined(__x86_64) || defined(__x86_64__) || \ defined(__amd64) || defined(__MIPSEL__) It's possible it's one of those and there's something else wrong. I don't have access to the toolchain and therefore can't test to see what it is. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center _______________________________________________ Development mailing list Development at qt-project.org http://lists.qt-project.org/mailman/listinfo/development From thiago.macieira at intel.com Thu May 17 08:46:34 2018 From: thiago.macieira at intel.com (Thiago Macieira) Date: Wed, 16 May 2018 23:46:34 -0700 Subject: [Development] Urgent help needed: determining endianness at compile time in INTEGRITY In-Reply-To: References: <2109918.4Po2X9OpSh@tjmaciei-mobl1> Message-ID: <2749992.gDyi8lJEAm@tjmaciei-mobl1> On Wednesday, 16 May 2018 23:26:27 PDT Kimmo Ollila wrote: > Endianness Macros > One of these symbols is always defined to specify the endianness of the > target processor. > > __BIG_ENDIAN__ > Big Endian byte order. > > __LITTLE_ENDIAN__ > Little Endian byte order. So they are defined but not required to be equal to something? Ok, will change the change. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From Kimmo.Ollila at qt.io Thu May 17 08:51:44 2018 From: Kimmo.Ollila at qt.io (Kimmo Ollila) Date: Thu, 17 May 2018 06:51:44 +0000 Subject: [Development] Urgent help needed: determining endianness at compile time in INTEGRITY In-Reply-To: <2749992.gDyi8lJEAm@tjmaciei-mobl1> References: <2109918.4Po2X9OpSh@tjmaciei-mobl1> <2749992.gDyi8lJEAm@tjmaciei-mobl1> Message-ID: > So they are defined but not required to be equal to something? Yup, that's right Regards, Kimmo Ollila -----Original Message----- From: Development On Behalf Of Thiago Macieira Sent: torstaina 17. toukokuuta 2018 9.47 To: development at qt-project.org Subject: Re: [Development] Urgent help needed: determining endianness at compile time in INTEGRITY On Wednesday, 16 May 2018 23:26:27 PDT Kimmo Ollila wrote: > Endianness Macros > One of these symbols is always defined to specify the endianness of > the target processor. > > __BIG_ENDIAN__ > Big Endian byte order. > > __LITTLE_ENDIAN__ > Little Endian byte order. So they are defined but not required to be equal to something? Ok, will change the change. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center _______________________________________________ Development mailing list Development at qt-project.org http://lists.qt-project.org/mailman/listinfo/development From tuukka.turunen at qt.io Thu May 17 09:28:19 2018 From: tuukka.turunen at qt.io (Tuukka Turunen) Date: Thu, 17 May 2018 07:28:19 +0000 Subject: [Development] Code contributions via bug reports and forum posts In-Reply-To: <3442451.H4V6bSfSvk@tjmaciei-mobl1> References: <945D6EC6-98E1-4D00-8468-136A42B1F84F@qt.io> <3442451.H4V6bSfSvk@tjmaciei-mobl1> Message-ID: On 16/05/2018, 19.07, "Development on behalf of Thiago Macieira" wrote: > > To all users: please continue submitting contributions through the > contribution system as much as you can. Submitting patches via the bug > reporting tool may not work if the assignee or maintainer in question does not > work for the Qt Company and there's no one who does that is willing to accept > the responsibility of submitting it on your behalf. Yes, absolutely. We should not reduce normal codereview use. For any of these "casual contributions", someone needs to do the work to get the patch in via codereview (and in most cases also do some changes to the patch as well). Intention is not do regular contributions in this way, just to allow similar approach for all users as has been the case for commercial license holders since ages. Yours, Tuukka From alexander.blasche at qt.io Thu May 17 10:14:15 2018 From: alexander.blasche at qt.io (Alex Blasche) Date: Thu, 17 May 2018 08:14:15 +0000 Subject: [Development] Naming convention for (scoped) enums Message-ID: Hi, The naming conventions for enums state that each enum value name must repeat a part of the enum Type name (for details see https://wiki.qt.io/API_Design_Principles#Naming_Enum_Types_and_Values) In case of scoped enums this becomes a superfluous rule as the type has to be mentioned anyway. Does anybody object to modifying the above definition by adding an exception for scoped enums where you do not have to repeat a part of the enum type name? -- Alex From alexander.blasche at qt.io Thu May 17 10:19:55 2018 From: alexander.blasche at qt.io (Alex Blasche) Date: Thu, 17 May 2018 08:19:55 +0000 Subject: [Development] =?iso-8859-1?q?Nominating_M=E5rten_Nordheim_as_an_?= =?iso-8859-1?q?approver?= In-Reply-To: References: Message-ID: Congratulations to Mårten. The rights have been adjusted. -- Alex ________________________________________ From: Development on behalf of Edward Welbourne Sent: Wednesday, 25 April 2018 1:40:41 PM To: development at qt-project.org Subject: [Development] Nominating Mårten Nordheim as an approver Hi all, I'd like to nominate Mårten Nordheim for Approver. We've had him here at TQtC, in the Core & Network team, for a bit over a year; he's been reviewing steadily and finding mistakes I miss. As well as diverse work in qtbase, he's also dabbled in the qtnetworkauth and qtwebsockets modules. Here's his list of changes in gerrit: https://codereview.qt-project.org/#/q/owner:"M%25C3%25A5rten+Nordheim",n,z and the (somewhat busier) list of what he's reviewed: https://codereview.qt-project.org/#/q/reviewer:"M%25C3%25A5rten+Nordheim",n,z Eddy. _______________________________________________ Development mailing list Development at qt-project.org http://lists.qt-project.org/mailman/listinfo/development From giuseppe.dangelo at kdab.com Thu May 17 10:24:48 2018 From: giuseppe.dangelo at kdab.com (Giuseppe D'Angelo) Date: Thu, 17 May 2018 10:24:48 +0200 Subject: [Development] Naming convention for (scoped) enums In-Reply-To: References: Message-ID: <08586250-469c-3804-8360-bd99b72fa4d0@kdab.com> Il 17/05/2018 10:14, Alex Blasche ha scritto: > In case of scoped enums this becomes a superfluous rule as the type has to be mentioned anyway. Does anybody object to modifying the above definition by adding an exception for scoped enums where you do not have to repeat a part of the enum type name? I approve of the change. In Qt 5.11 we've already started introducing enum classes that do not repeat the enumeration name in the enumerators (e.g. QAbstractItemModel::CheckIndexOption). I would also double-down and say that every new enumeration in Qt has to be an enum class. My 2 cents, -- Giuseppe D'Angelo | giuseppe.dangelo at 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4007 bytes Desc: Firma crittografica S/MIME URL: From Tor.arne.Vestbo at qt.io Thu May 17 10:31:44 2018 From: Tor.arne.Vestbo at qt.io (=?iso-8859-1?Q?Tor_Arne_Vestb=F8?=) Date: Thu, 17 May 2018 08:31:44 +0000 Subject: [Development] Naming convention for (scoped) enums In-Reply-To: References: Message-ID: > On 17 May 2018, at 10:14, Alex Blasche wrote: > > Hi, > > The naming conventions for enums state that each enum value name must repeat a part of the enum Type name (for details see https://wiki.qt.io/API_Design_Principles#Naming_Enum_Types_and_Values) > > In case of scoped enums this becomes a superfluous rule as the type has to be mentioned anyway. Does anybody object to modifying the above definition by adding an exception for scoped enums where you do not have to repeat a part of the enum type name? Sounds like a sensible thing +1 Tor Arne > -- > Alex > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development From christian.kandeler at qt.io Thu May 17 10:35:38 2018 From: christian.kandeler at qt.io (Christian Kandeler) Date: Thu, 17 May 2018 10:35:38 +0200 Subject: [Development] Naming convention for (scoped) enums In-Reply-To: References: Message-ID: <20180517103538.221f0e85@ckandeler-archlinux> On Thu, 17 May 2018 08:14:15 +0000 Alex Blasche wrote: > The naming conventions for enums state that each enum value name must repeat a part of the enum Type name (for details see https://wiki.qt.io/API_Design_Principles#Naming_Enum_Types_and_Values) > > In case of scoped enums this becomes a superfluous rule as the type has to be mentioned anyway. Does anybody object to modifying the above definition by adding an exception for scoped enums where you do not have to repeat a part of the enum type name? I would not have even assumed that the rule applies to scoped enums, but it can't hurt to write it down explicitly. Perhaps the section should be rewritten so that the unscoped enums are the special case rather than the other way around. Christian From jani.heikkinen at qt.io Fri May 18 11:26:23 2018 From: jani.heikkinen at qt.io (Jani Heikkinen) Date: Fri, 18 May 2018 09:26:23 +0000 Subject: [Development] Qt 5.11.0 RC2 out In-Reply-To: References: Message-ID: Hi, We have released Qt 5.11.0 RC2 today. Delta to RC(1) release can be found as an attachment. We are still targeting to release Qt 5.11.0 Tue 22nd May as planned br, Jani -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: delta_qt511-rc-qt511-rc2.txt URL: From alexander.blasche at qt.io Fri May 18 11:27:50 2018 From: alexander.blasche at qt.io (Alex Blasche) Date: Fri, 18 May 2018 09:27:50 +0000 Subject: [Development] =?iso-8859-1?q?Nominating_J=FCri_Valdmann_for_Appr?= =?iso-8859-1?q?over_status?= In-Reply-To: References: Message-ID: Congratulations to Jüri. The rights have been adjusted. -- Alex ________________________________________ From: Development on behalf of Michal Klocek Sent: Friday, 27 April 2018 10:58:20 AM To: development at qt-project.org Subject: [Development] Nominating Jüri Valdmann for Approver status Hi I would like to nominate Jüri Valdmann for Approver. He joined The Qt Company more than one year ago and he's been doing most of his excellent work for QtWebEngine. You can see his contributions here: https://codereview.qt-project.org/#/q/owner:%22J%C3%BCri%20Valdmann%22,n,z Br Michal _______________________________________________ Development mailing list Development at qt-project.org http://lists.qt-project.org/mailman/listinfo/development From Kai.Koehne at qt.io Fri May 18 16:36:37 2018 From: Kai.Koehne at qt.io (Kai Koehne) Date: Fri, 18 May 2018 14:36:37 +0000 Subject: [Development] Repository Request: qt/licensing Message-ID: Hi, I'd like to request the creation of a repository "qt/licensing" on codereview.qt-project.org. This will become an optional git submodule of qtbase (checkout: qtbase/licensing). The repository will contain the Licenses and binary files (licheck*) that are so far only in our commercial source packages. The goal is to allow proper commercial builds from git, see also https://bugreports.qt.io/browse/QTBUG-52222. As such, the repository should be readable by everyone, but write access should be limited to The Qt Company. Kai -- Kai Koehne, Senior Manager R&D | The Qt Company The Qt Company GmbH, Rudower Chaussee 13, D-12489 Berlin Geschäftsführer: Mika Pälsi, Juha Varelius, Mika Harjuaho. Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 144331 B From bstottle at ford.com Fri May 18 16:45:20 2018 From: bstottle at ford.com (Stottlemyer, Brett (B.S.)) Date: Fri, 18 May 2018 14:45:20 +0000 Subject: [Development] Repository Request: qt/licensing Message-ID: On 5/18/18, 10:36 AM, "Development on behalf of Kai Koehne" wrote: Hi, I'd like to request the creation of a repository "qt/licensing" on codereview.qt-project.org. This will become an optional git submodule of qtbase (checkout: qtbase/licensing). The repository will contain the Licenses and binary files (licheck*) that are so far only in our commercial source packages. The goal is to allow proper commercial builds from git, see also https://bugreports.qt.io/browse/QTBUG-52222. As such, the repository should be readable by everyone, but write access should be limited to The Qt Company. I don’t understand how would that solve the issue. Wouldn’t this repo need to be cloned and then (somehow) merged with qtbase? If public read/download access if not a concern, wouldn’t it make more sense to just add licheck and the licenses to qtbase repo? Brett From thiago.macieira at intel.com Fri May 18 17:53:27 2018 From: thiago.macieira at intel.com (Thiago Macieira) Date: Fri, 18 May 2018 08:53:27 -0700 Subject: [Development] Repository Request: qt/licensing In-Reply-To: References: Message-ID: <42411610.Z7GdVQiepC@tjmaciei-mobl1> On Friday, 18 May 2018 07:36:37 PDT Kai Koehne wrote: > Hi, > > I'd like to request the creation of a repository "qt/licensing" on > codereview.qt-project.org. This will become an optional git submodule of > qtbase (checkout: qtbase/licensing). > > The repository will contain the Licenses and binary files (licheck*) that > are so far only in our commercial source packages. The goal is to allow > proper commercial builds from git, see also > https://bugreports.qt.io/browse/QTBUG-52222. > > As such, the repository should be readable by everyone, but write access > should be limited to The Qt Company. Is the source code for licheck going to be added to the repository? If not, then the binary cannot be added to the a Qt Project repository. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From Kai.Koehne at qt.io Fri May 18 21:53:00 2018 From: Kai.Koehne at qt.io (Kai Koehne) Date: Fri, 18 May 2018 19:53:00 +0000 Subject: [Development] Repository Request: qt/licensing In-Reply-To: <42411610.Z7GdVQiepC@tjmaciei-mobl1> References: , <42411610.Z7GdVQiepC@tjmaciei-mobl1> Message-ID: > From: Development on behalf of Thiago Macieira > > Is the source code for licheck going to be added to the repository? No, I'd only add the binaries. > If not, then the binary cannot be added to the a Qt Project repository. With "Qt Project repository" I guess you mean any git submodule of qt5.git, and further submodules? Or is this just the hosting on codereview.qt-project.org that you're concerned about? Just for clarification: The official source packages contain the licheck executables already. My aim is that a git checkout and the source packages we provide contain the very same content. Kai -------------- next part -------------- An HTML attachment was scrubbed... URL: From Kai.Koehne at qt.io Fri May 18 21:59:35 2018 From: Kai.Koehne at qt.io (Kai Koehne) Date: Fri, 18 May 2018 19:59:35 +0000 Subject: [Development] Repository Request: qt/licensing In-Reply-To: References: Message-ID: > As such, the repository should be readable by everyone, but write access should be limited to The Qt Company. > > I don’t understand how would that solve the issue. Wouldn’t this repo need to be cloned and then (somehow) merged with qtbase? Yes, it would be a git submodule of qtbase. > If public > read/download access if not a concern, wouldn’t it make more sense to just add licheck and the licenses to qtbase repo? That would indeed be the easiest. I proposed a separate submodule because a) binary checkins will blow up repository content over time, which we should avoid for central modules like qtbase. b) people that want to just use the opensource version or a tech preview version can just ignore the submodule. Alternatively, the submodule can also be a qt5.git submodule, instead of a qtbase one. The logic in qtbase could still locate a repository relative to qtbase. Kai ________________________________ From: Stottlemyer, Brett (B.S.) Sent: Friday, May 18, 2018 4:45:20 PM To: Kai Koehne; development at qt-project.org Subject: Re: [Development] Repository Request: qt/licensing On 5/18/18, 10:36 AM, "Development on behalf of Kai Koehne" wrote: Hi, I'd like to request the creation of a repository "qt/licensing" on codereview.qt-project.org. This will become an optional git submodule of qtbase (checkout: qtbase/licensing). The repository will contain the Licenses and binary files (licheck*) that are so far only in our commercial source packages. The goal is to allow proper commercial builds from git, see also https://bugreports.qt.io/browse/QTBUG-52222. As such, the repository should be readable by everyone, but write access should be limited to The Qt Company. I don’t understand how would that solve the issue. Wouldn’t this repo need to be cloned and then (somehow) merged with qtbase? If public read/download access if not a concern, wouldn’t it make more sense to just add licheck and the licenses to qtbase repo? Brett -------------- next part -------------- An HTML attachment was scrubbed... URL: From thiago.macieira at intel.com Fri May 18 23:18:02 2018 From: thiago.macieira at intel.com (Thiago Macieira) Date: Fri, 18 May 2018 14:18:02 -0700 Subject: [Development] Repository Request: qt/licensing In-Reply-To: References: <42411610.Z7GdVQiepC@tjmaciei-mobl1> Message-ID: <6975554.xnAPg4GeEC@tjmaciei-mobl1> On Friday, 18 May 2018 12:53:00 PDT Kai Koehne wrote: > > From: Development on > > behalf of Thiago Macieira > > > > > > Is the source code for licheck going to be added to the repository? > > No, I'd only add the binaries. > > > If not, then the binary cannot be added to the a Qt Project repository. > > With "Qt Project repository" I guess you mean any git submodule of qt5.git, > and further submodules? Or is this just the hosting on > codereview.qt-project.org that you're concerned about? I understand the lines are blurred between Qt Project and Qt Company with the qt.io domain. Let's unblur them: The Git repositories and this mailing list are Qt Project. Everything there is Open Source. Please don't add a binary tool that isn't Open Source, even if it is freely redistributable. > Just for clarification: The official source packages contain the licheck > executables already. My aim is that a git checkout and the source packages > we provide contain the very same content. I understand, but I'm asking you not to. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From massimocallegari at yahoo.it Sat May 19 13:46:21 2018 From: massimocallegari at yahoo.it (Massimo Callegari) Date: Sat, 19 May 2018 11:46:21 +0000 (UTC) Subject: [Development] Wrong OpenGL version detection on Mac References: <1280537962.5274461.1526730381874.ref@mail.yahoo.com> Message-ID: <1280537962.5274461.1526730381874@mail.yahoo.com> Hi devs, I'm referring to https://bugreports.qt.io/browse/QTBUG-68130 Unfortunately it affects shaders in Qt3D, so it would be nice if this can be fixed on 5.11.0, if it's not too late. Forcing the GL version with QSurfaceFormat doesn't help. I haven't tested on 5.9.x, but I'm a bit surprised nobody spotted this before. Cheers, Massimo From tony.sarajarvi at qt.io Tue May 22 08:42:07 2018 From: tony.sarajarvi at qt.io (=?iso-8859-1?Q?Tony_Saraj=E4rvi?=) Date: Tue, 22 May 2018 06:42:07 +0000 Subject: [Development] Performing infra upgrade in the CI Message-ID: Hi I'm performing a small infra upgrade. I'll be upgrading MAAS to the latest version. This shouldn't cause any CI downtime. If something goes badly wrong, I'll just revert my change and let's get back to business as usual. Fingers crossed, -Tony -------------- next part -------------- An HTML attachment was scrubbed... URL: From lars.knoll at qt.io Tue May 22 09:30:18 2018 From: lars.knoll at qt.io (Lars Knoll) Date: Tue, 22 May 2018 07:30:18 +0000 Subject: [Development] Naming convention for (scoped) enums In-Reply-To: <20180517103538.221f0e85@ckandeler-archlinux> References: <20180517103538.221f0e85@ckandeler-archlinux> Message-ID: <2579F568-844E-46E0-8C1D-1DD1DD84C1DE@qt.io> > On 17 May 2018, at 11:35, Christian Kandeler wrote: > > On Thu, 17 May 2018 08:14:15 +0000 > Alex Blasche wrote: > >> The naming conventions for enums state that each enum value name must repeat a part of the enum Type name (for details see https://wiki.qt.io/API_Design_Principles#Naming_Enum_Types_and_Values) >> >> In case of scoped enums this becomes a superfluous rule as the type has to be mentioned anyway. Does anybody object to modifying the above definition by adding an exception for scoped enums where you do not have to repeat a part of the enum type name? > > I would not have even assumed that the rule applies to scoped enums, but it can't hurt to write it down explicitly. Perhaps the section should be rewritten so that the unscoped enums are the special case rather than the other way around. Agree. The default for new enums should be scoped enums. Cheers, Lars From alexander.blasche at qt.io Tue May 22 10:04:50 2018 From: alexander.blasche at qt.io (Alex Blasche) Date: Tue, 22 May 2018 08:04:50 +0000 Subject: [Development] Naming convention for (scoped) enums In-Reply-To: <2579F568-844E-46E0-8C1D-1DD1DD84C1DE@qt.io> References: <20180517103538.221f0e85@ckandeler-archlinux>, <2579F568-844E-46E0-8C1D-1DD1DD84C1DE@qt.io> Message-ID: I updated the enum section: https://wiki.qt.io/API_Design_Principles#Naming_Enum_Types_and_Values -- Alex ________________________________________ From: Development on behalf of Lars Knoll Sent: Tuesday, 22 May 2018 9:30:18 AM To: Christian Kandeler Cc: Qt development mailing list Subject: Re: [Development] Naming convention for (scoped) enums > On 17 May 2018, at 11:35, Christian Kandeler wrote: > > On Thu, 17 May 2018 08:14:15 +0000 > Alex Blasche wrote: > >> The naming conventions for enums state that each enum value name must repeat a part of the enum Type name (for details see https://wiki.qt.io/API_Design_Principles#Naming_Enum_Types_and_Values) >> >> In case of scoped enums this becomes a superfluous rule as the type has to be mentioned anyway. Does anybody object to modifying the above definition by adding an exception for scoped enums where you do not have to repeat a part of the enum type name? > > I would not have even assumed that the rule applies to scoped enums, but it can't hurt to write it down explicitly. Perhaps the section should be rewritten so that the unscoped enums are the special case rather than the other way around. Agree. The default for new enums should be scoped enums. Cheers, Lars _______________________________________________ Development mailing list Development at qt-project.org http://lists.qt-project.org/mailman/listinfo/development From jani.heikkinen at qt.io Tue May 22 12:09:30 2018 From: jani.heikkinen at qt.io (Jani Heikkinen) Date: Tue, 22 May 2018 10:09:30 +0000 Subject: [Development] Qt 5.11.0 released In-Reply-To: References: Message-ID: Hi everyone! I am happy to announce that Qt 5.11.0 is released today, see http://blog.qt.io/blog/2018/05/22/qt-5-11-released/ At this time we were ready slightly before originally estimated; big thanks to everyone involved! br, Jani Heikkinen Release Manager The Qt Company From jani.heikkinen at qt.io Tue May 22 15:29:43 2018 From: jani.heikkinen at qt.io (Jani Heikkinen) Date: Tue, 22 May 2018 13:29:43 +0000 Subject: [Development] HEADS UP: Branching from '5.9' to '5.9.6' completed Message-ID: Hi, Branching from '5.9' -> '5.9.6' now done and '5.9' is for Qt 5.9.7. So all changes targeted to Qt 5.9.6 must be done in '5.9.6' from now on. Target is to create Qt 5.9.6 "rc" soon, test it and if all OK release Qt 5.9.6 at the beginning of June. So please make sure all release blockers are visible in 5.9.6 blocker list (https://bugreports.qt.io/issues/?filter=19339) br, Jani > -----Original Message----- > From: Development project.org> On Behalf Of Jani Heikkinen > Sent: keskiviikko 9. toukokuuta 2018 14.01 > To: development at qt-project.org > Cc: releasing at qt-project.org > Subject: [Development] HEADS UP: Branching from '5.9' to '5.9.6' started > > Hi, > > We have soft branched '5.9.6' from '5.9' already today. This was done a bit > earlier than informed but don't worry; final downmerge from '5.9' to '5.9.6' > will happen Tue 22.5.2018 as planned. So there is now plenty of time to > finalize ongoing changes in '5.9' and start using '5.9.6' for new changes > targeted to Qt 5.9.6 release. Plan is to get Qt 5.9.6 out at the beginning of > June > > br, > Jani > > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development From philippeb8 at gmail.com Tue May 22 17:12:43 2018 From: philippeb8 at gmail.com (Phil Bouchard) Date: Tue, 22 May 2018 15:12:43 +0000 (UTC) Subject: [Development] WebAssembly Message-ID: Way to go Qt! http://blog.qt.io/blog/2018/05/22/qt-for-webassembly/ I suggested this in a previous thread but apparently you already had grips on it. Well good job folks! Sincerely, -Phil www.fornux.com From oswald.buddenhagen at qt.io Tue May 22 19:56:17 2018 From: oswald.buddenhagen at qt.io (Oswald Buddenhagen) Date: Tue, 22 May 2018 19:56:17 +0200 Subject: [Development] Stepping down as maintainer In-Reply-To: References: <3B7614FE-934A-41F3-8892-24D0769D0832@crimson.no> Message-ID: <20180522175617.GA6936@troll08> On Mon, Apr 09, 2018 at 06:37:23AM +0000, Alexander Blasche wrote: > All required Jira and https://wiki.qt.io/Maintainers updates have been done. > well, actually, the top-level "gui" item is still naming gunnar. and in jira we have no "gui: other" component at all ... > -- > Alex > > ________________________________________ > From: Development on behalf of Gunnar Sletta > Sent: Monday, 19 March 2018 1:39:50 PM > To: development > Subject: [Development] Stepping down as maintainer > > Hi, > > After quite some time of not being active in Qt, I am now formally stepping down as maintainer. It has been a great ride, but I simply don't have time to follow up Gui and Scene Graph and it makes sense that the people who are active in these areas also become the go-to guys. > > I've already spoken with Eskil and Lars, and propose the following list of people to formally take over my areas: > > Tor Arne Vestby - QPA and window system integration > Laszlo Agocs - OpenGL/Vulkan > Eirik Aavitsland - Image Formats and QPainter > Andy Nichols - Scene Graph > > (Other specific maintainers in QtGui stay unchanged) > > Thanks, > Gunnar > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development From thiago.macieira at intel.com Tue May 22 22:21:25 2018 From: thiago.macieira at intel.com (Thiago Macieira) Date: Tue, 22 May 2018 17:21:25 -0300 Subject: [Development] Repository Request: qt/licensing In-Reply-To: <6975554.xnAPg4GeEC@tjmaciei-mobl1> References: <6975554.xnAPg4GeEC@tjmaciei-mobl1> Message-ID: <4508906.VNGlaHcGFL@tjmaciei-mobl1> On Friday, 18 May 2018 18:18:02 -03 Thiago Macieira wrote: > > Just for clarification: The official source packages contain the licheck > > executables already. My aim is that a git checkout and the source packages > > we provide contain the very same content. > > I understand, but I'm asking you not to. Here's something that would be acceptable: Do create the qt/licensing repo but make it empty, or just a README file or whatever is necessary. This repository can live in qt-project.org and be mirrored under github.com/qtproject. In your internal infra, use a different repository branched off from the public one, containing the licence checker binary and anything else you may need. This repository should never be shared. It's no different than my own qtbase, except that I do share it: https://gitlab.com/thiagomacieira/qtbase -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From thiago.macieira at intel.com Wed May 23 02:16:22 2018 From: thiago.macieira at intel.com (Thiago Macieira) Date: Tue, 22 May 2018 21:16:22 -0300 Subject: [Development] Do we really need Assimp? Message-ID: <1557864.ivJVhQeBFm@tjmaciei-mobl1> Given the number of warnings in this codebase, I am really skeptical about the quality of the code. Today, compiling with GCC, Clang an ICC, I saw the following warnings scroll by, which are real issues: LWSLoader.cpp:428:14: warning: duplicated ‘if’ condition [-Wduplicated-cond] new_allocator.h:140:22: warning: destructor called on non-final 'Assimp::FICDATAValueImpl' that has virtual functions but non-virtual destructor [-Wdelete-non-virtual-dtor] miniz.h(4430): warning #592: variable "level" is used before its value is set And then there are of course warnings that indicate none of their developers are testing new compilers, like LWOLoader.cpp:1408:13: warning: this statement may fall through [-Wimplicit- fallthrough=] Can we get rid of it? If not, can I ask someone to compile it with CONFIG += warn_off, to hide all that ugliness? Those warnings make finding our warnings more difficult and it affects our reputation because people see warnings and think they're Qt's fault. Qt3D maintainers, please take action to make sure those warnings disappear from our builds. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From daetalusun at gmail.com Wed May 23 11:04:11 2018 From: daetalusun at gmail.com (Boxiang Sun) Date: Wed, 23 May 2018 11:04:11 +0200 Subject: [Development] Could someone help me to change my full name in bugreports.qt.io? Message-ID: Hi, I am contributing to PySide2. And I set up my account in https://account.qt.io correctly, which is "Boxiang Sun". But my full name in https://bugreports.qt.io is not, which is "Alexander Sun". I used the latter one before. But not for Qt. How can I change my full name in bugreports? Or is there someone(website manager, maybe?) who can help me to change my name, please? Thanks! Regards, Boxiang Sun -------------- next part -------------- An HTML attachment was scrubbed... URL: From Kai.Koehne at qt.io Wed May 23 15:23:46 2018 From: Kai.Koehne at qt.io (Kai Koehne) Date: Wed, 23 May 2018 13:23:46 +0000 Subject: [Development] Changing maintainership for Qt Creator modules Message-ID: Hi, I haven't actively worked on Qt Creator since a while, and would therefore like to step down as the maintainer for the Qt Creator modules I'm still listed for in https://wiki.qt.io/Maintainers: Debugging & Profiling / QML I propose Ulf Hermann as replacement. Project Management & Targets / QML I propose Thomas Hartmann as replacement. Regards Kai -- Kai Koehne, Senior Manager R&D | The Qt Company The Qt Company GmbH, Rudower Chaussee 13, D-12489 Berlin Geschäftsführer: Mika Pälsi, Juha Varelius, Mika Harjuaho. Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 144331 B From Kai.Koehne at qt.io Wed May 23 15:31:17 2018 From: Kai.Koehne at qt.io (Kai Koehne) Date: Wed, 23 May 2018 13:31:17 +0000 Subject: [Development] Repository Request: qt/licensing In-Reply-To: <4508906.VNGlaHcGFL@tjmaciei-mobl1> References: <6975554.xnAPg4GeEC@tjmaciei-mobl1> <4508906.VNGlaHcGFL@tjmaciei-mobl1> Message-ID: > -----Original Message----- > From: Development [mailto:development-bounces+kai.koehne=qt.io at qt- > project.org] On Behalf Of Thiago Macieira > Sent: Tuesday, May 22, 2018 10:21 PM > To: development at qt-project.org > Subject: Re: [Development] Repository Request: qt/licensing > > On Friday, 18 May 2018 18:18:02 -03 Thiago Macieira wrote: > > > Just for clarification: The official source packages contain the > > > licheck executables already. My aim is that a git checkout and the > > > source packages we provide contain the very same content. > > > > I understand, but I'm asking you not to. > > Here's something that would be acceptable: > > Do create the qt/licensing repo but make it empty, or just a README file or > whatever is necessary. This repository can live in qt-project.org and be mirrored > under github.com/qtproject. > > In your internal infra, use a different repository branched off from the public > one, containing the licence checker binary and anything else you may need. > This repository should never be shared. Well, the whole point of the exercise is to allow customers to configure Qt under commercial terms from git, so any non-shared git module doesn't help. We can also ship licheck binaries independently of the git modules, and ask then customers to pass their location e.g. via a configure argument: configure -commercial -licheck /path/to/licheck ... then all we have to add to qtbase is the .release-timestamp file to mark the date of a release. This means we'll give up the goal of making the qt source package sbe just archives of the git archives though. Regards Kai From Eike.Ziller at qt.io Wed May 23 15:31:29 2018 From: Eike.Ziller at qt.io (Eike Ziller) Date: Wed, 23 May 2018 13:31:29 +0000 Subject: [Development] Changing maintainership for Qt Creator modules In-Reply-To: References: Message-ID: +1. Both are the de-facto maintainers of that code nowadays :) > On 23. May 2018, at 15:23, Kai Koehne wrote: > > Hi, > > I haven't actively worked on Qt Creator since a while, and would therefore like to step down as the maintainer for the Qt Creator modules I'm still listed for in https://wiki.qt.io/Maintainers: > > > Debugging & Profiling / QML > > I propose Ulf Hermann as replacement. > > > Project Management & Targets / QML > > I propose Thomas Hartmann as replacement. > > > Regards > > Kai > > -- > Kai Koehne, Senior Manager R&D | The Qt Company > > The Qt Company GmbH, Rudower Chaussee 13, D-12489 Berlin > Geschäftsführer: Mika Pälsi, Juha Varelius, Mika Harjuaho. Sitz der > Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, > HRB 144331 B > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development -- Eike Ziller Principal Software Engineer The Qt Company GmbH Rudower Chaussee 13 D-12489 Berlin eike.ziller at 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 From simon.hausmann at qt.io Wed May 23 15:35:44 2018 From: simon.hausmann at qt.io (Simon Hausmann) Date: Wed, 23 May 2018 15:35:44 +0200 Subject: [Development] Repository Request: qt/licensing In-Reply-To: References: <4508906.VNGlaHcGFL@tjmaciei-mobl1> Message-ID: <2311982.YOgjgDl3zd@ubuntu> On Mittwoch, 23. Mai 2018 15:31:17 CEST Kai Koehne wrote: > > -----Original Message----- > > From: Development [mailto:development-bounces+kai.koehne=qt.io at qt- > > project.org] On Behalf Of Thiago Macieira > > Sent: Tuesday, May 22, 2018 10:21 PM > > To: development at qt-project.org > > Subject: Re: [Development] Repository Request: qt/licensing > > > > On Friday, 18 May 2018 18:18:02 -03 Thiago Macieira wrote: > > > > Just for clarification: The official source packages contain the > > > > licheck executables already. My aim is that a git checkout and the > > > > source packages we provide contain the very same content. > > > > > > I understand, but I'm asking you not to. > > > > Here's something that would be acceptable: > > > > Do create the qt/licensing repo but make it empty, or just a README file > > or > > whatever is necessary. This repository can live in qt-project.org and be > > mirrored under github.com/qtproject. > > > > In your internal infra, use a different repository branched off from the > > public one, containing the licence checker binary and anything else you > > may need. This repository should never be shared. > > Well, the whole point of the exercise is to allow customers to configure Qt > under commercial terms from git, so any non-shared git module doesn't help. > > We can also ship licheck binaries independently of the git modules, and ask > then customers to pass their location e.g. via a configure argument: > > configure -commercial -licheck /path/to/licheck ... Would it perhaps be possible for configure to just look in "well known" locations in the system where the online installer can place them (or place a file that contains the path to licheck) ? > then all we have to add to qtbase is the .release-timestamp file to mark the > date of a release. Can you determine the time of the release from the release tag perhaps? git describe can be used to find the "nearest" tag and the tag has a date. Simon From thiago.macieira at intel.com Wed May 23 15:42:49 2018 From: thiago.macieira at intel.com (Thiago Macieira) Date: Wed, 23 May 2018 10:42:49 -0300 Subject: [Development] Repository Request: qt/licensing In-Reply-To: References: <4508906.VNGlaHcGFL@tjmaciei-mobl1> Message-ID: <5536979.OkiGCGMjE9@tjmaciei-mobl1> On Wednesday, 23 May 2018 10:31:17 -03 Kai Koehne wrote: > > In your internal infra, use a different repository branched off from the > > public one, containing the licence checker binary and anything else you > > may need. This repository should never be shared. > > Well, the whole point of the exercise is to allow customers to configure Qt > under commercial terms from git, so any non-shared git module doesn't help. You can then make it public, so long as it's clear it's Qt Company, not Qt Project. I object to it showing up anywhere in github.com/qt and qt- project.org, but other places in qt.io could be acceptable. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From bstottle at ford.com Wed May 23 19:49:06 2018 From: bstottle at ford.com (Stottlemyer, Brett (B.S.)) Date: Wed, 23 May 2018 17:49:06 +0000 Subject: [Development] Repository Request: qt/licensing In-Reply-To: <5536979.OkiGCGMjE9@tjmaciei-mobl1> References: <4508906.VNGlaHcGFL@tjmaciei-mobl1> <5536979.OkiGCGMjE9@tjmaciei-mobl1> Message-ID: On Wednesday, May 23, 2018 9:43 AM Thiago Macieira wrote: > On Wednesday, 23 May 2018 10:31:17 -03 Kai Koehne wrote: > > Well, the whole point of the exercise is to allow customers to > > configure Qt under commercial terms from git, so any non-shared git module doesn't help. > > You can then make it public, so long as it's clear it's Qt Company, not Qt Project. I object to it showing up anywhere in github.com/qt and > qt- project.org, but other places in qt.io could be acceptable. Can .pro files test for commercial vs. oss licenses? If so, and you create a non-Qt project repo, couldn't some .pro in qtbase retrieve licheck, like QtCreator does here: http://code.qt.io/cgit/qt-creator/qt-creator.git/tree/qtcreator.pro#n123? Is that an acceptable solution? Seems like it would work here, although I think the time stamp generation and commercial licenses would need to be added to qtbase (I think). Regards, Brett From tero.kojo at qt.io Thu May 24 08:54:52 2018 From: tero.kojo at qt.io (Tero Kojo) Date: Thu, 24 May 2018 06:54:52 +0000 Subject: [Development] Qt Contributors' Summit registration and session reservation Message-ID: Hello, Qt Contributors' Summit 2018 is closing in fast. The time is June 11-12th. And the location is Oslo, The BI centre at Sandakerveien 116, 0484 Oslo. The event is aimed for everyone who is interested in the future of Qt, or has contributed in some way to Qt in the past year. (contribution is not limited to code, it can be any positive activity in the community.) There is no entrance fee, but for food purposes, you need to register. So if you are coming, please fill in this form: https://www.surveymonkey.com/r/3P55B5C The program can be found here: https://wiki.qt.io/Qt_contributors_summit_2018_Program As always if you have a session you want to hold, please add it to the program and prepare to present the basics about the topic. Best, Tero Tero Kojo Community Manager The Qt Company Bertel Jungin Aukio D3A 02600, Espoo, Finland tero.kojo at qt.io http://qt.io [The Qt Company logo] [Facebook] [Twitter] [LinkedIn] [Google+] [YouTube] -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image013.png Type: image/png Size: 8189 bytes Desc: image013.png URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image014.png Type: image/png Size: 869 bytes Desc: image014.png URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image015.png Type: image/png Size: 986 bytes Desc: image015.png URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image016.png Type: image/png Size: 907 bytes Desc: image016.png URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image017.png Type: image/png Size: 1039 bytes Desc: image017.png URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image018.png Type: image/png Size: 903 bytes Desc: image018.png URL: From jani.heikkinen at qt.io Thu May 24 09:27:38 2018 From: jani.heikkinen at qt.io (Jani Heikkinen) Date: Thu, 24 May 2018 07:27:38 +0000 Subject: [Development] Cleaning old development releases from download.qt.io Message-ID: Hi! Disk usage in download.qt.io is quite huge (~1.5 TB) at the moment and it is causing problems for mirrors and mirroring. We are cleaning up unnecessary stuff from there and one thing to remove is old qt pre-releases (snapshots, alpha, beta and rc releases) from http://download.qt.io/development_releases/qt/ . I have already hide those old ones but before deleting those permanently I want to get confirmation if that is really OK; those pre-releases aren't available in http://download.qt.io/archive/qt. But official releases are there of course and that's why I think it should be OK to remove those pre-releases. br, Jani Heikkinen Release Manager From kushnirtv at gmail.com Thu May 24 09:40:11 2018 From: kushnirtv at gmail.com (Taras Kushnir) Date: Thu, 24 May 2018 10:40:11 +0300 Subject: [Development] Qt public release build configuration Message-ID: Hello I'm going to build Qt from source for the first time in order to fix some issues in Quick Controls. I will need to rebuild Qt on Windows x86_64, OS X and Linux. Where can I find exact `configure` options used to create public releases 5.6.3 and 5.9.5 as well as exact versions of dependencies used to create the release (ICU etc.) and environments (OS version, frameworks, Windows Kit etc.)? Thank you, Taras Kushnir. -------------- next part -------------- An HTML attachment was scrubbed... URL: From Tobias.Hunger at qt.io Thu May 24 10:23:26 2018 From: Tobias.Hunger at qt.io (Tobias Hunger) Date: Thu, 24 May 2018 08:23:26 +0000 Subject: [Development] Orgad is now maintainer of Version Control plugins in Qt Creator Message-ID: Hello, I am pleased to announce that Orgad Shaneh is now maintainer of the plugins related to version control systems in Qt Creator. He has done most work in this area for a long time nowe and I am sure he will continue to do a great job in his new role as well. The maintainers page has been updated accordingly and the default assignee in JIRA has been changed. Best Regards, Tobias -- Tobias Hunger, Senior Software Engineer | The Qt Company The Qt Company GmbH, Rudower Chaussee 13, D-12489 Berlin Geschäftsführer: Mika Pälsi, Juha Varelius, Mika Harjuaho. Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 144331 B From orgads at gmail.com Thu May 24 10:28:24 2018 From: orgads at gmail.com (Orgad Shaneh) Date: Thu, 24 May 2018 11:28:24 +0300 Subject: [Development] [Qt-creator] Orgad is now maintainer of Version Control plugins in Qt Creator In-Reply-To: References: Message-ID: On Thu, May 24, 2018 at 11:23 AM Tobias Hunger wrote: > Hello, > > I am pleased to announce that Orgad Shaneh is now maintainer of the > plugins related to version control systems in Qt Creator. He has done most > work in this area for a long time nowe and I am sure he will continue to do > a great job in his new role as well. > > The maintainers page has been updated accordingly and the default assignee > in JIRA has been changed. > Thank you all for your trust. I'll do my best to improve VCS integration :) - Orgad -------------- next part -------------- An HTML attachment was scrubbed... URL: From a.rehn at menlosystems.com Thu May 24 10:46:46 2018 From: a.rehn at menlosystems.com (Arno Rehn) Date: Thu, 24 May 2018 10:46:46 +0200 Subject: [Development] QtWebChannel: Upstreaming of Python client In-Reply-To: <1572911.646YAUrLd6@agathebauer> References: <200afb57-55a0-14f7-c27e-bf9852cca9e4@menlosystems.com> <1572911.646YAUrLd6@agathebauer> Message-ID: Hey everbody, Am 15.02.2017 um 20:07 schrieb Milian Wolff: > On Mittwoch, 15. Februar 2017 11:15:13 CET Jonathan Liu wrote: >>>> I agree, this sounds pretty useful, especially given that we’re also >>>> working again on pyside since this spring. >>>> >>>> ...especially an implementation in Python and C++ both from the Qt >>>> Project could be a really nice combo - sign me up! >>> >>> Thanks for all the feedback! Nice to know that people are interested :) >>> I'll polish the code a little and create a review request. >> >> Did this ever get followed up? > > No, I never saw any request for review on gerrit. Sorry for the very long delay; other things got in the way. For now, we've published the python module on GitHub: https://github.com/MenloSystems/pywebchannel I'd really like to see this pushed upstream, but I can't tell when I get around to creating a review request. Regards, Arno -- Arno Rehn Tel +49 89 189 166 0 Fax +49 89 189 166 111 a.rehn at 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 From jani.heikkinen at qt.io Thu May 24 11:43:58 2018 From: jani.heikkinen at qt.io (Jani Heikkinen) Date: Thu, 24 May 2018 09:43:58 +0000 Subject: [Development] Qt public release build configuration In-Reply-To: References: Message-ID: Hi. Unfortunately it isn't that easy to figure out but the data is available; you just need to know from where to search it :D Configure options can be found from (qtbase) build log, from qt5.git integration. E.g for 5.6.3 here:https://testresults.qt.io/coin/integration/qt/qt5/tasks/1505476672 and for 5.9.5 here: https://testresults.qt.io/coin/integration/qt/qt5/tasks/1523412986 And SW details here: https://wiki.qt.io/Qt_5.6_Tools_and_Versions & https://wiki.qt.io/Qt_5.9_Tools_and_Versions br, Jani ________________________________________ From: Development on behalf of Taras Kushnir Sent: Thursday, May 24, 2018 10:40 AM To: development at qt-project.org Subject: [Development] Qt public release build configuration Hello I'm going to build Qt from source for the first time in order to fix some issues in Quick Controls. I will need to rebuild Qt on Windows x86_64, OS X and Linux. Where can I find exact `configure` options used to create public releases 5.6.3 and 5.9.5 as well as exact versions of dependencies used to create the release (ICU etc.) and environments (OS version, frameworks, Windows Kit etc.)? Thank you, Taras Kushnir. From a.rehn at menlosystems.com Thu May 24 13:10:12 2018 From: a.rehn at menlosystems.com (Arno Rehn) Date: Thu, 24 May 2018 13:10:12 +0200 Subject: [Development] QWebChannel .NET client available Message-ID: Hi, in addition to the Python WebChannel client, we've also created one for .NET: https://github.com/MenloSystems/webchannel.net It supports .NET 3.5 and .NET 4. With dynamic objects (i.e. late binding) support in the latter, working with QWebChannel in C# is actually quite pleasant. A C++11 client is also in the making and should be released soon. Regards, Arno -- Arno Rehn Tel +49 89 189 166 0 Fax +49 89 189 166 111 a.rehn at 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 From kushnirtv at gmail.com Thu May 24 13:19:26 2018 From: kushnirtv at gmail.com (Taras Kushnir) Date: Thu, 24 May 2018 14:19:26 +0300 Subject: [Development] Qt public release build configuration In-Reply-To: References: Message-ID: Hello Thanks for the fast reply. Link for Qt 5.9.5 works while 5.6.3 does not. I checked qt/qt5 and Windows 10 (msvc2015-x86_64). Error for "log" says "Error occurred while reading log:[object Object]" and raw log doesn't open as well. Maybe these logs are too old to open? Otherwise - thanks a lot! Taras 2018-05-24 12:43 GMT+03:00 Jani Heikkinen : > Hi. > > Unfortunately it isn't that easy to figure out but the data is available; > you just need to know from where to search it :D > > Configure options can be found from (qtbase) build log, from qt5.git > integration. E.g for 5.6.3 here:https://testresults.qt. > io/coin/integration/qt/qt5/tasks/1505476672 > and for 5.9.5 here: https://testresults.qt.io/ > coin/integration/qt/qt5/tasks/1523412986 > > And SW details here: https://wiki.qt.io/Qt_5.6_Tools_and_Versions & > https://wiki.qt.io/Qt_5.9_Tools_and_Versions > > br, > Jani > > ________________________________________ > From: Development > on behalf of Taras Kushnir > Sent: Thursday, May 24, 2018 10:40 AM > To: development at qt-project.org > Subject: [Development] Qt public release build configuration > > Hello > > I'm going to build Qt from source for the first time in order to fix some > issues in Quick Controls. I will need to rebuild Qt on Windows x86_64, OS X > and Linux. Where can I find exact `configure` options used to create public > releases 5.6.3 and 5.9.5 as well as exact versions of dependencies used to > create the release (ICU etc.) and environments (OS version, frameworks, > Windows Kit etc.)? > > Thank you, > Taras Kushnir. > -- Best regards, Taras Kushnir. -------------- next part -------------- An HTML attachment was scrubbed... URL: From milian.wolff at kdab.com Thu May 24 13:55:07 2018 From: milian.wolff at kdab.com (Milian Wolff) Date: Thu, 24 May 2018 13:55:07 +0200 Subject: [Development] QWebChannel .NET client available In-Reply-To: References: Message-ID: <2374016.O391DF6qoi@milian-kdab2> On Thursday, May 24, 2018 1:10:12 PM CEST Arno Rehn wrote: > Hi, > > in addition to the Python WebChannel client, we've also created one for > .NET: > > https://github.com/MenloSystems/webchannel.net > > It supports .NET 3.5 and .NET 4. With dynamic objects (i.e. late > binding) support in the latter, working with QWebChannel in C# is > actually quite pleasant. > > A C++11 client is also in the making and should be released soon. Cool stuff, that's pretty nice to see! If you ever feel like it, please do contribute this code for inclusion upstream into the webchannel module. Though only under the premise that you'll also maintain these parts then. I'm neither an expert in Python nor .NET, so I wouldn't be able to maintain that code. Cheers -- Milian Wolff | milian.wolff at kdab.com | Senior Software Engineer KDAB (Deutschland) GmbH, a KDAB Group company Tel: +49-30-521325470 KDAB - The Qt, C++ and OpenGL Experts -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3826 bytes Desc: not available URL: From a.rehn at menlosystems.com Thu May 24 14:16:12 2018 From: a.rehn at menlosystems.com (Arno Rehn) Date: Thu, 24 May 2018 14:16:12 +0200 Subject: [Development] QWebChannel .NET client available In-Reply-To: <2374016.O391DF6qoi@milian-kdab2> References: <2374016.O391DF6qoi@milian-kdab2> Message-ID: Am 24.05.2018 um 13:55 schrieb Milian Wolff: > On Thursday, May 24, 2018 1:10:12 PM CEST Arno Rehn wrote: >> in addition to the Python WebChannel client, we've also created one for >> .NET: >> >> https://github.com/MenloSystems/webchannel.net >> >> It supports .NET 3.5 and .NET 4. With dynamic objects (i.e. late >> binding) support in the latter, working with QWebChannel in C# is >> actually quite pleasant. >> >> A C++11 client is also in the making and should be released soon. > > Cool stuff, that's pretty nice to see! Thanks! > If you ever feel like it, please do contribute this code for inclusion > upstream into the webchannel module. Though only under the premise that you'll > also maintain these parts then. I'm neither an expert in Python nor .NET, so I > wouldn't be able to maintain that code. I'd really like that. Maintaining the code should be rather easy since it's nearly a one-to-one translation of qwebchannel.js. In any case, we're already reyling on QWebChannel and thus will continue to maintain these modules. However, I guess upstreaming the .NET part could be difficult from a build system point of view: we'd need to integrate the C# toolchain into qmake. The python module has a similar problem: Do we install the module into python's site-packages directory? Or do we simply ship the files and leave it up to the user to integrate it with python's package management? Regards, Arno -- Arno Rehn Tel +49 89 189 166 0 Fax +49 89 189 166 111 a.rehn at 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 From thiago.macieira at intel.com Thu May 24 14:21:24 2018 From: thiago.macieira at intel.com (Thiago Macieira) Date: Thu, 24 May 2018 09:21:24 -0300 Subject: [Development] Repository Request: qt/licensing In-Reply-To: References: <5536979.OkiGCGMjE9@tjmaciei-mobl1> Message-ID: <1576844.h3dPvRdNMj@tjmaciei-mobl1> On Wednesday, 23 May 2018 14:49:06 -03 Stottlemyer, Brett (B.S.) wrote: > Can .pro files test for commercial vs. oss licenses? If so, and you create > a non-Qt project repo, couldn't some .pro in qtbase retrieve licheck, like > QtCreator does here: > http://code.qt.io/cgit/qt-creator/qt-creator.git/tree/qtcreator.pro#n123? configure no longer saves anything, whether you pass -opensource or - commercial. The options are currently dummy. But they could be changed back to saving something. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From Kai.Koehne at qt.io Thu May 24 14:46:39 2018 From: Kai.Koehne at qt.io (Kai Koehne) Date: Thu, 24 May 2018 12:46:39 +0000 Subject: [Development] Repository Request: qt/licensing In-Reply-To: <2311982.YOgjgDl3zd@ubuntu> References: <4508906.VNGlaHcGFL@tjmaciei-mobl1> <2311982.YOgjgDl3zd@ubuntu> Message-ID: > -----Original Message----- > [ ..] > Would it perhaps be possible for configure to just look in "well known" > locations in the system where the online installer can place them (or place a file > that contains the path to licheck) ? That's a good idea, though the online installer has always been optional. But yeah, we can make this easier for this setup then. > > then all we have to add to qtbase is the .release-timestamp file to > > mark the date of a release. > > Can you determine the time of the release from the release tag perhaps? git > describe can be used to find the "nearest" tag and the tag has a date. Maybe, I'll need to study this a bit more. For now, adding the .release-timestamp just looked the most straighforward solution to me. Kai From Kai.Koehne at qt.io Thu May 24 14:58:43 2018 From: Kai.Koehne at qt.io (Kai Koehne) Date: Thu, 24 May 2018 12:58:43 +0000 Subject: [Development] Repository Request: qt/licensing In-Reply-To: References: <4508906.VNGlaHcGFL@tjmaciei-mobl1> <5536979.OkiGCGMjE9@tjmaciei-mobl1> Message-ID: > -----Original Message----- > [...] > Can .pro files test for commercial vs. oss licenses? If so, and you create a non- > Qt project repo, couldn't some .pro in qtbase retrieve licheck, like QtCreator > does here: http://code.qt.io/cgit/qt-creator/qt- > creator.git/tree/qtcreator.pro#n123? > > Is that an acceptable solution? Seems like it would work here, although I think > the time stamp generation and commercial licenses would need to be added to > qtbase (I think). Thanks, that's actually an interesting idea. Obvious downside is that you need network access ... but you can argue that, if people are using git, they most likely have it 😊 Alright, seems I need to get back to the drawing board and experiment a bit. The suggestions for getting the licheck executables distributes so far are - host the licheck executables outside of a qt-project.org repository, and let users clone it from there - let them be downloaded by the online installer - fetch them via qmake I'll look into each one of them. Meanwhile, consider the request for the repository withdrawn for now. Thanks Kai From thiago.macieira at intel.com Thu May 24 17:19:20 2018 From: thiago.macieira at intel.com (Thiago Macieira) Date: Thu, 24 May 2018 12:19:20 -0300 Subject: [Development] Repository Request: qt/licensing In-Reply-To: References: Message-ID: <7346258.devTqGVgxI@tjmaciei-mobl1> On Thursday, 24 May 2018 09:58:43 -03 Kai Koehne wrote: > Thanks, that's actually an interesting idea. Obvious downside is that you > need network access ... but you can argue that, if people are using git, > they most likely have it Uh... not really. I use git while on the plane :-) -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From thiago.macieira at intel.com Thu May 24 14:22:42 2018 From: thiago.macieira at intel.com (Thiago Macieira) Date: Thu, 24 May 2018 09:22:42 -0300 Subject: [Development] Cleaning old development releases from download.qt.io In-Reply-To: References: Message-ID: <1792318.MKPqlpxJoP@tjmaciei-mobl1> On Thursday, 24 May 2018 04:27:38 -03 Jani Heikkinen wrote: > Hi! > > Disk usage in download.qt.io is quite huge (~1.5 TB) at the moment and it is > causing problems for mirrors and mirroring. We are cleaning up unnecessary > stuff from there and one thing to remove is old qt pre-releases (snapshots, > alpha, beta and rc releases) from > http://download.qt.io/development_releases/qt/ . I have already hide those > old ones but before deleting those permanently I want to get confirmation > if that is really OK; those pre-releases aren't available in > http://download.qt.io/archive/qt. But official releases are there of course > and that's why I think it should be OK to remove those pre-releases. Snapshots yes. For the others, remove binaries but please keep the sources. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From apoenitz at t-online.de Thu May 24 06:48:28 2018 From: apoenitz at t-online.de (=?iso-8859-1?Q?Andr=E9_P=F6nitz?=) Date: Thu, 24 May 2018 06:48:28 +0200 Subject: [Development] Repository Request: qt/licensing In-Reply-To: References: <4508906.VNGlaHcGFL@tjmaciei-mobl1> <5536979.OkiGCGMjE9@tjmaciei-mobl1> Message-ID: <20180524044828.GA28115@klara.mpi.htwm.de> On Thu, May 24, 2018 at 12:58:43PM +0000, Kai Koehne wrote: > > -----Original Message----- [...] Can .pro files test for commercial > > vs. oss licenses? If so, and you create a non- Qt project repo, > > couldn't some .pro in qtbase retrieve licheck, like QtCreator does > > here: http://code.qt.io/cgit/qt-creator/qt- > > creator.git/tree/qtcreator.pro#n123? > > > > Is that an acceptable solution? Seems like it would work here, > > although I think the time stamp generation and commercial licenses > > would need to be added to qtbase (I think). > > Thanks, that's actually an interesting idea. Obvious downside is that > you need network access ... but you can argue that, if people are using > git, they most likely have it I am not sure I got the context right here, but as a general remark: "being in principle able to access network on demand, with permission, possibly restricted to certain times or other circumstances" does not mean that I would necessarily appreciate the attempt to access network at arbitrary times, in automated ways, possibly without my active knowledge and permission. So I'd prefer a git checkout to be usable offline, completely, without usable network access or even probing. Andre' From jani.heikkinen at qt.io Thu May 24 20:47:52 2018 From: jani.heikkinen at qt.io (Jani Heikkinen) Date: Thu, 24 May 2018 18:47:52 +0000 Subject: [Development] Cleaning old development releases from download.qt.io In-Reply-To: <1792318.MKPqlpxJoP@tjmaciei-mobl1> References: <1792318.MKPqlpxJoP@tjmaciei-mobl1> Message-ID: > -----Original Message----- > From: Development project.org> On Behalf Of Thiago Macieira > Sent: torstai 24. toukokuuta 2018 15.23 > To: development at qt-project.org > Subject: Re: [Development] Cleaning old development releases from > download.qt.io > > On Thursday, 24 May 2018 04:27:38 -03 Jani Heikkinen wrote: > > Hi! > > > > Disk usage in download.qt.io is quite huge (~1.5 TB) at the moment and > > it is causing problems for mirrors and mirroring. We are cleaning up > > unnecessary stuff from there and one thing to remove is old qt > > pre-releases (snapshots, alpha, beta and rc releases) from > > http://download.qt.io/development_releases/qt/ . I have already hide > > those old ones but before deleting those permanently I want to get > > confirmation if that is really OK; those pre-releases aren't available > > in http://download.qt.io/archive/qt. But official releases are there > > of course and that's why I think it should be OK to remove those pre- > releases. > > Snapshots yes. For the others, remove binaries but please keep the sources. Is sources really needed to be stored? Those pre-releases are also tagged in the git so everyone can get those from there if needed. And by default users should user official releases which are of course still available under "Official Release" or "Archive" - jani From bstottle at ford.com Thu May 24 21:18:22 2018 From: bstottle at ford.com (Stottlemyer, Brett (B.S.)) Date: Thu, 24 May 2018 19:18:22 +0000 Subject: [Development] Repository Request: qt/licensing In-Reply-To: <20180524044828.GA28115@klara.mpi.htwm.de> References: <4508906.VNGlaHcGFL@tjmaciei-mobl1> <5536979.OkiGCGMjE9@tjmaciei-mobl1> <20180524044828.GA28115@klara.mpi.htwm.de> Message-ID: <0eb12731dfa34124b31ebe08e4a72013@ford.com> On Thursday, May 24, 2018 12:48 AM, André Pönitz wrote: > ... does not mean that I would necessarily appreciate the attempt to access network at arbitrary times ... On Thursday, May 24, 2018 11:19 AM, Thiago Macieira wrote: > Uh... not really. I use git while on the plane :-) Fair points. I tend to build/update QtBase only a few times around the new releases, and usually I build/update QtCreator at the same time. Thus given the QtCreator code I referenced previously means those use cases/concerns are broken independent of my proposal. Maybe a combination is possible, where the project files look in a common location. If licheck isn't found, attempt to grab the file via https and put it there? Or print the necessary `git clone` message to grab licheck and put it in the right spot, then error out? Anything that avoids manual steps that are only found in the online documentation. Brett -----Original Message----- From: André Pönitz Sent: Thursday, May 24, 2018 12:48 AM To: Kai Koehne Cc: Stottlemyer, Brett (B.S.) ; Thiago Macieira ; development at qt-project.org Subject: Re: [Development] Repository Request: qt/licensing On Thu, May 24, 2018 at 12:58:43PM +0000, Kai Koehne wrote: > > -----Original Message----- [...] Can .pro files test for commercial > > vs. oss licenses? If so, and you create a non- Qt project repo, > > couldn't some .pro in qtbase retrieve licheck, like QtCreator does > > here: http://code.qt.io/cgit/qt-creator/qt- > > creator.git/tree/qtcreator.pro#n123? > > > > Is that an acceptable solution? Seems like it would work here, > > although I think the time stamp generation and commercial licenses > > would need to be added to qtbase (I think). > > Thanks, that's actually an interesting idea. Obvious downside is that > you need network access ... but you can argue that, if people are > using git, they most likely have it I am not sure I got the context right here, but as a general remark: "being in principle able to access network on demand, with permission, possibly restricted to certain times or other circumstances" does not mean that I would necessarily appreciate the attempt to access network at arbitrary times, in automated ways, possibly without my active knowledge and permission. So I'd prefer a git checkout to be usable offline, completely, without usable network access or even probing. Andre' From thiago.macieira at intel.com Thu May 24 21:45:58 2018 From: thiago.macieira at intel.com (Thiago Macieira) Date: Thu, 24 May 2018 16:45:58 -0300 Subject: [Development] Cleaning old development releases from download.qt.io In-Reply-To: References: <1792318.MKPqlpxJoP@tjmaciei-mobl1> Message-ID: <4836953.hrixnNk95e@tjmaciei-mobl1> On Thursday, 24 May 2018 15:47:52 -03 Jani Heikkinen wrote: > Is sources really needed to be stored? Those pre-releases are also tagged in > the git so everyone can get those from there if needed. And by default > users should user official releases which are of course still available > under "Official Release" or "Archive" The problem is that those sources are *not* what's on the repository, since our process includes a little more besides git archive. I know I couldn't recreate the release, if just given a tarball. So I'd rather we kept the actual, released sources. Note I'm asking only for alpha, beta and RC. We can even reduce by keeping only one set of sources, removing either the convenience tarball or the per-module sources. EVERYONE who is distributing Qt in their applications MUST keep a copy of the sources that they used in order to comply with the LGPL, but we know most people don't do that. If it's not too much to ask, we should help them comply with the LGPL. That said, we don't need those mirrored. They can be kept in a colder archive. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From thiago.macieira at intel.com Thu May 24 21:47:44 2018 From: thiago.macieira at intel.com (Thiago Macieira) Date: Thu, 24 May 2018 16:47:44 -0300 Subject: [Development] Repository Request: qt/licensing In-Reply-To: <0eb12731dfa34124b31ebe08e4a72013@ford.com> References: <20180524044828.GA28115@klara.mpi.htwm.de> <0eb12731dfa34124b31ebe08e4a72013@ford.com> Message-ID: <2826974.U5USLxe2Rx@tjmaciei-mobl1> On Thursday, 24 May 2018 16:18:22 -03 Stottlemyer, Brett (B.S.) wrote: > Maybe a combination is possible, where the project files look in a common > location. If licheck isn't found, attempt to grab the file via https and > put it there? Or print the necessary `git clone` message to grab licheck > and put it in the right spot, then error out? Anything that avoids manual > steps that are only found in the online documentation. Printing the instructions if licheck isn't found is preferable. Hitting the network during automated builds is really bad practice. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From thiago.macieira at intel.com Thu May 24 21:50:34 2018 From: thiago.macieira at intel.com (Thiago Macieira) Date: Thu, 24 May 2018 16:50:34 -0300 Subject: [Development] Cleaning old development releases from download.qt.io In-Reply-To: <4836953.hrixnNk95e@tjmaciei-mobl1> References: <4836953.hrixnNk95e@tjmaciei-mobl1> Message-ID: <1755436.93DHiGzQaI@tjmaciei-mobl1> On Thursday, 24 May 2018 16:45:58 -03 Thiago Macieira wrote: > The problem is that those sources are *not* what's on the repository, since > our process includes a little more besides git archive. I know I couldn't > recreate the release, if just given a tarball. I meant "if given a tag name" -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From pasi.keranen at qt.io Fri May 25 09:56:58 2018 From: pasi.keranen at qt.io (=?utf-8?B?UGFzaSBLZXLDpG5lbg==?=) Date: Fri, 25 May 2018 07:56:58 +0000 Subject: [Development] Qt 3D Studio 2.0 BETA 2 released Message-ID: <8BF31690-A700-4DF8-9593-8D3A6A69EA13@contoso.com> Hi, We have released Qt 3D Studio 2.0 BETA2 today. It is available as both commercial and open sourceversions from online and offline installers. For instructions on how to get started and install everything correctly, see Laszlo’s excellent blog on the subject for BETA1 here: http://blog.qt.io/blog/2018/05/18/get-started-qt-3d-studio-2-0-beta-1/ Regards, Pasi Keränen Senior Manager, 3D Team -------------- next part -------------- An HTML attachment was scrubbed... URL: From Uwe.Rathmann at tigertal.de Fri May 25 13:12:27 2018 From: Uwe.Rathmann at tigertal.de (Uwe Rathmann) Date: Fri, 25 May 2018 11:12:27 +0000 (UTC) Subject: [Development] QTBUG-43096 - QML instantiation performance decadence Message-ID: Hi all, this morning I got a notification about https://bugreports.qt.io/browse/QTBUG-43096 being closed. I guess many applications had been hit by this issue, but as I was related to the project that created this bug I would like to give my summary of what has happened since then: a) On the Qt development side a lot of efforts have been made to improve the QML problem. I don't want to be disrespectful, but the fact, that Controls 1 has finally become deprecated, because of ( IIRC ) "insolvable performance problems", it is fair say, that those were no game changers. So to me the only step that really matters was introducing Qt/Quick Controls 2. But what makes Controls 2 being superior compared to its predecessor ? AFAIK the answer is mostly about doing less QML, achieved by: - dropping features ( usually desktop related ) - internally done in C++ Of course this raises the question, why there is no offer for doing more in C++ on the application side, when it has been identified as the solution for implementing the controls ? And this is why I'm disappointed about Controls 2. Application code still has to be done in QML and when the majority of the GUI code is application code the benefits of Controls 2 are limited. b) On our side the the decision was made to go back to Qt 5.1, where the project is stuck until today. Almost all developers of the original team are gone - none of them recommending QML as technology for further projects. Even worse - some of them explicitly mentioned QML being a reason for leaving. So for the next generation of our product we started to implement our own framework on top of the C++ part of Qt/Quick ( https://github.com/uwerat/qskinny ). Our user interface today consists about ~200K lines of code ( pure C++ ) and so far I can say that the typical problems of having a bad startup performance or the heavy memory footprint simple don't exist. Unfortunately we still have to maintain our previous product written in QML for many years. Maybe we can migrate it step by step to our new framework. With all respect, Uwe From robin.burchell at crimson.no Fri May 25 14:30:05 2018 From: robin.burchell at crimson.no (Robin Burchell) Date: Fri, 25 May 2018 14:30:05 +0200 Subject: [Development] QTBUG-43096 - QML instantiation performance decadence In-Reply-To: References: Message-ID: <1527251405.2829505.1385058224.053D963E@webmail.messagingengine.com> Hi Uwe, I had predicted a response, so this mail comes as no surprise to me :) Personal opinions on various things ahead, the reader may disagree with me, that's perfectly normal and OK. >From my own perspective, I think Controls 1 was a well-intentioned mistake. It set out to fill a perceived hole in what QML/Quick offered, but it took some shortcuts getting there, which were no doubt unavoidable due to various reasons - if nothing else, the times were rather turbulent in the Qt world at the time. The end result of this was not something pretty, when looking at the pile of things like ScrollView regressions, usually a few per release, before even getting to performance concerns. Unfortunately, of course, since it existed, it got used - despite the shortcomings - though I would say that they likely made themselves very obvious without looking too hard. At this point, from my perspective, QQC1/QQC2 is largely water under the bridge. I have over the years avoided using QQC1 in several projects as I knew that the performance simply wasn't up to the task without ever trying it "seriously", instead developing custom controls or - now that it is available - using QQC2 where appropriate - so unfortunately, I won't really be able to comment much on that "excitement" except to say that I am happy that QQC2 exists, and I look forward to its continued growth and maturity to fill the gaps with QQC1 where possible and necessary. This leads me onto topic #2, which is QML's performance itself, and to me, this is a much more interesting topic, and where my own personal concern in the 5.1 -> 5.2 transition came into play. I experienced first-hand a lot of pain in those times and, realistically speaking, I don't think things really started to settle down until some years later. With the benefit of hindsight, I don't personally think that the engine transition from 5.1 to 5.2 went well, but on the other hand, people are human, and will make mistakes - the important thing is to learn from those mistakes, and not repeat them. As well as that, there were no doubt a number of contributing factors then, similar to QQC1's. That's quite far in the past, though. Nowadays, there has been a lot of work around the performance area, and it has continued to improve. There's also tracking of performance, to help avoid regressions in the area in future. These are the key reasons I closed the bug -- I think that the message has been heard, improvements have been made, and hopefully things are now consistently heading in the right direction. You mention qskinny. I think that experimentation is very cool, and it's great that it is working out for your project, and I am already familiar with it, but I'm not too interested in it personally, simply because the QML of "today" (having written a few libraries LOC of QML at this point) generally works well enough for me, and I find the convenience of the language very much worthwhile. I suppose it is also my role to be a cheerleader of sorts for this thing, so there's that. ;-) Even if our opinions differ though, I'd like to thank you for providing your perspective and story - it is not a surprise to me as I hope I have spelled out given the history of things, but it is interesting to hear. While I hear a lot of reluctance in your mail, I would encourage you to give QML another try in the future, and seeing how it goes for you. If there are things that you find surprising or unpleasant in the performance area, by all means, keep filing issues. Just because that one bug is closed doesn't mean the story is over: performance is a crucial feature in product development, and it is something that we must remain vigilant about, and work on continuously. :-) Thanks for the mail, Robin -- Robin Burchell robin at crimson.no On Fri, May 25, 2018, at 1:12 PM, Uwe Rathmann wrote: > Hi all, > > this morning I got a notification about > https://bugreports.qt.io/browse/QTBUG-43096 > being closed. I guess many applications had been hit by this issue, but > as I was related to the project that created this bug I would like to > give my summary of what has happened since then: > > a) > > On the Qt development side a lot of efforts have been made to improve > the QML problem. I don't want to be disrespectful, but the fact, that > Controls 1 has finally become deprecated, because of ( IIRC ) > "insolvable performance problems", it is fair say, that those were no > game changers. > > So to me the only step that really matters was introducing Qt/Quick > Controls 2. > > But what makes Controls 2 being superior compared to its predecessor ? > AFAIK the answer is mostly about doing less QML, achieved by: > > - dropping features ( usually desktop related ) > - internally done in C++ > > Of course this raises the question, why there is no offer for doing more > in C++ on the application side, when it has been identified as the > solution for implementing the controls ? > > And this is why I'm disappointed about Controls 2. Application code still > has to be done in QML and when the majority of the GUI code is > application code the benefits of Controls 2 are limited. > > b) > > On our side the the decision was made to go back to Qt 5.1, where the > project is stuck until today. > > Almost all developers of the original team are gone - none > of them recommending QML as technology for further projects. Even worse > - some of them explicitly mentioned QML being a reason for leaving. > > So for the next generation of our product we started to implement our > own framework on top of the C++ part of Qt/Quick ( > https://github.com/uwerat/qskinny ). Our user interface today consists > about ~200K lines of code ( pure C++ ) and so far I can say that the > typical problems of having a bad startup performance or the heavy memory > footprint simple don't exist. > > Unfortunately we still have to maintain our previous product written in > QML for many years. Maybe we can migrate it step by step to our new > framework. > > With all respect, > Uwe > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development From Simon.Hausmann at qt.io Fri May 25 15:20:48 2018 From: Simon.Hausmann at qt.io (Simon Hausmann) Date: Fri, 25 May 2018 13:20:48 +0000 Subject: [Development] QTBUG-43096 - QML instantiation performance decadence In-Reply-To: <1527251405.2829505.1385058224.053D963E@webmail.messagingengine.com> References: , <1527251405.2829505.1385058224.053D963E@webmail.messagingengine.com> Message-ID: Hi, And to add what Robin said, solely focused on the task in question that was closed: I ran benchmarks comparing a release build of 5.12 against 5.1.1 and ran the benchmark mentioned in the task, where Qt 5.12 came out in average faster by a factor of 4. More details as well as the concrete run results are in the JIRA ticket. I do consider the concret QML object instantiation performance decadence to be resolved. Simon ________________________________ From: Development on behalf of Robin Burchell Sent: Friday, May 25, 2018 2:30:05 PM To: development at qt-project.org Subject: Re: [Development] QTBUG-43096 - QML instantiation performance decadence Hi Uwe, I had predicted a response, so this mail comes as no surprise to me :) Personal opinions on various things ahead, the reader may disagree with me, that's perfectly normal and OK. >From my own perspective, I think Controls 1 was a well-intentioned mistake. It set out to fill a perceived hole in what QML/Quick offered, but it took some shortcuts getting there, which were no doubt unavoidable due to various reasons - if nothing else, the times were rather turbulent in the Qt world at the time. The end result of this was not something pretty, when looking at the pile of things like ScrollView regressions, usually a few per release, before even getting to performance concerns. Unfortunately, of course, since it existed, it got used - despite the shortcomings - though I would say that they likely made themselves very obvious without looking too hard. At this point, from my perspective, QQC1/QQC2 is largely water under the bridge. I have over the years avoided using QQC1 in several projects as I knew that the performance simply wasn't up to the task without ever trying it "seriously", instead developing custom controls or - now that it is available - using QQC2 where appropriate - so unfortunately, I won't really be able to comment much on that "excitement" except to say that I am happy that QQC2 exists, and I look forward to its continued growth and maturity to fill the gaps with QQC1 where possible and necessary. This leads me onto topic #2, which is QML's performance itself, and to me, this is a much more interesting topic, and where my own personal concern in the 5.1 -> 5.2 transition came into play. I experienced first-hand a lot of pain in those times and, realistically speaking, I don't think things really started to settle down until some years later. With the benefit of hindsight, I don't personally think that the engine transition from 5.1 to 5.2 went well, but on the other hand, people are human, and will make mistakes - the important thing is to learn from those mistakes, and not repeat them. As well as that, there were no doubt a number of contributing factors then, similar to QQC1's. That's quite far in the past, though. Nowadays, there has been a lot of work around the performance area, and it has continued to improve. There's also tracking of performance, to help avoid regressions in the area in future. These are the key reasons I closed the bug -- I think that the message has been heard, improvements have been made, and hopefully things are now consistently heading in the right direction. You mention qskinny. I think that experimentation is very cool, and it's great that it is working out for your project, and I am already familiar with it, but I'm not too interested in it personally, simply because the QML of "today" (having written a few libraries LOC of QML at this point) generally works well enough for me, and I find the convenience of the language very much worthwhile. I suppose it is also my role to be a cheerleader of sorts for this thing, so there's that. ;-) Even if our opinions differ though, I'd like to thank you for providing your perspective and story - it is not a surprise to me as I hope I have spelled out given the history of things, but it is interesting to hear. While I hear a lot of reluctance in your mail, I would encourage you to give QML another try in the future, and seeing how it goes for you. If there are things that you find surprising or unpleasant in the performance area, by all means, keep filing issues. Just because that one bug is closed doesn't mean the story is over: performance is a crucial feature in product development, and it is something that we must remain vigilant about, and work on continuously. :-) Thanks for the mail, Robin -- Robin Burchell robin at crimson.no On Fri, May 25, 2018, at 1:12 PM, Uwe Rathmann wrote: > Hi all, > > this morning I got a notification about > https://bugreports.qt.io/browse/QTBUG-43096 > being closed. I guess many applications had been hit by this issue, but > as I was related to the project that created this bug I would like to > give my summary of what has happened since then: > > a) > > On the Qt development side a lot of efforts have been made to improve > the QML problem. I don't want to be disrespectful, but the fact, that > Controls 1 has finally become deprecated, because of ( IIRC ) > "insolvable performance problems", it is fair say, that those were no > game changers. > > So to me the only step that really matters was introducing Qt/Quick > Controls 2. > > But what makes Controls 2 being superior compared to its predecessor ? > AFAIK the answer is mostly about doing less QML, achieved by: > > - dropping features ( usually desktop related ) > - internally done in C++ > > Of course this raises the question, why there is no offer for doing more > in C++ on the application side, when it has been identified as the > solution for implementing the controls ? > > And this is why I'm disappointed about Controls 2. Application code still > has to be done in QML and when the majority of the GUI code is > application code the benefits of Controls 2 are limited. > > b) > > On our side the the decision was made to go back to Qt 5.1, where the > project is stuck until today. > > Almost all developers of the original team are gone - none > of them recommending QML as technology for further projects. Even worse > - some of them explicitly mentioned QML being a reason for leaving. > > So for the next generation of our product we started to implement our > own framework on top of the C++ part of Qt/Quick ( > https://github.com/uwerat/qskinny ). Our user interface today consists > about ~200K lines of code ( pure C++ ) and so far I can say that the > typical problems of having a bad startup performance or the heavy memory > footprint simple don't exist. > > Unfortunately we still have to maintain our previous product written in > QML for many years. Maybe we can migrate it step by step to our new > framework. > > With all respect, > Uwe > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development _______________________________________________ Development mailing list Development at qt-project.org http://lists.qt-project.org/mailman/listinfo/development -------------- next part -------------- An HTML attachment was scrubbed... URL: From sergio.martins at kdab.com Fri May 25 15:54:41 2018 From: sergio.martins at kdab.com (=?UTF-8?Q?S=C3=A9rgio_Martins?=) Date: Fri, 25 May 2018 14:54:41 +0100 Subject: [Development] QTBUG-43096 - QML instantiation performance decadence In-Reply-To: References: Message-ID: <733674ae9e971877c2bf0584a69b6c70@kdab.com> On 2018-05-25 12:12, Uwe Rathmann wrote: > So for the next generation of our product we started to implement our > own framework on top of the C++ part of Qt/Quick ( > https://github.com/uwerat/qskinny ). Our user interface today consists > about ~200K lines of code ( pure C++ ) and so far I can say that the > typical problems of having a bad startup performance or the heavy > memory > footprint simple don't exist. > > Unfortunately we still have to maintain our previous product written in > QML for many years. Maybe we can migrate it step by step to our new > framework. You might also have problems maintaining qskinny since it's using private API. Which brings the question, should the needed API be made public ? Are there any parts of qskinny and/or patches that should be integrated to make it easier for such frameworks ? I think both QML-QtQuick and C++-QtQuick have their merits and we could improve the situation for the later. Regards, -- Sérgio Martins | sergio.martins at kdab.com | Senior Software Engineer Klarälvdalens Datakonsult AB, a KDAB Group company Tel: Sweden (HQ) +46-563-540090, USA +1-866-777-KDAB(5322) KDAB - The Qt, C++ and OpenGL Experts From Uwe.Rathmann at tigertal.de Fri May 25 16:31:30 2018 From: Uwe.Rathmann at tigertal.de (Uwe Rathmann) Date: Fri, 25 May 2018 14:31:30 +0000 (UTC) Subject: [Development] QTBUG-43096 - QML instantiation performance decadence References: <1527251405.2829505.1385058224.053D963E@webmail.messagingengine.com> Message-ID: Hi Robin, > From my own perspective, I think Controls 1 was a well-intentioned ... Agreed and to be honest I'm really impressed about what was doable in QML, but it also showed where its limitations are. But at the time, when Controls 2 has been started everything was on the table and - at least from the outside - it looked like a comfortable situation for making good decisions. And this is what I had expected to happen: a) a solid C++ API with the same quality we are used from all other Qt modules. Then the majority of the API is already available for QML by the standard mechanisms of the Qt/MetaObject system. b) a thin layer on top to make the QML API feature complete. Unfortunately I never noticed any indication pointing into the direction of a better C++ support. In fact the opposite happened: even the very base class of all QC 2 controls is not part of the public API ! > These are the key reasons I closed the bug -- I think > that the message has been heard, improvements have been made, and > hopefully things are now consistently heading in the right direction. The stupid fact is that QML always comes at a cost. Trying to reduce these cost has been successfully done and any further improvements are welcome, but: as long as there is no clear separation between the Qt/ Quick graphic stack and QML I disagree, that the "right direction" has already been found. > You mention qskinny. I think that experimentation is very cool, and it's > great that it is working out for your project, and I am already familiar > with it, but I'm not too interested in it personally, simply because the > QML of "today" (having written a few libraries LOC of QML at this point) > generally works well enough for me, and I find the convenience of the > language very much worthwhile. QSkinny is not about QML vs. C++ - it supports both, and some of the provided examples are in QML. The reasons, why we are not using QML is because we decided so. And this is the opposite to our previous version, where we made the decision for QML because we had to. -- Maybe a word on my intentions about QSkinny: in the first place it is supposed to be the platform for the products of our company ( being in the automotive industry ). So writing the docs, polishing the skins ( = themes ) or completing the set of controls - steps that should be done to make the project more accessible - do not have the priority they deserve. But I believe, that it is a good starting point to make more out of the Qt/Quick graphic stack as what we see today. And if in the end nobody else is interested ( in using or contributing ) it is good enough to demonstrate what is possible. Uwe From Uwe.Rathmann at tigertal.de Fri May 25 21:14:35 2018 From: Uwe.Rathmann at tigertal.de (Uwe Rathmann) Date: Fri, 25 May 2018 19:14:35 +0000 (UTC) Subject: [Development] QTBUG-43096 - QML instantiation performance decadence References: <1527251405.2829505.1385058224.053D963E@webmail.messagingengine.com> Message-ID: On Fri, 25 May 2018 14:30:05 +0200, Robin Burchell wrote: > I have over the years avoided using QQC1 in several projects as > I knew that the performance simply wasn't up to the task without ever > trying it "seriously", instead developing custom controls ... Please let me give a detailed answer to this one: On the Qt Conn 2016 Andrew ( Knight ) presented our very first results, when comparing 4 different implementations of an average button. a) a button from Quick Controls 1 b) a button from Quick Controls 2 c) a custom button composed in QML ( this is your approach ) d) a button from QSkinny All implementations have been done in QML with very similar code. Unfortunately the presentation has not been recorded, but out of my memory one of our statistics was: a) > 30 QObjects b + c ) 7 QObjects d) 1 QObject The reason why QSkinny is more lightweight is because it does scene graph node composition, where all other implementations are composing more heavy Quick items. ( But we also noticed stuff like that: QQuickGradient is a QObject and even QQuickGradientStop is one. So for the definition of a gradient with 2 colors you need 3 QObjects: > 400 bytes. These little things could easily being fixed by using Q_GADGET - but obviously nobody cares. ) -- Another example I can give is related to new code: the page indicator from Quick Controls 2. IMHO all what should be needed to describe such a control is the number of the bullets, the index of the current one, the shape of the bullets and maybe some color information - all in all maybe ~50 bytes. But the way how it is implemented is having a Quick Item for each bullet. IIRC an item has a minimum of 320 bytes ( usually more ) and has an extra transform node on top of its paint node. So we end up with something like n * 400 instead of ~50. Might be interesting to count the exact numbers being consumed with the existing styles - I would expect to end up with something scary. I don't want to insist too much on the page indicator example as this is usually not a control that is instantiated many times in the same application. But to me it is symptomatic and you find a similar situation almost everywhere. Uwe From robin.burchell at crimson.no Fri May 25 21:55:29 2018 From: robin.burchell at crimson.no (Robin Burchell) Date: Fri, 25 May 2018 21:55:29 +0200 Subject: [Development] QTBUG-43096 - QML instantiation performance decadence In-Reply-To: References: <1527251405.2829505.1385058224.053D963E@webmail.messagingengine.com> Message-ID: <1527278129.2975414.1385858480.6A305CD7@webmail.messagingengine.com> On Fri, May 25, 2018, at 4:31 PM, Uwe Rathmann wrote: > But at the time, when Controls 2 has been started everything was on the > table and - at least from the outside - it looked like a comfortable > situation for making good decisions. And this is what I had expected to > happen: What happens is only what there are enough time and resources to do, plus a direction to do it in the first place. It might be that you had attempted to drive some of this work yourself (or yourselves), I don't know - but I didn't see any discussion about it on this list that I recall, and I don't recall anything hitting codereview either, so I have to say that from the perspective of the project, I can't see how you could really expect this to happen. > Unfortunately I never noticed any indication pointing into the direction > of a better C++ support. In fact the opposite happened: even the very > base class of all QC 2 controls is not part of the public API ! Why does it need to be? I have never needed to subclass QQuickControl, personally, so I have never brought this topic up. Assuming you have a valid reason, then I would present my next problem with that: it's probably not mature enough. QQC2 is only three years old, and it is (still) going through quite a lot of change that is often likely not ABI compatible[1]. Sure, it's often _possible_ to work with this stuff in a backwards-compatible fashion, but that comes at a strong cost, which then requires answering: does the cost of having to work in such a manner justify making it public? I would tend to suggest no in that particular case from what I know right now. > The stupid fact is that QML always comes at a cost. Trying to reduce > these cost has been successfully done and any further improvements are > welcome, but: as long as there is no clear separation between the Qt/ > Quick graphic stack and QML I disagree, that the "right direction" has > already been found. There is a cost, yes. But I would say it's more a cost/benefit tradeoff. Faster prototyping and development cycles at a cost of requiring some of your resources to munch on. And, well, this problem isn't just limited to QML or QtQuick- if you want to run Qt as it exists today on a lightbulb, you're probably getting something wrong in your architectural design. ;-) Anyway, wrt direction, I assume you are hinting at a scenegraph that is less tied to QtQuick. If you are volunteering to help engineer such a separation in a way that is maintainable in the long term, and doesn't negatively impact performance of the graphics stack's consumer (QtQuick), then I have no objections personally, though I'm not really the right person to talk to. I would suggest coming up with specific proposals for what you want done, talking them over on this list, and then working on patches assuming there are no objections. But if you are asking me personally to separate the scenegraph out, then I have no interest in doing so. As I said, I am happy with QML and QtQuick in their present form (with hopefully indefinite iterations to improve it over time, of course). [1]: This does bring me to something that I do find unfortunate: API stability is a lot easier to promise than ABI stability. I can imagine a world in which we would have a public _API_ for more things than we do nowadays, but I am hesitant to contemplate that too much, because it ties our hands in changing the implementation a lot wrt ABI compatibility. From robin.burchell at crimson.no Fri May 25 22:35:58 2018 From: robin.burchell at crimson.no (Robin Burchell) Date: Fri, 25 May 2018 22:35:58 +0200 Subject: [Development] QTBUG-43096 - QML instantiation performance decadence In-Reply-To: References: <1527251405.2829505.1385058224.053D963E@webmail.messagingengine.com> Message-ID: <1527280558.2986762.1385858720.79637EA8@webmail.messagingengine.com> On Fri, May 25, 2018, at 9:14 PM, Uwe Rathmann wrote: > On the Qt Conn 2016 Andrew ( Knight ) presented our very first results, > when comparing 4 different implementations of an average button. > > a) a button from Quick Controls 1 > b) a button from Quick Controls 2 > c) a custom button composed in QML ( this is your approach ) > d) a button from QSkinny > > All implementations have been done in QML with very similar code. > > Unfortunately the presentation has not been recorded, but out of my > memory one of our statistics was: > > a) > 30 QObjects > b + c ) 7 QObjects > d) 1 QObject I'm familiar with numbers like that. I've come up with many similar ones myself in the past. The first point I would make in reply, though, is that the convenience of creating code with a/b/c are going to be significantly better in my experience. And in addition, nothing (except the lack of a need to _actually_ go this far) stops me from writing a button using QSGNode instances today, without any use of private API and similarly avoiding many of those object allocations. The one feature that would be a problem would be a missing public text node, which would mean I'd have to resort to a QQmlComponent with a Text item in it to set my label. Off the top of my head, that makes three QObjects, for the record: a QQuickItem for the button, a QObject (really a QQuickTextItem) from the component, and QQmlComponent itself, though that last one can be shared between buttons. Adding a public text node would be nice if we wanted to make it a single QObject, but doesn't justify creating a whole new framework to me, given it's perfectly possible with the API of QtQuick today, and there is plenty of precedent (and demand) for it. (And no, I don't think that just making QQuickTextNode public is the answer. That is a very, very heavy set of classes, it really needs some thought and cleanup applied first I think, alas, I don't know of anyone working on it today...) > ( But we also noticed stuff like that: QQuickGradient is a QObject and > even QQuickGradientStop is one. So for the definition of a gradient with > 2 colors you need 3 QObjects: > 400 bytes. These little things could > easily being fixed by using Q_GADGET - but obviously nobody cares. ) It's not that nobody cares, it's that you can't actually do that without breaking code that probably[1] exists in the real world. Let's take another good example from the top of my head: Item::anchors. Behind the scenes, it's implemented as a QQuickAnchors, which is a QObject. Let's turn it into a Q_GADGET, and we're done, right? Well, not quite, because now any code that does this: anchors { onLeftChanged { ... } } or this: this.anchors.leftChanged.connect(function() { ... }) or in the C++ world: connect(myItem->anchors(), &QQuickAnchors::leftChanged, ... ... will break, since Q_GADGET doesn't have signals - so it's simply not equivilent. It's nice to contemplate this sort of stuff, of course, and I'd love to see common features like anchors made cheaper (really, gradients aren't anywhere near as common, at least for the sake of my eyeballs I sure hope so), but doing so requires a careful approach, and probably a good chunk of grunt-work and magic that doesn't exist right now to make it actually happen, which is likely why it hasn't happened yet. Suggestions of how (or better still, patches), most certainly welcome. [1]: almost certainly. my personal rule is: if there is API for it, someone will misuse it in the most awful way possible to make your life hell with it, somehow. I think one has to have a love-hate relationship with users, you can't live without them, but my god you wish you could sometimes ;-). From jeanmichael.celerier at gmail.com Sat May 26 08:38:27 2018 From: jeanmichael.celerier at gmail.com (=?UTF-8?Q?Jean=2DMicha=C3=ABl_Celerier?=) Date: Sat, 26 May 2018 08:38:27 +0200 Subject: [Development] QTBUG-43096 - QML instantiation performance decadence In-Reply-To: <1527278129.2975414.1385858480.6A305CD7@webmail.messagingengine.com> References: <1527251405.2829505.1385058224.053D963E@webmail.messagingengine.com> <1527278129.2975414.1385858480.6A305CD7@webmail.messagingengine.com> Message-ID: > Why does it need to be? I have never needed to subclass QQuickControl, personally, so I have never brought this topic up. It's not about subclassing QQuickControl, it's about running code without a JIT / interpreter. Even if the cost in startup time and performance is minimal, it is not as fast as raw C++ code - and there's nothing wrong with wanting Qt to run on a lightbulb... some lightbulbs today have better CPUs than the ones Qt was originally developed on. In addition, there's something in which Qt Quick fails quite flat: any kind of UI that revolves around graphs with a lot of objects - stuff with which QGraphicsView is perfectly at ease. Look for instance at the model editor in Qt Creator : they went - rightly - with QGraphicsView. I tried to port my software (https://github.com/OSSIA/score) to Qt Quick twice but stuff like showing hundreds of text elements updated concurrently killed performance, while QGraphicsView has no problem blitting them like there's no tomorrow. And that's with Qt Quick having a much more restricted API than QGraphicsScene/View. But of course I'm sad since I have to reimplement basic widgets in QGraphics* manually and cannot use the pretty QQC2 ones :p Even the latest innovation, QML Shapes, is beaten in performance by existing solutions : http://kgronholm.blogspot.fr/2017/12/qt-510-rendering-benchmarks.html that in addition also provide a C++ API. ------- Jean-Michaël Celerier http://www.jcelerier.name On Fri, May 25, 2018 at 9:55 PM, Robin Burchell wrote: > On Fri, May 25, 2018, at 4:31 PM, Uwe Rathmann wrote: > > But at the time, when Controls 2 has been started everything was on the > > table and - at least from the outside - it looked like a comfortable > > situation for making good decisions. And this is what I had expected to > > happen: > > What happens is only what there are enough time and resources to do, plus > a direction to do it in the first place. It might be that you had attempted > to drive some of this work yourself (or yourselves), I don't know - but I > didn't see any discussion about it on this list that I recall, and I don't > recall anything hitting codereview either, so I have to say that from the > perspective of the project, I can't see how you could really expect this to > happen. > > > Unfortunately I never noticed any indication pointing into the direction > > of a better C++ support. In fact the opposite happened: even the very > > base class of all QC 2 controls is not part of the public API ! > > Why does it need to be? I have never needed to subclass QQuickControl, > personally, so I have never brought this topic up. > > Assuming you have a valid reason, then I would present my next problem > with that: it's probably not mature enough. QQC2 is only three years old, > and it is (still) going through quite a lot of change that is often likely > not ABI compatible[1]. Sure, it's often _possible_ to work with this stuff > in a backwards-compatible fashion, but that comes at a strong cost, which > then requires answering: does the cost of having to work in such a manner > justify making it public? I would tend to suggest no in that particular > case from what I know right now. > > > The stupid fact is that QML always comes at a cost. Trying to reduce > > these cost has been successfully done and any further improvements are > > welcome, but: as long as there is no clear separation between the Qt/ > > Quick graphic stack and QML I disagree, that the "right direction" has > > already been found. > > There is a cost, yes. But I would say it's more a cost/benefit tradeoff. > Faster prototyping and development cycles at a cost of requiring some of > your resources to munch on. And, well, this problem isn't just limited to > QML or QtQuick- if you want to run Qt as it exists today on a lightbulb, > you're probably getting something wrong in your architectural design. ;-) > > Anyway, wrt direction, I assume you are hinting at a scenegraph that is > less tied to QtQuick. If you are volunteering to help engineer such a > separation in a way that is maintainable in the long term, and doesn't > negatively impact performance of the graphics stack's consumer (QtQuick), > then I have no objections personally, though I'm not really the right > person to talk to. I would suggest coming up with specific proposals for > what you want done, talking them over on this list, and then working on > patches assuming there are no objections. > > But if you are asking me personally to separate the scenegraph out, then I > have no interest in doing so. As I said, I am happy with QML and QtQuick in > their present form (with hopefully indefinite iterations to improve it over > time, of course). > > [1]: This does bring me to something that I do find unfortunate: API > stability is a lot easier to promise than ABI stability. I can imagine a > world in which we would have a public _API_ for more things than we do > nowadays, but I am hesitant to contemplate that too much, because it ties > our hands in changing the implementation a lot wrt ABI compatibility. > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Uwe.Rathmann at tigertal.de Sat May 26 11:20:09 2018 From: Uwe.Rathmann at tigertal.de (Uwe Rathmann) Date: Sat, 26 May 2018 09:20:09 +0000 (UTC) Subject: [Development] QTBUG-43096 - QML instantiation performance decadence References: <1527251405.2829505.1385058224.053D963E@webmail.messagingengine.com> <1527278129.2975414.1385858480.6A305CD7@webmail.messagingengine.com> Message-ID: Hi Robin, > Why does it need to be? I have never needed to subclass QQuickControl, > personally, so I have never brought this topic up. For the same reason all other controls from QC2 do subclass it. If you want to participate in mechanisms ( like font/locale/palette propagation ) that are implemented in this base class, you have to. > There is a cost, yes. But I would say it's more a cost/benefit tradeoff. > Faster prototyping and development cycles at a cost of requiring some of > your resources to munch on. Please allow me not to respond: I would like to avoid ending up in yet another QML vs. C++ discussion. > Anyway, wrt direction, I assume you are hinting at a scenegraph that is > less tied to QtQuick. No, the scene graph is already a standalone module with a well designed public API: many thanks to the authors. Its API could be more comfortable and the existing set of nodes is underfeatured, but in general I have not much to complain. Almost everything is about the C++ classes of the various Qt/Quick modules. The majority of them is designed with having QML as the one and only use case in mind. I'm also not happy about how the scene graph is used inside of those classes, because it substantially contributes to the memory and startup performance problems of Qt/Quick. It took me some tome to get those things under control, but in the end it was possible without having to patch Qt code itself. > If you are volunteering ... I am - and you can already see more than 50K lines of code from my efforts. Uwe From Uwe.Rathmann at tigertal.de Sat May 26 12:30:11 2018 From: Uwe.Rathmann at tigertal.de (Uwe Rathmann) Date: Sat, 26 May 2018 10:30:11 +0000 (UTC) Subject: [Development] QTBUG-43096 - QML instantiation performance decadence References: <1527251405.2829505.1385058224.053D963E@webmail.messagingengine.com> <1527280558.2986762.1385858720.79637EA8@webmail.messagingengine.com> Message-ID: On Fri, 25 May 2018 22:35:58 +0200, Robin Burchell wrote: > The first point I would make in reply, though, is > that the convenience of creating code with a/b/c are going to be > significantly better in my experience. Code for d) look like this: https://github.com/uwerat/qskinny/blob/master/examples/buttons/buttons.qml IMHO the code for a/b would be very similar, the only one that requires more work would be c as you need extra code for creating the button itself. > Let's take > another good example from the top of my head: Item::anchors. Behind the > scenes, it's implemented as a QQuickAnchors, which is a QObject. Let's > turn it into a Q_GADGET, and we're done, right? No, but please let's stay with gradients, where the answer is yes. QSkinny offers this class to expose gradients to QML: https://github.com/ uwerat/qskinny/blob/master/src/common/QskGradient.h Now when having an control with a property like this: class MyRectangle : public QQuickItem { Q_OBJECT Q_PROPERTY( QskGradient gradient READ gradient WRITE setGradient RESET resetGradient NOTIFY gradientChanged ) ... }; you can write your QML code this way: MyRectangle { gradient { orientation: "Vertical" stops: [ { position: 0.0, color: "MediumAquamarine" }, { position: 0.5, color: "..." }, { position: 1.0, color: "DarkSeaGreen" }, ] } } The equivalent code offered by Qt/Quick needs 4 QObjects - for each instance of an item. So when having 100 rectangles these are 400 QObjects - good for nothing. Uwe From tantrido at ya.ru Sat May 26 12:36:23 2018 From: tantrido at ya.ru (Aleksey Kontsevich) Date: Sat, 26 May 2018 12:36:23 +0200 Subject: [Development] QTBUG-43096 - QML instantiation performance decadence In-Reply-To: References: <1527251405.2829505.1385058224.053D963E@webmail.messagingengine.com> <1527280558.2986762.1385858720.79637EA8@webmail.messagingengine.com> Message-ID: <1977491527330983@myt5-b94652e6921b.qloud-c.yandex.net> An HTML attachment was scrubbed... URL: From Simon.Hausmann at qt.io Sat May 26 14:05:38 2018 From: Simon.Hausmann at qt.io (Simon Hausmann) Date: Sat, 26 May 2018 12:05:38 +0000 Subject: [Development] QTBUG-43096 - QML instantiation performance decadence In-Reply-To: References: <1527251405.2829505.1385058224.053D963E@webmail.messagingengine.com> <1527280558.2986762.1385858720.79637EA8@webmail.messagingengine.com>, Message-ID: Hi, Jędrzej had a beautiful proof of concept at some point for QObject to combine the object and d-pointer allocation into one. That's where I had the idea that perhaps this idea could be extended all the way to QML, so that the instantiation of a .qml file would collect all object and d-pointer sizes at type compilation time and use a bumper pointer allocator during instantiation (assuming that we can verify upfront that the types support it). The consequence would be one libc malloc for all objects per .qml file and pointer based APIs like anchors or gradients would involve no data copying at all, as opposed to value based gadget APIs. This would require a static QObject parent-hierarchy and make a few other assumptions, but as long as they are the common case and can be detected, I think there are ways of making QtQuick elements instantiate faster and use less memory. Simon P.S.: Are you sure the stops: [ ... ] assignment works? ________________________________ From: Development on behalf of Uwe Rathmann Sent: Saturday, May 26, 2018 12:30:11 PM To: development at qt-project.org Subject: Re: [Development] QTBUG-43096 - QML instantiation performance decadence On Fri, 25 May 2018 22:35:58 +0200, Robin Burchell wrote: > The first point I would make in reply, though, is > that the convenience of creating code with a/b/c are going to be > significantly better in my experience. Code for d) look like this: https://github.com/uwerat/qskinny/blob/master/examples/buttons/buttons.qml IMHO the code for a/b would be very similar, the only one that requires more work would be c as you need extra code for creating the button itself. > Let's take > another good example from the top of my head: Item::anchors. Behind the > scenes, it's implemented as a QQuickAnchors, which is a QObject. Let's > turn it into a Q_GADGET, and we're done, right? No, but please let's stay with gradients, where the answer is yes. QSkinny offers this class to expose gradients to QML: https://github.com/ uwerat/qskinny/blob/master/src/common/QskGradient.h Now when having an control with a property like this: class MyRectangle : public QQuickItem { Q_OBJECT Q_PROPERTY( QskGradient gradient READ gradient WRITE setGradient RESET resetGradient NOTIFY gradientChanged ) ... }; you can write your QML code this way: MyRectangle { gradient { orientation: "Vertical" stops: [ { position: 0.0, color: "MediumAquamarine" }, { position: 0.5, color: "..." }, { position: 1.0, color: "DarkSeaGreen" }, ] } } The equivalent code offered by Qt/Quick needs 4 QObjects - for each instance of an item. So when having 100 rectangles these are 400 QObjects - good for nothing. Uwe _______________________________________________ Development mailing list Development at qt-project.org http://lists.qt-project.org/mailman/listinfo/development -------------- next part -------------- An HTML attachment was scrubbed... URL: From jeanmichael.celerier at gmail.com Sat May 26 14:12:25 2018 From: jeanmichael.celerier at gmail.com (=?UTF-8?Q?Jean=2DMicha=C3=ABl_Celerier?=) Date: Sat, 26 May 2018 14:12:25 +0200 Subject: [Development] QTBUG-43096 - QML instantiation performance decadence In-Reply-To: References: <1527251405.2829505.1385058224.053D963E@webmail.messagingengine.com> <1527280558.2986762.1385858720.79637EA8@webmail.messagingengine.com> Message-ID: > Jędrzej had a beautiful proof of concept at some point for QObject to combine the object and d-pointer allocation into one. If only there was a way to be able to use Qt without all the PIMPLing and just have QObjectPrivate be a "normal" QObject member ! ------- Jean-Michaël Celerier http://www.jcelerier.name On Sat, May 26, 2018 at 2:05 PM, Simon Hausmann wrote: > Hi, > > > Jędrzej had a beautiful proof of concept at some point for QObject to > combine the object and d-pointer allocation into one. > > > That's where I had the idea that perhaps this idea could be extended all > the way to QML, so that the instantiation of a .qml file would collect all > object and d-pointer sizes at type compilation time and use a bumper > pointer allocator during instantiation (assuming that we can verify upfront > that the types support it). > > > The consequence would be one libc malloc for all objects per .qml file and > pointer based APIs like anchors or gradients would involve no data copying > at all, as opposed to value based gadget APIs. > > > This would require a static QObject parent-hierarchy and make a few other > assumptions, but as long as they are the common case and can be detected, I > think there are ways of making QtQuick elements instantiate faster and use > less memory. > > > > > Simon > > > P.S.: Are you sure the stops: [ ... ] assignment works? > ------------------------------ > *From:* Development qt.io at qt-project.org> on behalf of Uwe Rathmann > *Sent:* Saturday, May 26, 2018 12:30:11 PM > *To:* development at qt-project.org > *Subject:* Re: [Development] QTBUG-43096 - QML instantiation performance > decadence > > On Fri, 25 May 2018 22:35:58 +0200, Robin Burchell wrote: > > > The first point I would make in reply, though, is > > that the convenience of creating code with a/b/c are going to be > > significantly better in my experience. > > Code for d) look like this: > https://github.com/uwerat/qskinny/blob/master/examples/buttons/buttons.qml > > IMHO the code for a/b would be very similar, the only one that requires > more work would be c as you need extra code for creating the button > itself. > > > Let's take > > another good example from the top of my head: Item::anchors. Behind the > > scenes, it's implemented as a QQuickAnchors, which is a QObject. Let's > > turn it into a Q_GADGET, and we're done, right? > > No, but please let's stay with gradients, where the answer is yes. > > QSkinny offers this class to expose gradients to QML: https://github.com/ > uwerat/qskinny/blob/master/src/common/QskGradient.h > > Now when having an control with a property like this: > > class MyRectangle : public QQuickItem > { > Q_OBJECT > > Q_PROPERTY( QskGradient gradient READ gradient > WRITE setGradient RESET resetGradient NOTIFY gradientChanged ) > > ... > }; > > you can write your QML code this way: > > MyRectangle > { > gradient { > orientation: "Vertical" > > stops: [ > { position: 0.0, color: "MediumAquamarine" }, > { position: 0.5, color: "..." }, > { position: 1.0, color: "DarkSeaGreen" }, > ] > } > } > > The equivalent code offered by Qt/Quick needs 4 QObjects - for each > instance of an item. So when having 100 rectangles these are 400 QObjects > - good for nothing. > > Uwe > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Uwe.Rathmann at tigertal.de Sat May 26 14:52:59 2018 From: Uwe.Rathmann at tigertal.de (Uwe Rathmann) Date: Sat, 26 May 2018 12:52:59 +0000 (UTC) Subject: [Development] QTBUG-43096 - QML instantiation performance decadence References: <1527251405.2829505.1385058224.053D963E@webmail.messagingengine.com> <1527280558.2986762.1385858720.79637EA8@webmail.messagingengine.com> Message-ID: On Sat, 26 May 2018 12:05:38 +0000, Simon Hausmann wrote: > P.S.: Are you sure the stops: [ ... ] assignment works? You are right: I forgot to mention this extra piece of code: QMetaType::registerConverter< QJSValue, QskGradientStop >( [] (const QJSValue& value) -> QskGradientStop { return { value.property( QLatin1String("position") ).toNumber(), value.property( QLatin1String("color") ).toVariant ().value< QColor >() }; } ); It can be found in https://github.com/uwerat/qskinny/blob/master/src/ common/QskModule.cpp. Most of the tricks for exposing stuff to QML have been written by Andrew ( Knight ) who is way more familiar with the QML world than I am. In the beginning we were not sure if we will be able to come up with a framework, that allows us to get rid of QML in general. That's why we played with ways how to expose our APIs to QML without creating the same overhead you find in the existing classes. Today the QML API is not in the focus of the application driving the development of QSkinny. But from the initial proof of concept it is pretty clear that I can expose - let's say 80-90 % of the API - to QML easily. But a Qt/Quick application is always a combination of QML and C++ and I don't see why it is necessary trying to do as much as possible in the QML part. Uwe From ville.voutilainen at gmail.com Sat May 26 15:07:46 2018 From: ville.voutilainen at gmail.com (Ville Voutilainen) Date: Sat, 26 May 2018 16:07:46 +0300 Subject: [Development] QTBUG-43096 - QML instantiation performance decadence In-Reply-To: References: <1527251405.2829505.1385058224.053D963E@webmail.messagingengine.com> <1527278129.2975414.1385858480.6A305CD7@webmail.messagingengine.com> Message-ID: On 26 May 2018 at 12:20, Uwe Rathmann wrote: > Hi Robin, > >> Why does it need to be? I have never needed to subclass QQuickControl, >> personally, so I have never brought this topic up. > > For the same reason all other controls from QC2 do subclass it. If you > want to participate in mechanisms ( like font/locale/palette propagation > ) that are implemented in this base class, you have to. > >> There is a cost, yes. But I would say it's more a cost/benefit tradeoff. >> Faster prototyping and development cycles at a cost of requiring some of >> your resources to munch on. > > Please allow me not to respond: I would like to avoid ending up in yet > another QML vs. C++ discussion. I think it makes perfect sense for many reasons to strive for exposing the QC2/QML/etc. API to C++ applications, and that that's something we should certainly do. There are very reasonable user scenarios and business cases where that would be desirable, as the trade-offs mentioned are on the scale from unpalatable to undesirable to unattractive. From thiago.macieira at intel.com Sat May 26 15:15:00 2018 From: thiago.macieira at intel.com (Thiago Macieira) Date: Sat, 26 May 2018 10:15:00 -0300 Subject: [Development] QTBUG-43096 - QML instantiation performance decadence In-Reply-To: References: <1527278129.2975414.1385858480.6A305CD7@webmail.messagingengine.com> Message-ID: <3564014.BLptoYu3I1@tjmaciei-mobl1> On Saturday, 26 May 2018 03:38:27 -03 Jean-Michaël Celerier wrote: > It's not about subclassing QQuickControl, it's about running code without a > JIT / interpreter. Even if the cost in startup time and performance is > minimal, it is not as fast as raw C++ code - and there's nothing wrong with > wanting Qt to run on a lightbulb... some lightbulbs today have better CPUs > than the ones Qt was originally developed on. I know you're making an exaggeration here for the sake of the argument, but it's not correct. First, Qt has considerably grown since 1.0. Just compare the size of the downloads from Qt 1.4 (available somewhere in download.qt.io, see Paul's blog) to 5.11. QtCore alone, today, is multiple times the size of the full Qt of back then. Second, no, Qt has never run on a CPU as tiny as you can find today on microcontrollers being deployed for IoT today. Those are still measured in tens of kilobytes of RAM with maybe a hundred kilobyte of flash storage. The only indicator that is comparable to the mainstay computers of 20 years ago is the clock: the microcontrollers run at tens of MHz, which is what the original Pentium from 1991 did (60 MHz). You may be thinking of processors as powerful as a Raspberry Pi Zero. Trust me, that is NOT what you would deploy to a light bulb, temperature sensor, humidity sensor, etc. You wouldn't even find that on a controller device with a simple screen, like a thermostat similar to the Google Nest: a system like you find on routers today (8-32 MB of flash storage, 32-128 MB of RAM, a CPU running at 200-600 MHz) more than suffices. Qt *could* run at the higher end of those, with a lot of compromises to make it fit. Which is why I don't think Qt has a role to play in these types of devices. Instead, Qt is far more likely to play in the industrial segment where devices need complex Human Machine Interfaces (HMI) and monitoring capabilities. Devices are also far more costly, since they aren't going for mass-market strategies. Finally, there's one more segment Qt could play, but it doesn't exist yet: microservices. If we start seeing controllers like I described replaced by a bigger device capable of installing and running multiple services, configurable by the user, then some of those could be Qt. Those microservices are likely to simply be Linux containers, so you should be expecting the host device to be like a Raspberry Pi or a low-end Intel Atom CPU with 1 GB of RAM or so. [It goes without saying that Qt could be used for digital signage, but it's a stretch to call those IoT] -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From thiago.macieira at intel.com Sat May 26 15:17:09 2018 From: thiago.macieira at intel.com (Thiago Macieira) Date: Sat, 26 May 2018 10:17:09 -0300 Subject: [Development] QTBUG-43096 - QML instantiation performance decadence In-Reply-To: References: Message-ID: <1843949.dfA5k42zuE@tjmaciei-mobl1> On Saturday, 26 May 2018 09:12:25 -03 Jean-Michaël Celerier wrote: > If only there was a way to be able to use Qt without all the PIMPLing and > just have QObjectPrivate be a "normal" QObject member ! You'd save maybe 10% of the allocations. Don't forget that the privates have a lot of internals that allocate memory too, in the form of vectors, strings, signal-slot connecion tables, etc. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From jeanmichael.celerier at gmail.com Sat May 26 19:01:59 2018 From: jeanmichael.celerier at gmail.com (=?UTF-8?Q?Jean=2DMicha=C3=ABl_Celerier?=) Date: Sat, 26 May 2018 19:01:59 +0200 Subject: [Development] QTBUG-43096 - QML instantiation performance decadence In-Reply-To: <1843949.dfA5k42zuE@tjmaciei-mobl1> References: <1843949.dfA5k42zuE@tjmaciei-mobl1> Message-ID: Well, you mention Nest thermostats : those actually run a Linux with 512 mb of RAM - more than enough for some QtCore goodness. > Which is why I don't think Qt has a role to play in these types of devices. This I don't understand. There would be so much to win in terms of code reuse - currently I have a QObject hierarchy for desktop and Qt UI interoperatibility and a raw C++ object hierarchy for embedded ; I'm just recreating the same stuff twice. It kills me that the embedded devices I use are powerful enough to run Python and Javascript interpreters but not some QObjects. About the allocations, I don't know: running my app under heaptrack shows that QObjectPrivate is responsible for a great deal of those - way more than I would like. Besides, this is not so much a problem of memory than a problem of cache fragmentation. And in semi-powerful devices like Pi you can really feel these effects if you are trying to push them to the max. Ideally, there would be something like QObject but which allows full constexpr or at least static-initialization; since embedded devices commonly have static object trees which could be built at compile-time. A QObjectLiteral of some sorts if you want, like QStringLiteral :p ------- Jean-Michaël Celerier http://www.jcelerier.name On Sat, May 26, 2018 at 3:17 PM, Thiago Macieira wrote: > On Saturday, 26 May 2018 09:12:25 -03 Jean-Michaël Celerier wrote: > > If only there was a way to be able to use Qt without all the PIMPLing and > > just have QObjectPrivate be a "normal" QObject member ! > > You'd save maybe 10% of the allocations. Don't forget that the privates > have a > lot of internals that allocate memory too, in the form of vectors, > strings, > signal-slot connecion tables, etc. > > -- > Thiago Macieira - thiago.macieira (AT) intel.com > Software Architect - Intel Open Source Technology Center > > > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development > -------------- next part -------------- An HTML attachment was scrubbed... URL: From thiago.macieira at intel.com Sat May 26 20:04:43 2018 From: thiago.macieira at intel.com (Thiago Macieira) Date: Sat, 26 May 2018 15:04:43 -0300 Subject: [Development] QTBUG-43096 - QML instantiation performance decadence In-Reply-To: References: <1843949.dfA5k42zuE@tjmaciei-mobl1> Message-ID: <3631708.1e7lxq5fpB@tjmaciei-mobl1> On Saturday, 26 May 2018 14:01:59 -03 Jean-Michaël Celerier wrote: > Well, you mention Nest thermostats : those actually run a Linux with 512 mb > of RAM - more than enough for some QtCore goodness. I said "similar to". Yes, there are some overkill devices for the needs they have. Usually because whoever made them decided to go for Java or HTML5 UI. Another reason for 512 MB of RAM is that there are no smaller discrete memory modules. It's just not worth producing them in scale, so their price is actually higher than 512 MB, so no one produces them ... vicious cycle. There's a huge chasm between embedded RAM (order of a few MB) and discrete RAM (512 MB). > > Which is why I don't think Qt has a role to play in these types of > > devices. > > This I don't understand. There would be so much to win in terms of code > reuse - currently I have a QObject hierarchy for desktop and Qt UI > interoperatibility and a raw C++ object hierarchy for embedded ; I'm just > recreating the same stuff twice. It kills me that the embedded devices I > use are powerful enough to run Python and Javascript interpreters but not > some QObjects. Qt is not going to run on a device with 16 MB of RAM. Period. Even running a regular Linux userspace is going to be tricky -- forget systemd at less than 8 MB. There are JavaScript interpreters for microcontrollers (see Duktape and Jerryscript). But those are designed to run on tens of *kilobytes* of RAM. You can't compare them to Qt, as they have special limitations to run that way. For example, neither implementation supports "eval". Instead, compare Qt to a full JS interpreter, like V8. You need those 512 MB for it, otherwise you won't run comfortably. Ditto for Python. But Qt can run comfortably on 128 MB of RAM, possibly 64. QtCore+QtNetwork plus Websocket or OPC-UA or CoAP or other IoT protocols can definitely make do at 32 MB. But like I said, those devices don't exist because 32 MB is just not economical. Even routers and NAS are coming with 512 MB or 1 GB of RAM, for no technical reason at all. > About the allocations, I don't know: running my app under heaptrack shows > that QObjectPrivate is responsible for a great deal of those - way more > than I would like. Besides, this is not so much a problem of memory than a > problem of cache fragmentation. And in semi-powerful devices like Pi you > can really feel these effects if you are trying to push them to the max. That's because the Pi is, like you qualified, "semi-powerful". It's not powerful enough to make those limitations go away by using speculative execution and pipelining (which is why it wasn't affected by Spectre), but it's also big enough that people run complex software in it. In other worlds, it's "the worst of both worlds". You should choose either a small microcontroller with a dedicated MCU-class OS that uses static memory allocation, or you should go for an actual powerful device that will hide those issues by doing other things while it waits for memory. > Ideally, there would be something like QObject but which allows full > constexpr or at least static-initialization; since embedded devices > commonly have static object trees which could be built at compile-time. A > QObjectLiteral of some sorts if you want, like QStringLiteral :p Never going to happen, not in standard Qt anyway. Any such hacks would be specific to their particular use and hardly reusable. You're getting close to static memory allocation, which is when you decide at compile time that you're going to have N such objects and never more. That's how MCU-class OSes implement TCP/IP for example. They can have at most an configuration-time chosen number of simultaneous connections. If you try to start one more or if you receive one more SYN, it will fail. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From richard at weickelt.de Sat May 26 23:20:17 2018 From: richard at weickelt.de (Richard Weickelt) Date: Sat, 26 May 2018 23:20:17 +0200 Subject: [Development] QTBUG-43096 - QML instantiation performance decadence In-Reply-To: <3631708.1e7lxq5fpB@tjmaciei-mobl1> References: <1843949.dfA5k42zuE@tjmaciei-mobl1> <3631708.1e7lxq5fpB@tjmaciei-mobl1> Message-ID: <3a4f0fe2-346e-f201-2bca-79413fc1ae57@weickelt.de> > There are JavaScript interpreters for microcontrollers (see Duktape and > Jerryscript). But those are designed to run on tens of *kilobytes* of RAM. You > can't compare them to Qt, as they have special limitations to run that way. > For example, neither implementation supports "eval". I wonder if those tiny devices with tens or even hundreds of kilobytes RAM running Jerryscript would be already sufficient for a "QML light". I am not talking about QML GUIs, but rather simple sensor/actor applications consisting of few state machines and using one of the 1001 available communication stacks. MCU vendors usually offer and praise their own C SDKs, but my experience so far is that it can take a very long time to achieve even simple applications and one has to write either a lot of boilerplate code or use fragile and obscure tools. QML has some powerful features that feel like a quantum leap when compared to C: - property bindings - easy component composition - signals, signal handlers - ... If we had nice QML modules like Qt Bluetooth and Qt Sensors available for tiny devices, I believe that application development would become very simple and convenient. I am making a few assumptions here: - the whole application structure would be static, no dynamic loading of components - bindings are resolved at build-time. - the application would be compiled to bytecode on the host before being flashed onto the target - the back-end of those modules would most likely not be Qt - it would be possible to deduce, which features the QML application actually uses so that unused functionality can be dropped at build-time. I would be interested in other opinions. Maybe I am on a completely wrong track here. Richard From thiago.macieira at intel.com Sun May 27 00:25:01 2018 From: thiago.macieira at intel.com (Thiago Macieira) Date: Sat, 26 May 2018 19:25:01 -0300 Subject: [Development] QTBUG-43096 - QML instantiation performance decadence In-Reply-To: <3a4f0fe2-346e-f201-2bca-79413fc1ae57@weickelt.de> References: <3631708.1e7lxq5fpB@tjmaciei-mobl1> <3a4f0fe2-346e-f201-2bca-79413fc1ae57@weickelt.de> Message-ID: <6341429.VGnudhuMqD@tjmaciei-mobl1> On Saturday, 26 May 2018 18:20:17 -03 Richard Weickelt wrote: > > There are JavaScript interpreters for microcontrollers (see Duktape and > > Jerryscript). But those are designed to run on tens of *kilobytes* of RAM. > > You can't compare them to Qt, as they have special limitations to run > > that way. For example, neither implementation supports "eval". > > I wonder if those tiny devices with tens or even hundreds of kilobytes RAM > running Jerryscript would be already sufficient for a "QML light". I am not > talking about QML GUIs, but rather simple sensor/actor applications > consisting of few state machines and using one of the 1001 available > communication stacks. It would be interesting to explore. QML is nothing but a property-binding and object-instantiating syntax on top of JS, so it could be done. > MCU vendors usually offer and praise their own C SDKs, but my experience so > far is that it can take a very long time to achieve even simple applications > and one has to write either a lot of boilerplate code or use fragile and > obscure tools. Hence the use of JS. See https://elinux.org/images/f/ff/JavaScript_Meets_Zephyr.pdf Disclaimer: Sakari is a colleague of mine. And some of the folks at TQtC may remember him from Nokia times, as he worked on Maemo/MeeGo. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From d3faultdotxbe at gmail.com Sun May 27 20:43:31 2018 From: d3faultdotxbe at gmail.com (d3fault) Date: Sun, 27 May 2018 11:43:31 -0700 Subject: [Development] Are there plans to decouple QML from JavaScript? Message-ID: Now that QML can be precompiled and has a software renderer, I see it as *almost* usable. One final piece missing to get me on board: decouple qml from js. to re-state old arguments: -I already have all of C/C++ at my disposal, JS buys me nothing -If I don't use it, I shouldn't have to pay for it >From a C++ perspective, Bindings are really the only interesting feature that JS brings, but those don't require JS! JS was just a lazy/quick/hacky/EXPENSIVE way to get Bindings in QML. A much better approach would be to parse the Bindings using libclang [0] and generate regular Qt/C++ code to support the bindings [1]. That being said, I don't even need bindings and am perfectly content using signals/slots to update the GUI. What if there was a per-project config, say "QML_NoJS", that when enabled, causes compilation to error out if there is any JS detected? Qt Lite project would additionally need to support compiling QML without JS, but that's obvious. d3fault [0] - https://llvm.org/docs/tutorial/OCamlLangImpl1.html [1] - https://forum.qt.io/topic/16009/does-qt-need-a-modern-c-gui-api/132?page=4 From jani.heikkinen at qt.io Mon May 28 10:58:23 2018 From: jani.heikkinen at qt.io (Jani Heikkinen) Date: Mon, 28 May 2018 08:58:23 +0000 Subject: [Development] MAINTAINERS, Your actions needed: Qt 5.9.6 changes files Message-ID: Hi! Initial ones here: https://codereview.qt-project.org/#/q/message:%22Add+changes+file+for+Qt+5.9.6%22,n,z Please do needed modifications now & get approval. We are targeting to get Qt 5.9.6 out at the beginning of June so we need to get all these in asap br, Jani From Karsten.Heimrich at qt.io Mon May 28 12:19:28 2018 From: Karsten.Heimrich at qt.io (Karsten Heimrich) Date: Mon, 28 May 2018 10:19:28 +0000 Subject: [Development] =?windows-1252?q?Changing_maintainer-ship_for_Qt_As?= =?windows-1252?q?sistant=2C_Qt_Help_and_Qt_Creator=92s_help_Integration?= Message-ID: Hi, officially I'm still  the maintainer of Qt Assistant & Qt Help and Qt Creator’s help Integration. Since I actually no longer working on this code, I propose Jaroslaw  Kobus as the new maintainer. Jarek has done a lot of good work on these  modules recently and has been a very long time with Qt in general. Regards, Karsten Karsten Heimrich, Software engineer | The Qt Company The Qt Company GmbH, Rudower Chaussee 13, D-12489 Berlin Geschäftsführer: Mika Pälsi, Juha Varelius, Mika Harjuaho. Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 144331 B From Eike.Ziller at qt.io Mon May 28 12:33:44 2018 From: Eike.Ziller at qt.io (Eike Ziller) Date: Mon, 28 May 2018 10:33:44 +0000 Subject: [Development] =?utf-8?q?Changing_maintainer-ship_for_Qt_Assistan?= =?utf-8?q?t=2C_Qt_Help_and_Qt_Creator=E2=80=99s_help_Integration?= In-Reply-To: References: Message-ID: +1 ! > On 28. May 2018, at 12:19, Karsten Heimrich wrote: > > Hi, > > officially I'm still the maintainer of Qt Assistant & Qt Help and Qt Creator’s help Integration. Since I actually no longer working on this code, I propose Jaroslaw Kobus as the new maintainer. Jarek has done a lot of good work on these modules recently and has been a very long time with Qt in general. > > > Regards, > Karsten > > Karsten Heimrich, Software engineer | The Qt Company > > The Qt Company GmbH, Rudower Chaussee 13, D-12489 Berlin > Geschäftsführer: Mika Pälsi, Juha Varelius, Mika Harjuaho. Sitz der > Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, > HRB 144331 B > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development -- Eike Ziller Principal Software Engineer The Qt Company GmbH Rudower Chaussee 13 D-12489 Berlin eike.ziller at 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 From Tobias.Hunger at qt.io Mon May 28 12:41:21 2018 From: Tobias.Hunger at qt.io (Tobias Hunger) Date: Mon, 28 May 2018 10:41:21 +0000 Subject: [Development] =?windows-1252?q?Changing_maintainer-ship_for_Qt_A?= =?windows-1252?q?ssistant=2C_Qt_Help_and_Qt_Creator=92s_help_Integration?= In-Reply-To: References: Message-ID: > [...] I propose Jaroslaw Kobus as the new maintainer. +1 from me for that. Best Regards, Tobisa -- Tobias Hunger, Senior Software Engineer | The Qt Company The Qt Company GmbH, Rudower Chaussee 13, D-12489 Berlin Geschäftsführer: Mika Pälsi, Juha Varelius, Mika Harjuaho. Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 144331 B From christian.kandeler at qt.io Mon May 28 12:53:21 2018 From: christian.kandeler at qt.io (Christian Kandeler) Date: Mon, 28 May 2018 12:53:21 +0200 Subject: [Development] =?utf-8?q?Changing_maintainer-ship_for_Qt_Assistan?= =?utf-8?q?t=2C_Qt_Help_and_Qt_Creator=E2=80=99s_help_Integration?= In-Reply-To: References: Message-ID: <20180528125321.5442344e@ckandeler-archlinux> On Mon, 28 May 2018 10:19:28 +0000 Karsten Heimrich wrote: > officially I'm still  the maintainer of Qt Assistant & Qt Help and Qt Creator’s help Integration. Since I actually no longer working on this code, I propose Jaroslaw  Kobus as the new maintainer. Jarek has done a lot of good work on these  modules recently and has been a very long time with Qt in general. +1 Christian From jedrzej.nowacki at qt.io Mon May 28 14:04:01 2018 From: jedrzej.nowacki at qt.io (Jedrzej Nowacki) Date: Mon, 28 May 2018 14:04:01 +0200 Subject: [Development] QTBUG-43096 - QML instantiation performance decadence In-Reply-To: References: Message-ID: <2481229.Ks2MVOS0cu@43> On Saturday, May 26, 2018 2:05:38 PM CEST Simon Hausmann wrote: > Jędrzej had a beautiful proof of concept at some point for QObject to > combine the object and d-pointer allocation into one. Old times :-) For completeness: https://codereview.qt-project.org/#/q/status:deferred +project:qt/qtbase+branch:dev+topic:qobject_operator_new,n,z From aapo.keskimolo at qt.io Tue May 29 08:14:08 2018 From: aapo.keskimolo at qt.io (=?utf-8?B?QWFwbyBLZXNraW3DtmzDtg==?=) Date: Tue, 29 May 2018 06:14:08 +0000 Subject: [Development] Coin maintenance notification In-Reply-To: References: Message-ID: Coin production will be updated Tue May 29 09:30-10:00 EEST 2018. See attachment for related changes. Kind regards/Ystävällisin terveisin, Aapo Keskimölö -------------- next part -------------- A non-text attachment was scrubbed... Name: product_baseline_20180529.log Type: application/octet-stream Size: 32708 bytes Desc: product_baseline_20180529.log URL: From jani.heikkinen at qt.io Thu May 31 06:55:54 2018 From: jani.heikkinen at qt.io (Jani Heikkinen) Date: Thu, 31 May 2018 04:55:54 +0000 Subject: [Development] [Interest] Maintenance Tool network error (OSX) In-Reply-To: References: <9fd5706f-7887-b26c-3ae5-0f7e31751c60@tungware.se> , Message-ID: Hi! This issue should be fixed now. It would be better to report these kind of issues to Jira, to our internal release team ml (qt.team.releases at qt.io) or to development ML (development at qt-project.org) in the future to make sure we will notice the issue immediately. br, Jani ________________________________________ From: Jason H Sent: Wednesday, May 30, 2018 6:26 PM To: Jani Heikkinen Cc: interest at qt-project.org; fromqt at tungware.se Subject: Re: [Interest] Maintenance Tool network error (OSX) Sure. For next time, is there a contact for similar issues we should use? Maybe the developer list? > Sent: Wednesday, May 30, 2018 at 1:54 AM > From: "Jani Heikkinen" > To: "interest at qt-project.org" , "fromqt at tungware.se" > Subject: Re: [Interest] Maintenance Tool network error (OSX) > > Hi all, > > Thanks for notifying this. There seems to be some issue and some release content is missing from download.qt.io. We will study & fix the issue as soon as possible > > br, > Jani > ________________________________________ > From: Interest on behalf of Henry Skoglund > Sent: Tuesday, May 29, 2018 7:18 PM > To: interest at qt-project.org > Subject: Re: [Interest] Maintenance Tool network error (OSX) > > I'm getting it too. > > (No Qt installed before, downloaded Online installer: ok, login: ok, but > cannot install any version of Qt today on my brand new Mac. > > Also get this error just now when I tried on a new Windows 10 PC (se > picture #2). > > No Qt today :-( > > Rgrds Henry > > On 2018-05-29 17:18, Jason H wrote: > > Not sure if anyone else is getting this... > > > > > > > > _______________________________________________ > > Interest mailing list > > Interest at qt-project.org > > http://lists.qt-project.org/mailman/listinfo/interest > > > > _______________________________________________ > Interest mailing list > Interest at qt-project.org > http://lists.qt-project.org/mailman/listinfo/interest > From Uwe.Rathmann at tigertal.de Thu May 31 09:21:00 2018 From: Uwe.Rathmann at tigertal.de (Uwe Rathmann) Date: Thu, 31 May 2018 07:21:00 +0000 (UTC) Subject: [Development] QTBUG-43096 - QML instantiation performance decadence References: <1527251405.2829505.1385058224.053D963E@webmail.messagingengine.com> Message-ID: Hi Simon, > I ran benchmarks comparing a release build of 5.12 against 5.1.1 and ran > the benchmark mentioned in the task, where Qt 5.12 came out in average > faster by a factor of 4. Christophers comment in the JIRA ticket raises some questions concerning the correctness of those benchmarks. Would you be so kind to clarify how far we can trust in these numbers ? Uwe From chris.adams at qinetic.com.au Thu May 31 09:48:53 2018 From: chris.adams at qinetic.com.au (Chris Adams) Date: Thu, 31 May 2018 17:48:53 +1000 Subject: [Development] QTBUG-43096 - QML instantiation performance decadence In-Reply-To: References: <1527251405.2829505.1385058224.053D963E@webmail.messagingengine.com> Message-ID: On Thu, May 31, 2018 at 5:21 PM, Uwe Rathmann wrote: > Hi Simon, > >> I ran benchmarks comparing a release build of 5.12 against 5.1.1 and ran >> the benchmark mentioned in the task, where Qt 5.12 came out in average >> faster by a factor of 4. > > Christophers comment in the JIRA ticket raises some questions concerning > the correctness of those benchmarks. > > Would you be so kind to clarify how far we can trust in these numbers ? I did have a couple of questions about that particular benchmark result, but that doesn't mean that the conclusion is incorrect. It's important to note that the issue may lie in the original numbers, as the library metrics test previously used some hand-rolled methods to discard outliers and perform an average, and worked on wall time rather than cpu ticks - a method which may very well have been wrong (and that would be entirely my fault). Also, it is worth pointing out that recently a considerable effort has been made to improve the benchmarking of all stages of QtQuick applications (from the JS side of things, to the QML compiler side of things, to the scene graph side of things), as the grafana and qmlbench etc tracking proves. Performance regressions are now being caught, and performance metrics are easily visible, thanks to those efforts, and that is definitely have a very positive effect on performance outcomes for everyone. FWIW I am certain that the QML engine in Qt 5.12 will indeed perform better than it did in Qt 5.1 days (or any other version of Qt) because the people working most closely with the engine and the people working most closely with QtQuick both believe it to be so, and I trust their judgement. Best regards, Chris. From Simo.Falt at qt.io Thu May 31 13:43:12 2018 From: Simo.Falt at qt.io (=?utf-8?B?U2ltbyBGw6RsdA==?=) Date: Thu, 31 May 2018 11:43:12 +0000 Subject: [Development] Coin maintenance notification Message-ID: <12BC19D6-6CC0-4ED9-B757-7E21034DF3FB@qt.io> The update introduced some unexpected “features”, which were reverted/fixed. In addition to that, we suffered from infra related problems today. Those also should be fixed by now. Due to issues above, CI is a bit busy atm, so please be patient. Simo On 29/05/2018, 9.14, "Development on behalf of Aapo Keskimölö" wrote: Coin production will be updated Tue May 29 09:30-10:00 EEST 2018. See attachment for related changes. Kind regards/Ystävällisin terveisin, Aapo Keskimölö From alexander.blasche at qt.io Thu May 31 14:42:51 2018 From: alexander.blasche at qt.io (Alex Blasche) Date: Thu, 31 May 2018 12:42:51 +0000 Subject: [Development] Jira changes going forward In-Reply-To: References: Message-ID: This review has come to a conclusion. Based on reviews the major points have settled. The highlights of the changes are: - Internal Qt company requirements management will shift to public projects - Renaming and reordering of components (breaks existing filters) - Additional fields for Jira issues - Automatic closure/check of long pending "Need more Info" bugs where the bug reporter fails to provide information Implementation of those changes will happen during June. -- Alex ________________________________________ From: Development on behalf of Alex Blasche Sent: Wednesday, 2 May 2018 2:18:54 PM To: development at qt-project.org Subject: [Development] Jira changes going forward Hi, there are quite a few changes to Jira on my todo list. Some of them result from some internal TQtC process changes (related to public requirements mgmt) and others were put forward by individuals with a keen interest in improving things (thank you for that). Unfortunately some of proposals will break existing setups (especially filters). Since there are a lot of changes I chose to use gerrit for the discussion. A long mail is not able to provide the means to update and review the latest consensus. Please have a look at https://codereview.qt-project.org/#/c/225694/ The patch is not intended to be merged. It merely exists to facilitate the community discussion. However I might document some of the outcomes (especially process outcomes) somewhere later on. Thank you for your feedback. -- Alex _______________________________________________ Development mailing list Development at qt-project.org http://lists.qt-project.org/mailman/listinfo/development From jhihn at gmx.com Thu May 31 17:12:05 2018 From: jhihn at gmx.com (Jason H) Date: Thu, 31 May 2018 17:12:05 +0200 Subject: [Development] [Interest] Maintenance Tool network error (OSX) In-Reply-To: References: <9fd5706f-7887-b26c-3ae5-0f7e31751c60@tungware.se> Message-ID: Confirmed, I was able to install 5.11 :-) > Sent: Thursday, May 31, 2018 at 12:55 AM > From: "Jani Heikkinen" > To: "Jason H" , "development at qt-project.org" > Cc: "interest at qt-project.org" , "fromqt at tungware.se" > Subject: Re: [Interest] Maintenance Tool network error (OSX) > > Hi! > This issue should be fixed now. > > It would be better to report these kind of issues to Jira, to our internal release team ml (qt.team.releases at qt.io) or to development ML (development at qt-project.org) in the future to make sure we will notice the issue immediately. > > br, > Jani > ________________________________________ > From: Jason H > Sent: Wednesday, May 30, 2018 6:26 PM > To: Jani Heikkinen > Cc: interest at qt-project.org; fromqt at tungware.se > Subject: Re: [Interest] Maintenance Tool network error (OSX) > > Sure. For next time, is there a contact for similar issues we should use? Maybe the developer list? > > > > Sent: Wednesday, May 30, 2018 at 1:54 AM > > From: "Jani Heikkinen" > > To: "interest at qt-project.org" , "fromqt at tungware.se" > > Subject: Re: [Interest] Maintenance Tool network error (OSX) > > > > Hi all, > > > > Thanks for notifying this. There seems to be some issue and some release content is missing from download.qt.io. We will study & fix the issue as soon as possible > > > > br, > > Jani > > ________________________________________ > > From: Interest on behalf of Henry Skoglund > > Sent: Tuesday, May 29, 2018 7:18 PM > > To: interest at qt-project.org > > Subject: Re: [Interest] Maintenance Tool network error (OSX) > > > > I'm getting it too. > > > > (No Qt installed before, downloaded Online installer: ok, login: ok, but > > cannot install any version of Qt today on my brand new Mac. > > > > Also get this error just now when I tried on a new Windows 10 PC (se > > picture #2). > > > > No Qt today :-( > > > > Rgrds Henry > > > > On 2018-05-29 17:18, Jason H wrote: > > > Not sure if anyone else is getting this... > > > > > > > > > > > > _______________________________________________ > > > Interest mailing list > > > Interest at qt-project.org > > > http://lists.qt-project.org/mailman/listinfo/interest > > > > > > > _______________________________________________ > > Interest mailing list > > Interest at qt-project.org > > http://lists.qt-project.org/mailman/listinfo/interest > > > From robin.burchell at crimson.no Thu May 31 22:38:38 2018 From: robin.burchell at crimson.no (Robin Burchell) Date: Thu, 31 May 2018 22:38:38 +0200 Subject: [Development] Coin maintenance notification In-Reply-To: <12BC19D6-6CC0-4ED9-B757-7E21034DF3FB@qt.io> References: <12BC19D6-6CC0-4ED9-B757-7E21034DF3FB@qt.io> Message-ID: <1527799118.939702.1392261880.0CABD51B@webmail.messagingengine.com> https://testresults.qt.io/coin/ shows the last successful integration at ~4pm, and the integrating list is full again: https://codereview.qt-project.org/#/q/status:integrating,n,z So I guess it's not fixed, or something else broke? -- Robin Burchell robin at crimson.no On Thu, May 31, 2018, at 1:43 PM, Simo Fält wrote: > The update introduced some unexpected “features”, which were reverted/ > fixed. > In addition to that, we suffered from infra related problems today. > Those also should be fixed by now. > > Due to issues above, CI is a bit busy atm, so please be patient. > > Simo > > On 29/05/2018, 9.14, "Development on behalf of Aapo Keskimölö" > aapo.keskimolo at qt.io> wrote: > > Coin production will be updated Tue May 29 09:30-10:00 EEST 2018. > > See attachment for related changes. > > > Kind regards/Ystävällisin terveisin, > Aapo Keskimölö > > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development From Simo.Falt at qt.io Thu May 31 23:23:26 2018 From: Simo.Falt at qt.io (=?utf-8?B?U2ltbyBGw6RsdA==?=) Date: Thu, 31 May 2018 21:23:26 +0000 Subject: [Development] Coin maintenance notification In-Reply-To: <1527799118.939702.1392261880.0CABD51B@webmail.messagingengine.com> References: <12BC19D6-6CC0-4ED9-B757-7E21034DF3FB@qt.io> <1527799118.939702.1392261880.0CABD51B@webmail.messagingengine.com> Message-ID: <4016D5E0-4B9C-4A74-8FF2-B5BB9253A472@qt.io> You are right. It seems that the connection to service in testresults.qt.io keeps giving up on us. I just restarted coin, but I don’t know how to fix the root cause. We have to investigate this more tomorrow morning. Simo On 31/05/2018, 23.38, "Development on behalf of Robin Burchell" wrote: https://testresults.qt.io/coin/ shows the last successful integration at ~4pm, and the integrating list is full again: https://codereview.qt-project.org/#/q/status:integrating,n,z So I guess it's not fixed, or something else broke? -- Robin Burchell robin at crimson.no On Thu, May 31, 2018, at 1:43 PM, Simo Fält wrote: > The update introduced some unexpected “features”, which were reverted/ > fixed. > In addition to that, we suffered from infra related problems today. > Those also should be fixed by now. > > Due to issues above, CI is a bit busy atm, so please be patient. > > Simo > > On 29/05/2018, 9.14, "Development on behalf of Aapo Keskimölö" > aapo.keskimolo at qt.io> wrote: > > Coin production will be updated Tue May 29 09:30-10:00 EEST 2018. > > See attachment for related changes. > > > Kind regards/Ystävällisin terveisin, > Aapo Keskimölö > > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development _______________________________________________ Development mailing list Development at qt-project.org http://lists.qt-project.org/mailman/listinfo/development