From mandeepsandhu.chd at gmail.com  Tue Aug  1 00:35:15 2017
From: mandeepsandhu.chd at gmail.com (Mandeep Sandhu)
Date: Mon, 31 Jul 2017 15:35:15 -0700
Subject: [Development] implicit sharing and iterators in qt containers
In-Reply-To: <1920508.xjn6X5LUKW@tjmaciei-mobl1>
References: <CAC+QLdTA0N_fQYQGcuwaXyRYDmikG+p0w2iRiXoGH947L+wqCw@mail.gmail.com>
	<4432140.ttfqaDjMO5@tjmaciei-mobl1>
	<CAC+QLdSHt9QcYk0Ue95J+HnU9Ejc4X7WjL+dpXVmSc0q4YBhpA@mail.gmail.com>
	<1920508.xjn6X5LUKW@tjmaciei-mobl1>
Message-ID: <CAC+QLdS3gL13sU8=1d248GyYtH=TQO0RSOWS-xV9QMZ6RWK9aA@mail.gmail.com>

On Mon, Jul 31, 2017 at 2:57 PM, Thiago Macieira <thiago.macieira at intel.com>
wrote:

> On segunda-feira, 31 de julho de 2017 14:36:59 PDT Mandeep Sandhu wrote:
> > > I'd expect to be able to use keys that do not define qHash or qLess.
> >
> > Why?
>
> My type key type may be or contain an opaque non-orderable type, which
> would
> make implementing both qHash and qLess impossible. Right now, if you have
> such
> a key type, you can't use QMap or QHash. Example type: QVariant.
>
> Therefore, for this new container to add something we currently do not
> have,
> it MUST NOT require either function.
>

Okay, I got your point now. Although wouldn't the user be expecting this,
given that other containers (STL containers, python dicts) also impose the
same constraints? Isn't it a fair trade-off for faster lookup?


> > > Search would be O(n). So be it.
> >
> > Well it wouldn't be much of a "map" then, would it?
>
> Sure it would. There's nothing that requires associative containers to have
> search times better than O(n). It just happens that both std::map and QMap
> implements them at O(log n).


Well, if fast lookup isn't necessary, then I guess such a "container" is
not really needed, and one can simply implement it using a
QLinkedList<QPair<Key key, Value value>> (maybe with some added
restrictions).

-mandeep


>

> --
> 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: <http://lists.qt-project.org/pipermail/development/attachments/20170731/3ef87ade/attachment.html>

From mandeepsandhu.chd at gmail.com  Tue Aug  1 00:38:35 2017
From: mandeepsandhu.chd at gmail.com (Mandeep Sandhu)
Date: Mon, 31 Jul 2017 15:38:35 -0700
Subject: [Development] implicit sharing and iterators in qt containers
In-Reply-To: <68429c0d-6d44-9bff-9642-26bf9c96e685@gmail.com>
References: <CAC+QLdTA0N_fQYQGcuwaXyRYDmikG+p0w2iRiXoGH947L+wqCw@mail.gmail.com>
	<1932821.jQ6KmOpCoi@tjmaciei-mobl1>
	<CAC+QLdTAXwpBsOJGbXWH5vFnEq+hKJ+4Y0EncFqfPkhA2hSktA@mail.gmail.com>
	<4432140.ttfqaDjMO5@tjmaciei-mobl1>
	<CAC+QLdSHt9QcYk0Ue95J+HnU9Ejc4X7WjL+dpXVmSc0q4YBhpA@mail.gmail.com>
	<68429c0d-6d44-9bff-9642-26bf9c96e685@gmail.com>
Message-ID: <CAC+QLdSodU-vhqZJMeYSsLgtFLrQQSdwN8EQB+pfGU+n3qfQ3Q@mail.gmail.com>

>
>
> It's still a key-value store in which items are retrieved by key, which
> is sort of the definition of a "map". It just has inefficient look-up.
>

Right. Since this (fast lookup) is so ubiquitous amongst map like
containers, I thought this was expected from all associative containers.

If not, as I said before, a QLinkedList<QPair<Key key, Value value>> with
some restrictions should suffice.

-mandeep



>
> --
> Matthew
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20170731/e6cb3347/attachment.html>

From thiago.macieira at intel.com  Tue Aug  1 01:02:55 2017
From: thiago.macieira at intel.com (Thiago Macieira)
Date: Mon, 31 Jul 2017 16:02:55 -0700
Subject: [Development] implicit sharing and iterators in qt containers
In-Reply-To: <CAC+QLdS3gL13sU8=1d248GyYtH=TQO0RSOWS-xV9QMZ6RWK9aA@mail.gmail.com>
References: <CAC+QLdTA0N_fQYQGcuwaXyRYDmikG+p0w2iRiXoGH947L+wqCw@mail.gmail.com>
	<1920508.xjn6X5LUKW@tjmaciei-mobl1>
	<CAC+QLdS3gL13sU8=1d248GyYtH=TQO0RSOWS-xV9QMZ6RWK9aA@mail.gmail.com>
Message-ID: <4784816.sgWyzqg4dN@tjmaciei-mobl1>

On segunda-feira, 31 de julho de 2017 15:35:15 PDT Mandeep Sandhu wrote:
> Well, if fast lookup isn't necessary, then I guess such a "container" is
> not really needed, and one can simply implement it using a
> QLinkedList<QPair<Key key, Value value>> (maybe with some added
> restrictions).

And that's what it should be (though QVector, not QLinkedList) and simply add 
the convenience functions for iteration and searching by key.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center



From philippeb8 at gmail.com  Tue Aug  1 04:11:38 2017
From: philippeb8 at gmail.com (Phil Bouchard)
Date: Mon, 31 Jul 2017 22:11:38 -0400
Subject: [Development] [BB++] 17 minutes long documentary
Message-ID: <oloo0k$du5$2@blaine.gmane.org>

Last call here because like I promised, here's a 17 minutes long 
documentary on BB++ which now shows its internals:
https://youtu.be/GrNDYWyasxg


Regards,
-Phil



From alexander.blasche at qt.io  Tue Aug  1 08:37:33 2017
From: alexander.blasche at qt.io (Alex Blasche)
Date: Tue, 1 Aug 2017 06:37:33 +0000
Subject: [Development] Nominating Denis Shienkov for Approver status
In-Reply-To: <239acd2f-188f-b018-1b68-245e04c1e9b6@iseg-hv.de>
References: <239acd2f-188f-b018-1b68-245e04c1e9b6@iseg-hv.de>
Message-ID: <DB4PR02MB02854477CD70C2387AE448A1E7B30@DB4PR02MB0285.eurprd02.prod.outlook.com>

Congratulations to Denis. Approver rights have been granted.

--
Alex


> -----Original Message-----
> From: Development [mailto:development-
> bounces+alexander.blasche=qt.io at qt-project.org] On Behalf Of André
> Hartmann
> Sent: Thursday, 6 July 2017 08:36
> To: development at qt-project.org; qt-creator at qt-project.org
> Subject: [Development] Nominating Denis Shienkov for Approver status
> 
> I'd like to propose the nomination of Denis Shienkov for Approver status.
> 
> Denis has been the maintainer of QtSerialPort for a long time now.
> He also formed the architecture of QtSerialBus and provided several CAN plugins
> there. He further contributes to other parts of Qt and QtCreator and is actively
> reviewing other changes (for example he has constructively improved a lot of
> my changes to QtSerialBus).
> 
> This is his own Gerrit dashboard:
> 
> https://codereview.qt-
> project.org/#/q/owner:%22Denis+Shienkov+%253Cdenis.shienkov%2540gmail.c
> om%253E%22,n,z
> 
> And these are his reviews:
> 
> https://codereview.qt-
> project.org/#/q/reviewer:%22Denis+Shienkov+%253Cdenis.shienkov%2540gmai
> l.com%253E%22,n,z
> 
> Best regards,
> André
> _______________________________________________
> Development mailing list
> Development at qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development

From alexander.blasche at qt.io  Tue Aug  1 08:38:57 2017
From: alexander.blasche at qt.io (Alex Blasche)
Date: Tue, 1 Aug 2017 06:38:57 +0000
Subject: [Development] Nominating Viktor Engelmann for Approver Status
In-Reply-To: <VI1PR02MB10069C4343C6DFC6042DD8508CAE0@VI1PR02MB1006.eurprd02.prod.outlook.com>
References: <VI1PR02MB10069C4343C6DFC6042DD8508CAE0@VI1PR02MB1006.eurprd02.prod.outlook.com>
Message-ID: <DB4PR02MB02853BA54BDDA687BF370F45E7B30@DB4PR02MB0285.eurprd02.prod.outlook.com>

Congratulations to Viktor. Approver rights have been granted.

--
Alex

> -----Original Message-----
> From: Development [mailto:development-
> bounces+alexander.blasche=qt.io at qt-project.org] On Behalf Of Simon
> Hausmann
> Sent: Tuesday, 11 July 2017 13:25
> To: development at qt-project.org
> Subject: [Development] Nominating Viktor Engelmann for Approver Status
> 
> Hi,
> 
> 
> 
> 
> I'd like to propose Viktor for approver status. Since August last year he's been
> contributing to QtWebEngine full-time. Based on my experience talking to him
> and working with him, I trust him to review changes thoroughly and approve or
> reject changes responsively.
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> Simon



From alexander.blasche at qt.io  Tue Aug  1 08:41:15 2017
From: alexander.blasche at qt.io (Alex Blasche)
Date: Tue, 1 Aug 2017 06:41:15 +0000
Subject: [Development] Nominating Jesus Fernandez for Approver status
In-Reply-To: <HE1PR0202MB2588894AD75E0695C59CBA1191AE0@HE1PR0202MB2588.eurprd02.prod.outlook.com>
References: <HE1PR0202MB2588894AD75E0695C59CBA1191AE0@HE1PR0202MB2588.eurprd02.prod.outlook.com>
Message-ID: <DB4PR02MB02852FFC351CBB75BD03E082E7B30@DB4PR02MB0285.eurprd02.prod.outlook.com>

Congratulations to Jesus. Approver rights have been set.

--
Alex

> -----Original Message-----
> From: Development [mailto:development-
> bounces+alexander.blasche=qt.io at qt-project.org] On Behalf Of Timur
> Pocheptsov
> Sent: Tuesday, 11 July 2017 14:07
> To: Qt development mailing list <development at qt-project.org>
> Subject: [Development] Nominating Jesus Fernandez for Approver status
> 
> I'd like to nominate Jesus Fernandez for Approver status. Among other things
> Jesus is the author and the maintainer
> 
> of qtnetworkauth module, he is actively contributing to qtcore, qtnetwork,
> qtwebsockets, qsql, etc. He is also
> 
> participating in the development of the WebGL QPA plugin.
> 
> 
> 
> 
> This is his Gerrit dashboard:
> 
> 
> 
> 
> https://codereview.qt-
> project.org/#/q/owner:%22Jesus+Fernandez%22+status:merged,n,z
> 
> 
> 
> 
> Best regards,
> 
>     Timur.
> 
> 
> 
> 



From jani.heikkinen at qt.io  Tue Aug  1 08:55:28 2017
From: jani.heikkinen at qt.io (Jani Heikkinen)
Date: Tue, 1 Aug 2017 06:55:28 +0000
Subject: [Development] Qt 5.10 schedule etc
Message-ID: <HE1PR02MB3132DFFBCCFE0E6C6061CC579DB30@HE1PR02MB3132.eurprd02.prod.outlook.com>

Hi all,
Kindly reminder: According to schedule we should have Qt 5.10 feature freeze after a week, see https://wiki.qt.io/Qt_5.10_Release. So it is time to do remaining finalizations to 5.10 new features now and focus to bug fixing after that. Please fill new features page now as well (https://wiki.qt.io/New_Features_in_Qt_5.10); it seems to be quite empty at the moment.

And we should start soft branching today. But as Frederik informed yesterday we are planning to do some changes to coin infrastructure during this week (see http://lists.qt-project.org/pipermail/development/2017-July/030596.html). So let's postpone the start of soft branching a bit and do it after coin infra changes are in & working. Doing one more branch just now makes these coin changes more difficult & most probably causes more delays in the future. 

So the plan with 5.10 is following:
1. Let's keep the agreed ff as it is (8.8.2017)
2. Get first 5.10 binary snapshot from 'dev' out as soon as possible
3. Start soft branching (from 'dev' to '5.10') immediately after coin infra changes are in & every branch ('5.6', 5.9' & 'dev') is working ok with infra changes
4. Finalize branching (~ a week from soft branching)
5. Release Qt 5.10 alpha as soon as possible after the branching. We should be able to do this quite quickly; As usual Alpha will be src packages only and we can already create needed ones from 'dev'.
   * Most probably we should be able to deliver binary snapshot with alpha as well. If not just at same time then quite soon after the release...

br,
Jani




From denis.shienkov at gmail.com  Tue Aug  1 08:54:02 2017
From: denis.shienkov at gmail.com (Denis Shienkov)
Date: Tue, 1 Aug 2017 09:54:02 +0300
Subject: [Development] Nominating Denis Shienkov for Approver status
In-Reply-To: <DB4PR02MB02854477CD70C2387AE448A1E7B30@DB4PR02MB0285.eurprd02.prod.outlook.com>
References: <239acd2f-188f-b018-1b68-245e04c1e9b6@iseg-hv.de>
	<DB4PR02MB02854477CD70C2387AE448A1E7B30@DB4PR02MB0285.eurprd02.prod.outlook.com>
Message-ID: <f997050e-4bec-c757-596e-a403802982ec@gmail.com>

WOW, thanks... :)

Q: Approver of what?

BR, Denis.


01.08.2017 9:37, Alex Blasche пишет:
> Congratulations to Denis. Approver rights have been granted.
>
> --
> Alex
>
>
>> -----Original Message-----
>> From: Development [mailto:development-
>> bounces+alexander.blasche=qt.io at qt-project.org] On Behalf Of André
>> Hartmann
>> Sent: Thursday, 6 July 2017 08:36
>> To: development at qt-project.org; qt-creator at qt-project.org
>> Subject: [Development] Nominating Denis Shienkov for Approver status
>>
>> I'd like to propose the nomination of Denis Shienkov for Approver status.
>>
>> Denis has been the maintainer of QtSerialPort for a long time now.
>> He also formed the architecture of QtSerialBus and provided several CAN plugins
>> there. He further contributes to other parts of Qt and QtCreator and is actively
>> reviewing other changes (for example he has constructively improved a lot of
>> my changes to QtSerialBus).
>>
>> This is his own Gerrit dashboard:
>>
>> https://codereview.qt-
>> project.org/#/q/owner:%22Denis+Shienkov+%253Cdenis.shienkov%2540gmail.c
>> om%253E%22,n,z
>>
>> And these are his reviews:
>>
>> https://codereview.qt-
>> project.org/#/q/reviewer:%22Denis+Shienkov+%253Cdenis.shienkov%2540gmai
>> l.com%253E%22,n,z
>>
>> Best regards,
>> André
>> _______________________________________________
>> 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 Aug  1 09:20:33 2017
From: thiago.macieira at intel.com (Thiago Macieira)
Date: Tue, 01 Aug 2017 00:20:33 -0700
Subject: [Development] Nominating Denis Shienkov for Approver status
In-Reply-To: <f997050e-4bec-c757-596e-a403802982ec@gmail.com>
References: <239acd2f-188f-b018-1b68-245e04c1e9b6@iseg-hv.de>
	<DB4PR02MB02854477CD70C2387AE448A1E7B30@DB4PR02MB0285.eurprd02.prod.outlook.com>
	<f997050e-4bec-c757-596e-a403802982ec@gmail.com>
Message-ID: <3882866.DtbGhIb7l1@tjmaciei-mobl1>

On segunda-feira, 31 de julho de 2017 23:54:02 PDT Denis Shienkov wrote:
> WOW, thanks... :)
> 
> Q: Approver of what?

In the Qt Project. You get the rights throughout, but you're expected to only 
give +2 when you know what you're doing.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center



From thiago.macieira at intel.com  Tue Aug  1 09:18:18 2017
From: thiago.macieira at intel.com (Thiago Macieira)
Date: Tue, 01 Aug 2017 00:18:18 -0700
Subject: [Development] Qt 5.10 schedule etc
In-Reply-To: <HE1PR02MB3132DFFBCCFE0E6C6061CC579DB30@HE1PR02MB3132.eurprd02.prod.outlook.com>
References: <HE1PR02MB3132DFFBCCFE0E6C6061CC579DB30@HE1PR02MB3132.eurprd02.prod.outlook.com>
Message-ID: <3843172.Ly00O2OvuP@tjmaciei-mobl1>

On segunda-feira, 31 de julho de 2017 23:55:28 PDT Jani Heikkinen wrote:
> And we should start soft branching today. But as Frederik informed yesterday
> we are planning to do some changes to coin infrastructure during this week
> (see
> http://lists.qt-project.org/pipermail/development/2017-July/030596.html).
> So let's postpone the start of soft branching a bit and do it after coin
> infra changes are in & working. Doing one more branch just now makes these
> coin changes more difficult & most probably causes more delays in the
> future.
> 
> So the plan with 5.10 is following:
> 1. Let's keep the agreed ff as it is (8.8.2017)

Please note that this means that in the next 7 days we need to:

1. Integrate all of Ossi's configure changes to 5.9 (re-staged now)
https://codereview.qt-project.org/201118
https://codereview.qt-project.org/201119
https://codereview.qt-project.org/201120
https://codereview.qt-project.org/201121
https://codereview.qt-project.org/201201
https://codereview.qt-project.org/201122
https://codereview.qt-project.org/201120
https://codereview.qt-project.org/201202
https://codereview.qt-project.org/201203
https://codereview.qt-project.org/201204
https://codereview.qt-project.org/201205
https://codereview.qt-project.org/199408
https://codereview.qt-project.org/201206

2. Merge those up to dev.

3. Apply all my changes
set 1:
https://codereview.qt-project.org/167049
https://codereview.qt-project.org/200061
https://codereview.qt-project.org/165952
https://codereview.qt-project.org/199037
https://codereview.qt-project.org/200062
https://codereview.qt-project.org/200073

set 2:
https://codereview.qt-project.org/199004
https://codereview.qt-project.org/199005
https://codereview.qt-project.org/200063
https://codereview.qt-project.org/200064
https://codereview.qt-project.org/200065
https://codereview.qt-project.org/200453
https://codereview.qt-project.org/199007
https://codereview.qt-project.org/200068
https://codereview.qt-project.org/200069
https://codereview.qt-project.org/200070
https://codereview.qt-project.org/200071
https://codereview.qt-project.org/200072
https://codereview.qt-project.org/200074
https://codereview.qt-project.org/199000
https://codereview.qt-project.org/200066
https://codereview.qt-project.org/200180
https://codereview.qt-project.org/200924
https://codereview.qt-project.org/200832
https://codereview.qt-project.org/200258
https://codereview.qt-project.org/200836
https://codereview.qt-project.org/200926

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center



From thiago.macieira at intel.com  Tue Aug  1 09:40:28 2017
From: thiago.macieira at intel.com (Thiago Macieira)
Date: Tue, 01 Aug 2017 00:40:28 -0700
Subject: [Development] Qt 5.10 schedule etc
In-Reply-To: <3843172.Ly00O2OvuP@tjmaciei-mobl1>
References: <HE1PR02MB3132DFFBCCFE0E6C6061CC579DB30@HE1PR02MB3132.eurprd02.prod.outlook.com>
	<3843172.Ly00O2OvuP@tjmaciei-mobl1>
Message-ID: <4498563.6ShosfVC4Z@tjmaciei-mobl1>

On terça-feira, 1 de agosto de 2017 00:18:18 PDT Thiago Macieira wrote:
> 1. Integrate all of Ossi's configure changes to 5.9 (re-staged now)
> https://codereview.qt-project.org/201118
> https://codereview.qt-project.org/201119
> https://codereview.qt-project.org/201120
> https://codereview.qt-project.org/201121
> https://codereview.qt-project.org/201201
> https://codereview.qt-project.org/201122
> https://codereview.qt-project.org/201120
> https://codereview.qt-project.org/201202
> https://codereview.qt-project.org/201203
> https://codereview.qt-project.org/201204
> https://codereview.qt-project.org/201205
> https://codereview.qt-project.org/199408
> https://codereview.qt-project.org/201206

Failed integration with:

 Module "<nil>" (<nil>) Failed to provision template 'qtci-windows-8-x86_64-2-
da597b':
 Could not clone template: qtci-windows-8-x86_64-2-da597b - Template VM was 
not found.

This same error has been happening for a fix in qtwebkit.

> 2. Merge those up to dev.
> 
> 3. Apply all my changes
> set 1:
> https://codereview.qt-project.org/167049
> https://codereview.qt-project.org/200061
> https://codereview.qt-project.org/165952
> https://codereview.qt-project.org/199037
> https://codereview.qt-project.org/200062
> https://codereview.qt-project.org/200073

Set 1 is now staged.

Going to bed now.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center



From mitch.curtis at qt.io  Tue Aug  1 09:43:03 2017
From: mitch.curtis at qt.io (Mitch Curtis)
Date: Tue, 1 Aug 2017 07:43:03 +0000
Subject: [Development] Qt 5.10 schedule etc
In-Reply-To: <4498563.6ShosfVC4Z@tjmaciei-mobl1>
References: <HE1PR02MB3132DFFBCCFE0E6C6061CC579DB30@HE1PR02MB3132.eurprd02.prod.outlook.com>
	<3843172.Ly00O2OvuP@tjmaciei-mobl1> <4498563.6ShosfVC4Z@tjmaciei-mobl1>
Message-ID: <HE1PR02MB1132F9ACEAF5788E8776786588B30@HE1PR02MB1132.eurprd02.prod.outlook.com>

> -----Original Message-----
> From: Development [mailto:development-bounces+mitch.curtis=qt.io at qt-
> project.org] On Behalf Of Thiago Macieira
> Sent: Tuesday, 1 August 2017 9:40 AM
> To: development at qt-project.org
> Subject: Re: [Development] Qt 5.10 schedule etc
> 
> On terça-feira, 1 de agosto de 2017 00:18:18 PDT Thiago Macieira wrote:
> > 1. Integrate all of Ossi's configure changes to 5.9 (re-staged now)
> > https://codereview.qt-project.org/201118
> > https://codereview.qt-project.org/201119
> > https://codereview.qt-project.org/201120
> > https://codereview.qt-project.org/201121
> > https://codereview.qt-project.org/201201
> > https://codereview.qt-project.org/201122
> > https://codereview.qt-project.org/201120
> > https://codereview.qt-project.org/201202
> > https://codereview.qt-project.org/201203
> > https://codereview.qt-project.org/201204
> > https://codereview.qt-project.org/201205
> > https://codereview.qt-project.org/199408
> > https://codereview.qt-project.org/201206
> 
> Failed integration with:
> 
>  Module "<nil>" (<nil>) Failed to provision template 'qtci-windows-8-x86_64-
> 2-
> da597b':
>  Could not clone template: qtci-windows-8-x86_64-2-da597b - Template VM
> was not found.
> 
> This same error has been happening for a fix in qtwebkit.

I've seen the same error and was told that there are network problems that are being looked into.

> > 2. Merge those up to dev.
> >
> > 3. Apply all my changes
> > set 1:
> > https://codereview.qt-project.org/167049
> > https://codereview.qt-project.org/200061
> > https://codereview.qt-project.org/165952
> > https://codereview.qt-project.org/199037
> > https://codereview.qt-project.org/200062
> > https://codereview.qt-project.org/200073
> 
> Set 1 is now staged.
> 
> Going to bed now.
> 
> --
> 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 tony.sarajarvi at qt.io  Tue Aug  1 09:48:46 2017
From: tony.sarajarvi at qt.io (=?iso-8859-1?Q?Tony_Saraj=E4rvi?=)
Date: Tue, 1 Aug 2017 07:48:46 +0000
Subject: [Development] CI has infra problems
Message-ID: <VI1PR02MB111940969B06BD683996A8B692B30@VI1PR02MB1119.eurprd02.prod.outlook.com>

Hi

Windows provisionings are failing currently. Most likely culprit is some DHCP or router misconfiguration. We'll begin investigating immediately.

-T
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20170801/c8aa0898/attachment.html>

From tony.sarajarvi at qt.io  Tue Aug  1 10:30:41 2017
From: tony.sarajarvi at qt.io (=?utf-8?B?VG9ueSBTYXJhasOkcnZp?=)
Date: Tue, 1 Aug 2017 08:30:41 +0000
Subject: [Development] CI has infra problems
In-Reply-To: <VI1PR02MB111940969B06BD683996A8B692B30@VI1PR02MB1119.eurprd02.prod.outlook.com>
References: <VI1PR02MB111940969B06BD683996A8B692B30@VI1PR02MB1119.eurprd02.prod.outlook.com>
Message-ID: <VI1PR02MB11194865DA341947E73552DB92B30@VI1PR02MB1119.eurprd02.prod.outlook.com>

Fixed! Thanks for your patience 😊

-T

From: Tony Sarajärvi
Sent: tiistai 1. elokuuta 2017 10.49
To: development at qt-project.org
Cc: Qt Development <qt.development at qt.io>
Subject: CI has infra problems

Hi

Windows provisionings are failing currently. Most likely culprit is some DHCP or router misconfiguration. We’ll begin investigating immediately.

-T
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20170801/b8789505/attachment.html>

From denis.shienkov at gmail.com  Tue Aug  1 12:18:37 2017
From: denis.shienkov at gmail.com (Denis Shienkov)
Date: Tue, 1 Aug 2017 13:18:37 +0300
Subject: [Development] Nominating Denis Shienkov for Approver status
In-Reply-To: <3882866.DtbGhIb7l1@tjmaciei-mobl1>
References: <239acd2f-188f-b018-1b68-245e04c1e9b6@iseg-hv.de>
	<DB4PR02MB02854477CD70C2387AE448A1E7B30@DB4PR02MB0285.eurprd02.prod.outlook.com>
	<f997050e-4bec-c757-596e-a403802982ec@gmail.com>
	<3882866.DtbGhIb7l1@tjmaciei-mobl1>
Message-ID: <CAHtcb0w+NjJ1o+_dRV-+1WDga4dmUm5s5bHQkUvQ21FS79BTuw@mail.gmail.com>

WOW, I'm surprised.. Thanks. Need to drink.. :)

2017-08-01 10:20 GMT+03:00 Thiago Macieira <thiago.macieira at intel.com>:

> On segunda-feira, 31 de julho de 2017 23:54:02 PDT Denis Shienkov wrote:
> > WOW, thanks... :)
> >
> > Q: Approver of what?
>
> In the Qt Project. You get the rights throughout, but you're expected to
> only
> give +2 when you know what you're doing.
>
> --
> 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: <http://lists.qt-project.org/pipermail/development/attachments/20170801/3bef2cc9/attachment.html>

From andre.hartmann at iseg-hv.de  Tue Aug  1 12:58:54 2017
From: andre.hartmann at iseg-hv.de (=?UTF-8?Q?Andr=c3=a9_Hartmann?=)
Date: Tue, 1 Aug 2017 12:58:54 +0200
Subject: [Development] Nominating Denis Shienkov for Approver status
In-Reply-To: <CAHtcb0w+NjJ1o+_dRV-+1WDga4dmUm5s5bHQkUvQ21FS79BTuw@mail.gmail.com>
References: <239acd2f-188f-b018-1b68-245e04c1e9b6@iseg-hv.de>
	<DB4PR02MB02854477CD70C2387AE448A1E7B30@DB4PR02MB0285.eurprd02.prod.outlook.com>
	<f997050e-4bec-c757-596e-a403802982ec@gmail.com>
	<3882866.DtbGhIb7l1@tjmaciei-mobl1>
	<CAHtcb0w+NjJ1o+_dRV-+1WDga4dmUm5s5bHQkUvQ21FS79BTuw@mail.gmail.com>
Message-ID: <1e133072-2181-278f-79ca-23d27f1c7d82@iseg-hv.de>

Hi Denis,

 > WOW, I'm surprised.. Thanks. Need to drink.. :)

But don't drink too much ... you may have to review something later today :)

Honestly, this is also a "thank you" for your long-term Qt contribution. 
Keep it up!

Best regards,
André

Am 01.08.2017 um 12:18 schrieb Denis Shienkov:
> WOW, I'm surprised.. Thanks. Need to drink.. :)
> 
> 2017-08-01 10:20 GMT+03:00 Thiago Macieira <thiago.macieira at intel.com 
> <mailto:thiago.macieira at intel.com>>:
> 
>     On segunda-feira, 31 de julho de 2017 23:54:02 PDT Denis Shienkov wrote:
>     > WOW, thanks... :)
>     >
>     > Q: Approver of what?
> 
>     In the Qt Project. You get the rights throughout, but you're
>     expected to only
>     give +2 when you know what you're doing.
> 
>     --
>     Thiago Macieira - thiago.macieira (AT) intel.com <http://intel.com>
>        Software Architect - Intel Open Source Technology Center
> 
>     _______________________________________________
>     Development mailing list
>     Development at qt-project.org <mailto:Development at qt-project.org>
>     http://lists.qt-project.org/mailman/listinfo/development
>     <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 Kai.Koehne at qt.io  Tue Aug  1 14:44:54 2017
From: Kai.Koehne at qt.io (Kai Koehne)
Date: Tue, 1 Aug 2017 12:44:54 +0000
Subject: [Development] Give reviewers ample time to respond
Message-ID: <AM4PR02MB32508DB7315412B0855FFBE298B30@AM4PR02MB3250.eurprd02.prod.outlook.com>

Hi,

I'd like to remind everyone about our commit policy: https://wiki.qt.io/Review_Policy . In particular, it says 'Give reviewers ample time to respond', which is assumed to be a full working day minimum (preferably two days). 

That is, even if you have a +2 by an approver, you should _not_ stage immediately if there are other reviewers who haven't given feedback yet.

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 frederik.gladhorn at qt.io  Tue Aug  1 16:07:16 2017
From: frederik.gladhorn at qt.io (Frederik Gladhorn)
Date: Tue, 01 Aug 2017 16:07:16 +0200
Subject: [Development] Coin infrastructure changes
In-Reply-To: <DB6PR02MB3126A9AB82AE3CC9D67E688A87B20@DB6PR02MB3126.eurprd02.prod.outlook.com>
References: <1795351.MzuLWtvgav@frederik-thinkcentre-m93p>
	<DB6PR02MB3126A9AB82AE3CC9D67E688A87B20@DB6PR02MB3126.eurprd02.prod.outlook.com>
Message-ID: <4526757.xC0H3MDiR9@frederik-thinkcentre-m93p>

On mandag 31. juli 2017 15.24.57 CEST Laszlo Agocs wrote:
> Hi,
> 
> Are we sure that the week before the 5.10 feature freeze date is really the
> best time to do this?

Yes and no. There clearly is no good time. The longer we wait, the more 
trouble we'll have. The change is needed to take fresh new hardware into use 
and move forward. Right now things are still comparatively calm as many people 
were on vacation and are only now comming back. We'd have liked to be faster, 
but only now feel that it would be responsible to switch.

The current issues (that are seemingly still ongoing) are by the way the old 
system falling apart, seems like it wants to support us moving on. We haven't 
changed anything yet (and it will probably be Friday before we feel that we're 
finally ready).

Cheers,
Frederik


> 
> Cheers,
> Laszlo
> 
> -----Original Message-----
> From: Development
> [mailto:development-bounces+laszlo.agocs=qt.io at qt-project.org] On Behalf Of
> Frederik Gladhorn Sent: mandag 31. juli 2017 15.19
> To: development at qt-project.org
> Subject: [Development] Coin infrastructure changes
> 
> Hi all,
> 
> this is mostly for your information. On Wednesday this week (most likely)
> we're making changes to Coin, potentially leading to some interruptions in
> integrations.
> 
> The longer version:
> 
> We've been working towards replacing the underlying virtualization layer in
> our Continuous Integration infrastructure and have now reached a point
> where we're ready (as ready as we'll get at least) to switch over from
> VSphere to OpenNebula. There are a bunch of advantages (not least that we
> can actually debug issues in OpenNebula/KVM, it'll make the scheduling code
> in Coin easier, ...).
> 
> This will also be the point at which we start to use some of the new
> hardware that The Qt Company has been purchasing and getting ready, so
> things will initially be at the same speed and eventually much faster.
> 
> We have Qt 5.6 and 5.9 running smoothly, the dev branch currently needs some
> merges, hopefully we'll get it working really soon now.
> 
> Hopefully the process is: stop the system; change branch; restart and things
> will work. I would expect some hickups when we scale up and run in
> production mode, so bear with us and report issues, we'll eventually be
> better off, once things are in shape.
> 
> Cheers,
> Frederik
> 
> _______________________________________________
> Development mailing list
> Development at qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development




From harald.vistnes at gmail.com  Tue Aug  1 20:04:34 2017
From: harald.vistnes at gmail.com (Harald Vistnes)
Date: Tue, 1 Aug 2017 20:04:34 +0200
Subject: [Development]  Qt3D without Qml/QtQuick?
Message-ID: <CAGqrDLt73McqWbnAWYwo_bpZ7ntj2ObpyeT49LbHfUoawDMp9w@mail.gmail.com>

Hi,

is it possible to build the pure C++ subset of Qt3D (Qt3DCore, Qt3DRender,
Qt3DExtras, Qt3DInput, Qt3DLogic) without Qml and QtQuick? I tried to
configure and build Qt with -skip qtdeclarative, but then Qt3D was skipped
completely.

After building Qt I tried building Qt3D manually by running
qmake qt3d.pro and jom but with the following error message:

D:\qt5\qt3d>..\qtbase\bin\qmake.exe qt3d.pro
Info: creating cache file D:\qt5\qt3d\.qmake.cache

D:\qt5\qt3d>jom

jom 1.1.2 - empower your cores

        cd src\ && ( if not exist Makefile D:\qt5\qtbase\bin\qmake.exe -o
Makefile D:\qt5\qt3d\src\src.pro ) && c:\jom\jom.exe -f Makefile
        cd core\ && ( if not exist Makefile D:\qt5\qtbase\bin\qmake.exe -o
Makefile D:\qt5\qt3d\src\core\core.pro ) && c:\jom\jom.exe -f Makefile
Cannot read D:/qt5/qt3d/src/core/qt3dcore-config.pri: No such file or
directory
Project ERROR: Could not find feature qt3d-profile-jobs.
jom: D:\qt5\qt3d\src\Makefile [sub-core-make_first] Error 3
        cd doc\ && ( if not exist Makefile D:\qt5\qtbase\bin\qmake.exe -o
Makefile D:\qt5\qt3d\src\doc\doc.pro ) && c:\jom\jom.exe -f Makefile
        c:\jom\jom.exe -f Makefile.Release
jom: D:\qt5\qt3d\Makefile [sub-src-make_first] Error 2


I'm on Windows 10, VS2015, latest sources from git, 5.9 branch.

Thanks,
Harald
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20170801/0875871e/attachment.html>

From sh at theharmers.co.uk  Tue Aug  1 20:26:32 2017
From: sh at theharmers.co.uk (Sean Harmer)
Date: Tue, 1 Aug 2017 19:26:32 +0100
Subject: [Development] Qt3D without Qml/QtQuick?
In-Reply-To: <CAGqrDLt73McqWbnAWYwo_bpZ7ntj2ObpyeT49LbHfUoawDMp9w@mail.gmail.com>
References: <CAGqrDLt73McqWbnAWYwo_bpZ7ntj2ObpyeT49LbHfUoawDMp9w@mail.gmail.com>
Message-ID: <0422e2fe-de4d-2d20-33aa-575ad38d9d4e@theharmers.co.uk>

Hi,

On 01/08/2017 19:04, Harald Vistnes wrote:
> Hi,
>
> is it possible to build the pure C++ subset of Qt3D (Qt3DCore,
> Qt3DRender, Qt3DExtras, Qt3DInput, Qt3DLogic) without Qml and QtQuick? I
> tried to configure and build Qt with -skip qtdeclarative, but then Qt3D
> was skipped completely.

Yeah, at the moment Qt 3D is marked as requiring QtDeclarative but 
indeed there is no reason why that can't be made an optional dependency 
to allow what you need. It should be pretty easy to fix up 
qt3d/src/src.pro. Patches welcome :)

Cheers,

Sean

>
> After building Qt I tried building Qt3D manually by running
> qmake qt3d.pro <http://qt3d.pro> and jom but with the following error
> message:
>
> D:\qt5\qt3d>..\qtbase\bin\qmake.exe qt3d.pro <http://qt3d.pro>
> Info: creating cache file D:\qt5\qt3d\.qmake.cache
>
> D:\qt5\qt3d>jom
>
> jom 1.1.2 - empower your cores
>
>         cd src\ && ( if not exist Makefile D:\qt5\qtbase\bin\qmake.exe
> -o Makefile D:\qt5\qt3d\src\src.pro <http://src.pro> ) && c:\jom\jom.exe
> -f Makefile
>         cd core\ && ( if not exist Makefile D:\qt5\qtbase\bin\qmake.exe
> -o Makefile D:\qt5\qt3d\src\core\core.pro <http://core.pro> ) &&
> c:\jom\jom.exe -f Makefile
> Cannot read D:/qt5/qt3d/src/core/qt3dcore-config.pri: No such file or
> directory
> Project ERROR: Could not find feature qt3d-profile-jobs.
> jom: D:\qt5\qt3d\src\Makefile [sub-core-make_first] Error 3
>         cd doc\ && ( if not exist Makefile D:\qt5\qtbase\bin\qmake.exe
> -o Makefile D:\qt5\qt3d\src\doc\doc.pro <http://doc.pro> ) &&
> c:\jom\jom.exe -f Makefile
>         c:\jom\jom.exe -f Makefile.Release
> jom: D:\qt5\qt3d\Makefile [sub-src-make_first] Error 2
>
>
> I'm on Windows 10, VS2015, latest sources from git, 5.9 branch.
>
> Thanks,
> Harald
>
>
>
>
> _______________________________________________
> Development mailing list
> Development at qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development
>


From harald.vistnes at gmail.com  Tue Aug  1 21:14:18 2017
From: harald.vistnes at gmail.com (Harald Vistnes)
Date: Tue, 1 Aug 2017 21:14:18 +0200
Subject: [Development] Qt3D without Qml/QtQuick?
In-Reply-To: <0422e2fe-de4d-2d20-33aa-575ad38d9d4e@theharmers.co.uk>
References: <CAGqrDLt73McqWbnAWYwo_bpZ7ntj2ObpyeT49LbHfUoawDMp9w@mail.gmail.com>
	<0422e2fe-de4d-2d20-33aa-575ad38d9d4e@theharmers.co.uk>
Message-ID: <CAGqrDLt6ruv5C3OYLmBfijK8tcVrF_M5LqhJLyMtyaoMVpKMNQ@mail.gmail.com>

Thanks Sean,

I had a look in qt3d/src/src.pro, but there already was a
qtHaveModule(quick) {} around the quick3d libs and I don't know where the
dependency on qtdeclarative is set. I'd be happy to provide a patch, but it
seems I don't know enough about the internal Qt dependency settings...

Harald


2017-08-01 20:26 GMT+02:00 Sean Harmer <sh at theharmers.co.uk>:

> Hi,
>
> On 01/08/2017 19:04, Harald Vistnes wrote:
>
>> Hi,
>>
>> is it possible to build the pure C++ subset of Qt3D (Qt3DCore,
>> Qt3DRender, Qt3DExtras, Qt3DInput, Qt3DLogic) without Qml and QtQuick? I
>> tried to configure and build Qt with -skip qtdeclarative, but then Qt3D
>> was skipped completely.
>>
>
> Yeah, at the moment Qt 3D is marked as requiring QtDeclarative but indeed
> there is no reason why that can't be made an optional dependency to allow
> what you need. It should be pretty easy to fix up qt3d/src/src.pro.
> Patches welcome :)
>
> Cheers,
>
> Sean
>
>
>> After building Qt I tried building Qt3D manually by running
>> qmake qt3d.pro <http://qt3d.pro> and jom but with the following error
>> message:
>>
>> D:\qt5\qt3d>..\qtbase\bin\qmake.exe qt3d.pro <http://qt3d.pro>
>> Info: creating cache file D:\qt5\qt3d\.qmake.cache
>>
>> D:\qt5\qt3d>jom
>>
>> jom 1.1.2 - empower your cores
>>
>>         cd src\ && ( if not exist Makefile D:\qt5\qtbase\bin\qmake.exe
>> -o Makefile D:\qt5\qt3d\src\src.pro <http://src.pro> ) && c:\jom\jom.exe
>> -f Makefile
>>         cd core\ && ( if not exist Makefile D:\qt5\qtbase\bin\qmake.exe
>> -o Makefile D:\qt5\qt3d\src\core\core.pro <http://core.pro> ) &&
>> c:\jom\jom.exe -f Makefile
>> Cannot read D:/qt5/qt3d/src/core/qt3dcore-config.pri: No such file or
>> directory
>> Project ERROR: Could not find feature qt3d-profile-jobs.
>> jom: D:\qt5\qt3d\src\Makefile [sub-core-make_first] Error 3
>>         cd doc\ && ( if not exist Makefile D:\qt5\qtbase\bin\qmake.exe
>> -o Makefile D:\qt5\qt3d\src\doc\doc.pro <http://doc.pro> ) &&
>> c:\jom\jom.exe -f Makefile
>>         c:\jom\jom.exe -f Makefile.Release
>> jom: D:\qt5\qt3d\Makefile [sub-src-make_first] Error 2
>>
>>
>> I'm on Windows 10, VS2015, latest sources from git, 5.9 branch.
>>
>> Thanks,
>> Harald
>>
>>
>>
>>
>> _______________________________________________
>> 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: <http://lists.qt-project.org/pipermail/development/attachments/20170801/923213e1/attachment.html>

From thiago.macieira at intel.com  Tue Aug  1 21:25:45 2017
From: thiago.macieira at intel.com (Thiago Macieira)
Date: Tue, 1 Aug 2017 12:25:45 -0700
Subject: [Development] Qt3D without Qml/QtQuick?
In-Reply-To: <CAGqrDLt6ruv5C3OYLmBfijK8tcVrF_M5LqhJLyMtyaoMVpKMNQ@mail.gmail.com>
References: <CAGqrDLt73McqWbnAWYwo_bpZ7ntj2ObpyeT49LbHfUoawDMp9w@mail.gmail.com>
	<0422e2fe-de4d-2d20-33aa-575ad38d9d4e@theharmers.co.uk>
	<CAGqrDLt6ruv5C3OYLmBfijK8tcVrF_M5LqhJLyMtyaoMVpKMNQ@mail.gmail.com>
Message-ID: <1801176.nTSr5lU83M@tjmaciei-mobl1>

On terça-feira, 1 de agosto de 2017 12:14:18 PDT Harald Vistnes wrote:
> I had a look in qt3d/src/src.pro, but there already was a
> qtHaveModule(quick) {} around the quick3d libs and I don't know where the
> dependency on qtdeclarative is set. I'd be happy to provide a patch, but it
> seems I don't know enough about the internal Qt dependency settings...

It's set in qt5.git's file .gitmodules.

[submodule "qt3d"]
        depends = qtdeclarative
        recommends = qtimageformats qtgamepad
        path = qt3d
        url = ../qt3d.git
        branch = 5.9
        status = addon

You want to make qtbase a strict dependency and move qtdeclarative to 
"recommends".

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center



From harald.vistnes at gmail.com  Tue Aug  1 22:21:45 2017
From: harald.vistnes at gmail.com (Harald Vistnes)
Date: Tue, 1 Aug 2017 22:21:45 +0200
Subject: [Development] Qt3D without Qml/QtQuick?
In-Reply-To: <1801176.nTSr5lU83M@tjmaciei-mobl1>
References: <CAGqrDLt73McqWbnAWYwo_bpZ7ntj2ObpyeT49LbHfUoawDMp9w@mail.gmail.com>
	<0422e2fe-de4d-2d20-33aa-575ad38d9d4e@theharmers.co.uk>
	<CAGqrDLt6ruv5C3OYLmBfijK8tcVrF_M5LqhJLyMtyaoMVpKMNQ@mail.gmail.com>
	<1801176.nTSr5lU83M@tjmaciei-mobl1>
Message-ID: <CAGqrDLsDdEdPBa2V1p-WswBDuU7p3yDZ-vW3ywjtSuvrt3bBCg@mail.gmail.com>

Thanks Thiago,

that was it! I changed it .gitmodules to

[submodule "qt3d"]
depends = qtbase
recommends = qtdeclarative qtimageformats qtgamepad
path = qt3d
url = ../qt3d.git
branch = 5.9
status = addon

Now Qt3D builds even with -skip qtdeclarative.

Harald


2017-08-01 21:25 GMT+02:00 Thiago Macieira <thiago.macieira at intel.com>:

> On terça-feira, 1 de agosto de 2017 12:14:18 PDT Harald Vistnes wrote:
> > I had a look in qt3d/src/src.pro, but there already was a
> > qtHaveModule(quick) {} around the quick3d libs and I don't know where the
> > dependency on qtdeclarative is set. I'd be happy to provide a patch, but
> it
> > seems I don't know enough about the internal Qt dependency settings...
>
> It's set in qt5.git's file .gitmodules.
>
> [submodule "qt3d"]
>         depends = qtdeclarative
>         recommends = qtimageformats qtgamepad
>         path = qt3d
>         url = ../qt3d.git
>         branch = 5.9
>         status = addon
>
> You want to make qtbase a strict dependency and move qtdeclarative to
> "recommends".
>
> --
> 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: <http://lists.qt-project.org/pipermail/development/attachments/20170801/aba48ad5/attachment.html>

From thiago.macieira at intel.com  Tue Aug  1 22:31:26 2017
From: thiago.macieira at intel.com (Thiago Macieira)
Date: Tue, 1 Aug 2017 13:31:26 -0700
Subject: [Development] Qt3D without Qml/QtQuick?
In-Reply-To: <CAGqrDLsDdEdPBa2V1p-WswBDuU7p3yDZ-vW3ywjtSuvrt3bBCg@mail.gmail.com>
References: <CAGqrDLt73McqWbnAWYwo_bpZ7ntj2ObpyeT49LbHfUoawDMp9w@mail.gmail.com>
	<1801176.nTSr5lU83M@tjmaciei-mobl1>
	<CAGqrDLsDdEdPBa2V1p-WswBDuU7p3yDZ-vW3ywjtSuvrt3bBCg@mail.gmail.com>
Message-ID: <2976338.3deAu578Eq@tjmaciei-mobl1>

On terça-feira, 1 de agosto de 2017 13:21:45 PDT Harald Vistnes wrote:
> Thanks Thiago,
> 
> that was it! I changed it .gitmodules to
> 
> [submodule "qt3d"]
> depends = qtbase
> recommends = qtdeclarative qtimageformats qtgamepad
> path = qt3d
> url = ../qt3d.git
> branch = 5.9
> status = addon
> 
> Now Qt3D builds even with -skip qtdeclarative.
> 
> Harald

Now submit it.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center



From harald.vistnes at gmail.com  Tue Aug  1 23:27:58 2017
From: harald.vistnes at gmail.com (Harald Vistnes)
Date: Tue, 1 Aug 2017 23:27:58 +0200
Subject: [Development] Qt3D without Qml/QtQuick?
In-Reply-To: <2976338.3deAu578Eq@tjmaciei-mobl1>
References: <CAGqrDLt73McqWbnAWYwo_bpZ7ntj2ObpyeT49LbHfUoawDMp9w@mail.gmail.com>
	<1801176.nTSr5lU83M@tjmaciei-mobl1>
	<CAGqrDLsDdEdPBa2V1p-WswBDuU7p3yDZ-vW3ywjtSuvrt3bBCg@mail.gmail.com>
	<2976338.3deAu578Eq@tjmaciei-mobl1>
Message-ID: <CAGqrDLsx==DADb4qXcdQQTR_g_y=fSkvOa1D+a8UypAMwqJJbA@mail.gmail.com>

Done.

2017-08-01 22:31 GMT+02:00 Thiago Macieira <thiago.macieira at intel.com>:

> On terça-feira, 1 de agosto de 2017 13:21:45 PDT Harald Vistnes wrote:
> > Thanks Thiago,
> >
> > that was it! I changed it .gitmodules to
> >
> > [submodule "qt3d"]
> > depends = qtbase
> > recommends = qtdeclarative qtimageformats qtgamepad
> > path = qt3d
> > url = ../qt3d.git
> > branch = 5.9
> > status = addon
> >
> > Now Qt3D builds even with -skip qtdeclarative.
> >
> > Harald
>
> Now submit it.
>
> --
> 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: <http://lists.qt-project.org/pipermail/development/attachments/20170801/abc7257a/attachment.html>

From thiago.macieira at intel.com  Wed Aug  2 00:11:38 2017
From: thiago.macieira at intel.com (Thiago Macieira)
Date: Tue, 1 Aug 2017 15:11:38 -0700
Subject: [Development] CI has infra problems
In-Reply-To: <VI1PR02MB11194865DA341947E73552DB92B30@VI1PR02MB1119.eurprd02.prod.outlook.com>
References: <VI1PR02MB111940969B06BD683996A8B692B30@VI1PR02MB1119.eurprd02.prod.outlook.com>
	<VI1PR02MB11194865DA341947E73552DB92B30@VI1PR02MB1119.eurprd02.prod.outlook.com>
Message-ID: <2440538.JxO7cD1VFa@tjmaciei-mobl1>

No, another problem has now appeared:

 Module "qt/qtbase" (34adca0607ff9231b4c79949353827c1c8319c52) Failed 
repeatedly to launch build/test agent:
 Failed 7 times to acquire the hardware
         buildKey: qt/qtbase/eab0f32365c02540893fd3d1d75c2af2b4e6f6e8/
LinuxUbuntu_16_04x86_64LinuxUbuntu_16_04x86_64GCCqtci-linux-Ubuntu-16.04-
x86_64-1-bd2be3TestOnly_LicenseCheck/7ca30f915833d953146007e71743147e3e719500/
Test
         agentLaunchRequest: AgentLaunchRequest(machineType=0, 
testConfiguration=TestConfiguration(testHack=None, features=[8, 7], 
vmTemplate='qtci-linux-Ubuntu-16.04-x86_64-1-bd2be3', configureArgs=None, 
toolsets=[Toolset(targetSourceDirectory='qt/qtqa-latest', branch='master', 
excludeSubModules=None, 
repositoryState=RepositoryState(sha1='f2fea571b9e17dc31eff349f6b744603c670dcd6', 
project='qt/qtqa', contentSha1='2e26fde8a7db0bb8e81edb44509ea8a64d257e1a', 
dependencies=[], gerritInstance='qt-project'), sourceOnly=True)], 
target=Machine(os=1, arch='x86_64', os_version=304, compiler=0), 
host=Machine(os=1, arch='x86_64', os_version=304, compiler=0), type=0), 
productVersion='5.9', buildKey='qt/qtbase/
eab0f32365c02540893fd3d1d75c2af2b4e6f6e8/
LinuxUbuntu_16_04x86_64LinuxUbuntu_16_04x86_64GCCqtci-linux-Ubuntu-16.04-
x86_64-1-bd2be3TestOnly_LicenseCheck/7ca30f915833d953146007e71743147e3e719500/
Test', vmTemplate='qtci-linux-Ubuntu-16.04-x86_64-1-bd2be3', type=1)
         reasons:
    


On terça-feira, 1 de agosto de 2017 01:30:41 PDT Tony Sarajärvi wrote:
> Fixed! Thanks for your patience 😊
> 
> -T
> 
> From: Tony Sarajärvi
> Sent: tiistai 1. elokuuta 2017 10.49
> To: development at qt-project.org
> Cc: Qt Development <qt.development at qt.io>
> Subject: CI has infra problems
> 
> Hi
> 
> Windows provisionings are failing currently. Most likely culprit is some
> DHCP or router misconfiguration. We’ll begin investigating immediately.
 
> -T


-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center



From quentin.schulz at free-electrons.com  Wed Aug  2 08:34:02 2017
From: quentin.schulz at free-electrons.com (Quentin Schulz)
Date: Wed, 2 Aug 2017 08:34:02 +0200
Subject: [Development] Screen mirroring
Message-ID: <035f3d4a-9baa-845a-e1e0-65b4eddc2ed0@free-electrons.com>

Hi all,

I'm currently working on getting screen mirroring working on an iMX6Q
with Qt5.8 and eglfs plugin.

On this SoC, there is an IPU (Image Processing Unit) which has two DI
(Display Interface). The DI is connected to encoders (HDMI and LVDS
in our case) and can each handle one screen. It is my understanding that
a DI can be assimilated as a CRTC.

We use the eglfs plugin (via -platform) with kms back-end.

I'm able to display content on the two screens connected to the HDMI and
LVDS with Qt5_Cinematicexperience (one screen at a time) or
quickmwtest[1] (both screens at the same time, but different images)
thanks to a JSON file I specify with QT_QPA_EGLFS_KMS_CONFIG.

What I would like to achieve is to have the same image on both screens
at the same time (same resolution of 1024x768 limited by the LVDS)
without having to code the application to explicitly "copy" what is
displayed on one screen to the other.

I managed to achieve this goal by using the same framebuffer for both
CRTCs. I basically added a drmModeSetCrtc to QEglFSKmsGbmScreen::flip[2]
with hardcoded connectors and CRTCs ids. See horrible patch here[3].

Is it (using the same framebuffer for both CRTCs) the right way to do
it? How do you see it being implemented? I guess that we should also
adapt the JSON file to be able to specify screen mirroring.

Else, what do you suggest?

Thanks,
Quentin

[1] https://github.com/alpqr/quickmwtest
[2]
https://git.qt.io/consulting-usa/qtbase-xcb-rendering/blob/dev/src/plugins/platforms/eglfs/deviceintegration/eglfs_kms/qeglfskmsgbmscreen.cpp#L193
[3] http://code.bulix.org/vs6d7z-176162
-- 
Quentin Schulz, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com


From lars.knoll at qt.io  Wed Aug  2 09:17:06 2017
From: lars.knoll at qt.io (Lars Knoll)
Date: Wed, 2 Aug 2017 07:17:06 +0000
Subject: [Development] Stepping down as widgets maintainers
In-Reply-To: <1714138.kXay1iSZ6k@tjmaciei-mobl1>
References: <97a1d14fbd1f7e45ed3f42772b32fd46@kdab.com>
	<1714138.kXay1iSZ6k@tjmaciei-mobl1>
Message-ID: <B47AC78C-970C-4876-80BF-96E4819255AC@qt.io>

Hi,

I think the proper time has passed, so congratulations to Richard to his new role. There were no objections towards the sub-maintainers neither, and Richard was part of creating that proposal, so I think those are then settled as well. Congratulations to all of you, and thanks for stepping up. The wiki and Maintainer list in gerrit has been adjusted accordingly.

And once again a big thank you to Marc for your efforts in maintaining Qt Widgets so far.

Cheers,
Lars

> On 7 Jul 2017, at 18:34, Thiago Macieira <thiago.macieira at intel.com> wrote:
> 
> On sexta-feira, 7 de julho de 2017 03:20:19 PDT Marc Mutz wrote:
>> KDAB is handing back widgets maintenance, which means that I'm stepping
>> down as widgets maintainer. The focus of KDAB contributions to Qt is
>> clearly elsewhere these days (Qt3D, Core, tooling), and the module
>> deserves more focus than it has seen lately.
> 
> Hello Marc
> 
> Let me thank you for the effort on the module so far and for the work you've 
> been doing in the core. It's much appreciated.
> 
> Frederik wrote:
>> Richard Gustavsen as overall maintainer
>> Gabriel de Dietrich for styles
>> Jan-Arve Sæther for layouts
>> Eskil Abrahamsen-Blomfeldt for all text related things
>> Andreas Aardal Hanssen for graphicsview
> 
> Many thanks for Richard for stepping up for the overall maintainership. +1 for 
> him as maintainer.
> 
> Then it's Richard's job to ACK the sub-maintainers, though it looks to me that 
> all of them would be "duh, of course".
> 
> -- 
> 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 laszlo.agocs at qt.io  Wed Aug  2 09:18:50 2017
From: laszlo.agocs at qt.io (Laszlo Agocs)
Date: Wed, 2 Aug 2017 07:18:50 +0000
Subject: [Development] Screen mirroring
In-Reply-To: <035f3d4a-9baa-845a-e1e0-65b4eddc2ed0@free-electrons.com>
References: <035f3d4a-9baa-845a-e1e0-65b4eddc2ed0@free-electrons.com>
Message-ID: <DB6PR02MB31267A6E506A6037854FBFAA87B00@DB6PR02MB3126.eurprd02.prod.outlook.com>

Hi,

Don't you need to duplicate the drmModePageFlip call too? drmModeSetCrtc is called only once. Other than that it should be alright conceptually (as long as the two screens support the same mode). Proper plumbing with config file support can get more complicated, of course. There is some work planned/on-going around eglfs_kms (see umbrella task at https://bugreports.qt.io/browse/QTBUG-62132 ) which could provide this (configurable cloning) as well, but all that won't land before 5.11 at earliest. So current versions need custom patches for the time being.

Cheers,
Laszlo
 

-----Original Message-----
From: Development [mailto:development-bounces+laszlo.agocs=qt.io at qt-project.org] On Behalf Of Quentin Schulz
Sent: onsdag 2. august 2017 08.34
To: development at qt-project.org
Cc: Thomas Petazzoni <thomas.petazzoni at free-electrons.com>; Boris Brezillon <boris.brezillon at free-electrons.com>; Alexandre Belloni <alexandre.belloni at free-electrons.com>
Subject: [Development] Screen mirroring

Hi all,

I'm currently working on getting screen mirroring working on an iMX6Q with Qt5.8 and eglfs plugin.

On this SoC, there is an IPU (Image Processing Unit) which has two DI (Display Interface). The DI is connected to encoders (HDMI and LVDS in our case) and can each handle one screen. It is my understanding that a DI can be assimilated as a CRTC.

We use the eglfs plugin (via -platform) with kms back-end.

I'm able to display content on the two screens connected to the HDMI and LVDS with Qt5_Cinematicexperience (one screen at a time) or quickmwtest[1] (both screens at the same time, but different images) thanks to a JSON file I specify with QT_QPA_EGLFS_KMS_CONFIG.

What I would like to achieve is to have the same image on both screens at the same time (same resolution of 1024x768 limited by the LVDS) without having to code the application to explicitly "copy" what is displayed on one screen to the other.

I managed to achieve this goal by using the same framebuffer for both CRTCs. I basically added a drmModeSetCrtc to QEglFSKmsGbmScreen::flip[2] with hardcoded connectors and CRTCs ids. See horrible patch here[3].

Is it (using the same framebuffer for both CRTCs) the right way to do it? How do you see it being implemented? I guess that we should also adapt the JSON file to be able to specify screen mirroring.

Else, what do you suggest?

Thanks,
Quentin

[1] https://github.com/alpqr/quickmwtest
[2]
https://git.qt.io/consulting-usa/qtbase-xcb-rendering/blob/dev/src/plugins/platforms/eglfs/deviceintegration/eglfs_kms/qeglfskmsgbmscreen.cpp#L193
[3] http://code.bulix.org/vs6d7z-176162
--
Quentin Schulz, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
_______________________________________________
Development mailing list
Development at qt-project.org
http://lists.qt-project.org/mailman/listinfo/development


From lorn.potter at gmail.com  Wed Aug  2 23:10:18 2017
From: lorn.potter at gmail.com (Lorn Potter)
Date: Thu, 3 Aug 2017 07:10:18 +1000
Subject: [Development] Give reviewers ample time to respond
In-Reply-To: <AM4PR02MB32508DB7315412B0855FFBE298B30@AM4PR02MB3250.eurprd02.prod.outlook.com>
References: <AM4PR02MB32508DB7315412B0855FFBE298B30@AM4PR02MB3250.eurprd02.prod.outlook.com>
Message-ID: <FC1C4C29-8101-4A1B-BDFE-97448DA3122C@gmail.com>


> On 1 Aug 2017, at 10:44 pm, Kai Koehne <kai.koehne at qt.io> wrote:
> 
> I'd like to remind everyone about our commit policy: https://wiki.qt.io/Review_Policy . In particular, it says 'Give reviewers ample time to respond', which is assumed to be a full working day minimum (preferably two days). 
> 
> That is, even if you have a +2 by an approver, you should _not_ stage immediately if there are other reviewers who haven't given feedback yet.

+1
I have often woken up to see changes pushed through over (my) night that I wish I had a chance to comment on, or at least be given the chance to even be aware of some change before it’s been integrated.

There also might be reviewers not listed for review that might want to comment.

I also understand some P0/urgent changes might need to be rushed through.

From patrickkidd at gmail.com  Thu Aug  3 04:54:51 2017
From: patrickkidd at gmail.com (Patrick Stinson)
Date: Wed, 2 Aug 2017 19:54:51 -0700
Subject: [Development] Erroneous Qt TouchBegin event to QGraphicsView ?
Message-ID: <2F8B3E9B-254E-4AC8-87F3-9413469B794B@gmail.com>

Hi there!

I am seeing a QEvent::TouchBegin being sent to the QGraphicsView viewport (on Mac) when moving the mouse into or out of the view with no buttons pressed. I noticed this because if a QLineEdit somewhere else on the window, and then I move the mouse over the view, the line edit loses focus within the last line in the following code block in Application::notify, where “widget” is the QGraphicsView viewport.

At other times this same block is called (indicating a TouchBegin event) when I simply move the mouse outside the view again.

What gives? The stack trace doesn’t include the generation of the touch event so I can’t infer the conceptual policy here. Seems like line edit should at least retain focus when not clicking or dragging anywhere.

Thank you!

    case QEvent::TouchBegin:
    // Note: TouchUpdate and TouchEnd events are never propagated
    {
        QWidget *widget = static_cast<QWidget *>(receiver);
        QTouchEvent *touchEvent = static_cast<QTouchEvent *>(e);
        bool eventAccepted = touchEvent->isAccepted();
        bool acceptTouchEvents = widget->testAttribute(Qt::WA_AcceptTouchEvents);

        if (acceptTouchEvents && e->spontaneous()) {
            const QPoint localPos = touchEvent->touchPoints()[0].pos().toPoint();
            QApplicationPrivate::giveFocusAccordingToFocusPolicy(widget, e, localPos);
        }
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20170802/8ab9e629/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 1403 bytes
Desc: not available
URL: <http://lists.qt-project.org/pipermail/development/attachments/20170802/8ab9e629/attachment.bin>

From frederik.gladhorn at qt.io  Thu Aug  3 09:26:45 2017
From: frederik.gladhorn at qt.io (Frederik Gladhorn)
Date: Thu, 03 Aug 2017 09:26:45 +0200
Subject: [Development] Coin infrastructure changes
In-Reply-To: <1795351.MzuLWtvgav@frederik-thinkcentre-m93p>
References: <1795351.MzuLWtvgav@frederik-thinkcentre-m93p>
Message-ID: <9955164.d3r2RMvhyB@lumpi>

Hello :)

One day late, we're attempting to switch now. For a short while things will 
take more time (we're so to speak warming up the caches right now), but 
hopefully things will be progressing as normal again.

If you see completely weird behavior, we're of course happy to hear about it.

Cheers,
Frederik

On mandag 31. juli 2017 15.19.00 CEST Frederik Gladhorn wrote:
> Hi all,
> 
> this is mostly for your information. On Wednesday this week (most likely)
> we're making changes to Coin, potentially leading to some interruptions in
> integrations.
> 
> The longer version:
> 
> We've been working towards replacing the underlying virtualization layer in
> our Continuous Integration infrastructure and have now reached a point where
> we're ready (as ready as we'll get at least) to switch over from VSphere to
> OpenNebula. There are a bunch of advantages (not least that we can actually
> debug issues in OpenNebula/KVM, it'll make the scheduling code in Coin
> easier, ...).
> 
> This will also be the point at which we start to use some of the new
> hardware that The Qt Company has been purchasing and getting ready, so
> things will initially be at the same speed and eventually much faster.
> 
> We have Qt 5.6 and 5.9 running smoothly, the dev branch currently needs some
> merges, hopefully we'll get it working really soon now.
> 
> Hopefully the process is: stop the system; change branch; restart and things
> will work. I would expect some hickups when we scale up and run in
> production mode, so bear with us and report issues, we'll eventually be
> better off, once things are in shape.
> 
> Cheers,
> Frederik
> 
> _______________________________________________
> Development mailing list
> Development at qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development




From laszlo.agocs at qt.io  Thu Aug  3 15:57:07 2017
From: laszlo.agocs at qt.io (Laszlo Agocs)
Date: Thu, 3 Aug 2017 13:57:07 +0000
Subject: [Development] Screen mirroring
In-Reply-To: <DB6PR02MB31267A6E506A6037854FBFAA87B00@DB6PR02MB3126.eurprd02.prod.outlook.com>
References: <035f3d4a-9baa-845a-e1e0-65b4eddc2ed0@free-electrons.com>,
	<DB6PR02MB31267A6E506A6037854FBFAA87B00@DB6PR02MB3126.eurprd02.prod.outlook.com>
Message-ID: <DB6PR02MB3126998FEEB03E7509EEF21887B10@DB6PR02MB3126.eurprd02.prod.outlook.com>

There's now a patch in https://codereview.qt-project.org/#/c/201604/ demonstrating the concept. (only tried with 2 screens on Mesa 17 on Intel) It is against dev and part of bigger patch set, and will not apply to 5.8 for sure. But could be helpful.


Cheers,

Laszlo


________________________________
From: Development <development-bounces+laszlo.agocs=qt.io at qt-project.org> on behalf of Laszlo Agocs <laszlo.agocs at qt.io>
Sent: Wednesday, August 2, 2017 9:18:50 AM
To: Quentin Schulz; development at qt-project.org
Cc: Thomas Petazzoni; Boris Brezillon; Alexandre Belloni
Subject: Re: [Development] Screen mirroring

Hi,

Don't you need to duplicate the drmModePageFlip call too? drmModeSetCrtc is called only once. Other than that it should be alright conceptually (as long as the two screens support the same mode). Proper plumbing with config file support can get more complicated, of course. There is some work planned/on-going around eglfs_kms (see umbrella task at https://bugreports.qt.io/browse/QTBUG-62132 ) which could provide this (configurable cloning) as well, but all that won't land before 5.11 at earliest. So current versions need custom patches for the time being.

Cheers,
Laszlo


-----Original Message-----
From: Development [mailto:development-bounces+laszlo.agocs=qt.io at qt-project.org] On Behalf Of Quentin Schulz
Sent: onsdag 2. august 2017 08.34
To: development at qt-project.org
Cc: Thomas Petazzoni <thomas.petazzoni at free-electrons.com>; Boris Brezillon <boris.brezillon at free-electrons.com>; Alexandre Belloni <alexandre.belloni at free-electrons.com>
Subject: [Development] Screen mirroring

Hi all,

I'm currently working on getting screen mirroring working on an iMX6Q with Qt5.8 and eglfs plugin.

On this SoC, there is an IPU (Image Processing Unit) which has two DI (Display Interface). The DI is connected to encoders (HDMI and LVDS in our case) and can each handle one screen. It is my understanding that a DI can be assimilated as a CRTC.

We use the eglfs plugin (via -platform) with kms back-end.

I'm able to display content on the two screens connected to the HDMI and LVDS with Qt5_Cinematicexperience (one screen at a time) or quickmwtest[1] (both screens at the same time, but different images) thanks to a JSON file I specify with QT_QPA_EGLFS_KMS_CONFIG.

What I would like to achieve is to have the same image on both screens at the same time (same resolution of 1024x768 limited by the LVDS) without having to code the application to explicitly "copy" what is displayed on one screen to the other.

I managed to achieve this goal by using the same framebuffer for both CRTCs. I basically added a drmModeSetCrtc to QEglFSKmsGbmScreen::flip[2] with hardcoded connectors and CRTCs ids. See horrible patch here[3].

Is it (using the same framebuffer for both CRTCs) the right way to do it? How do you see it being implemented? I guess that we should also adapt the JSON file to be able to specify screen mirroring.

Else, what do you suggest?

Thanks,
Quentin

[1] https://github.com/alpqr/quickmwtest
[2]
https://git.qt.io/consulting-usa/qtbase-xcb-rendering/blob/dev/src/plugins/platforms/eglfs/deviceintegration/eglfs_kms/qeglfskmsgbmscreen.cpp#L193
[3] http://code.bulix.org/vs6d7z-176162
--
Quentin Schulz, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
_______________________________________________
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: <http://lists.qt-project.org/pipermail/development/attachments/20170803/f6138bd8/attachment.html>

From laszlo.agocs at qt.io  Thu Aug  3 15:58:05 2017
From: laszlo.agocs at qt.io (Laszlo Agocs)
Date: Thu, 3 Aug 2017 13:58:05 +0000
Subject: [Development] Screen mirroring
In-Reply-To: <DB6PR02MB3126998FEEB03E7509EEF21887B10@DB6PR02MB3126.eurprd02.prod.outlook.com>
References: <035f3d4a-9baa-845a-e1e0-65b4eddc2ed0@free-electrons.com>,
	<DB6PR02MB31267A6E506A6037854FBFAA87B00@DB6PR02MB3126.eurprd02.prod.outlook.com>,
	<DB6PR02MB3126998FEEB03E7509EEF21887B10@DB6PR02MB3126.eurprd02.prod.outlook.com>
Message-ID: <DB6PR02MB31266792BC8620DCD155B84387B10@DB6PR02MB3126.eurprd02.prod.outlook.com>

Ouch, wrong link. The correct one is https://codereview.qt-project.org/#/c/201648/


Laszlo

________________________________
From: Development <development-bounces+laszlo.agocs=qt.io at qt-project.org> on behalf of Laszlo Agocs <laszlo.agocs at qt.io>
Sent: Thursday, August 3, 2017 3:57 PM
To: Quentin Schulz; development at qt-project.org
Cc: Thomas Petazzoni; Boris Brezillon; Alexandre Belloni
Subject: Re: [Development] Screen mirroring


There's now a patch in https://codereview.qt-project.org/#/c/201604/ demonstrating the concept. (only tried with 2 screens on Mesa 17 on Intel) It is against dev and part of bigger patch set, and will not apply to 5.8 for sure. But could be helpful.


Cheers,

Laszlo


________________________________
From: Development <development-bounces+laszlo.agocs=qt.io at qt-project.org> on behalf of Laszlo Agocs <laszlo.agocs at qt.io>
Sent: Wednesday, August 2, 2017 9:18:50 AM
To: Quentin Schulz; development at qt-project.org
Cc: Thomas Petazzoni; Boris Brezillon; Alexandre Belloni
Subject: Re: [Development] Screen mirroring

Hi,

Don't you need to duplicate the drmModePageFlip call too? drmModeSetCrtc is called only once. Other than that it should be alright conceptually (as long as the two screens support the same mode). Proper plumbing with config file support can get more complicated, of course. There is some work planned/on-going around eglfs_kms (see umbrella task at https://bugreports.qt.io/browse/QTBUG-62132 ) which could provide this (configurable cloning) as well, but all that won't land before 5.11 at earliest. So current versions need custom patches for the time being.

Cheers,
Laszlo


-----Original Message-----
From: Development [mailto:development-bounces+laszlo.agocs=qt.io at qt-project.org] On Behalf Of Quentin Schulz
Sent: onsdag 2. august 2017 08.34
To: development at qt-project.org
Cc: Thomas Petazzoni <thomas.petazzoni at free-electrons.com>; Boris Brezillon <boris.brezillon at free-electrons.com>; Alexandre Belloni <alexandre.belloni at free-electrons.com>
Subject: [Development] Screen mirroring

Hi all,

I'm currently working on getting screen mirroring working on an iMX6Q with Qt5.8 and eglfs plugin.

On this SoC, there is an IPU (Image Processing Unit) which has two DI (Display Interface). The DI is connected to encoders (HDMI and LVDS in our case) and can each handle one screen. It is my understanding that a DI can be assimilated as a CRTC.

We use the eglfs plugin (via -platform) with kms back-end.

I'm able to display content on the two screens connected to the HDMI and LVDS with Qt5_Cinematicexperience (one screen at a time) or quickmwtest[1] (both screens at the same time, but different images) thanks to a JSON file I specify with QT_QPA_EGLFS_KMS_CONFIG.

What I would like to achieve is to have the same image on both screens at the same time (same resolution of 1024x768 limited by the LVDS) without having to code the application to explicitly "copy" what is displayed on one screen to the other.

I managed to achieve this goal by using the same framebuffer for both CRTCs. I basically added a drmModeSetCrtc to QEglFSKmsGbmScreen::flip[2] with hardcoded connectors and CRTCs ids. See horrible patch here[3].

Is it (using the same framebuffer for both CRTCs) the right way to do it? How do you see it being implemented? I guess that we should also adapt the JSON file to be able to specify screen mirroring.

Else, what do you suggest?

Thanks,
Quentin

[1] https://github.com/alpqr/quickmwtest
[2]
https://git.qt.io/consulting-usa/qtbase-xcb-rendering/blob/dev/src/plugins/platforms/eglfs/deviceintegration/eglfs_kms/qeglfskmsgbmscreen.cpp#L193
[3] http://code.bulix.org/vs6d7z-176162
--
Quentin Schulz, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
_______________________________________________
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: <http://lists.qt-project.org/pipermail/development/attachments/20170803/e5a80b73/attachment.html>

From andreas.aardal.hanssen at gmail.com  Thu Aug  3 17:40:57 2017
From: andreas.aardal.hanssen at gmail.com (Andreas Aardal Hanssen)
Date: Thu, 3 Aug 2017 17:40:57 +0200
Subject: [Development] Erroneous Qt TouchBegin event to QGraphicsView ?
In-Reply-To: <2F8B3E9B-254E-4AC8-87F3-9413469B794B@gmail.com>
References: <2F8B3E9B-254E-4AC8-87F3-9413469B794B@gmail.com>
Message-ID: <2A9DF7A0-19F8-4B93-B156-8993854BC665@gmail.com>


> 3. aug. 2017 kl. 04.54 skrev Patrick Stinson <patrickkidd at gmail.com>:
> Hi there!
> I am seeing a QEvent::TouchBegin being sent to the QGraphicsView viewport (on Mac) when moving the mouse into or out of the view with no buttons pressed. I noticed this because if a QLineEdit somewhere else on the window, and then I move the mouse over the view, the line edit loses focus within the last line in the following code block in Application::notify, where “widget” is the QGraphicsView viewport.
> At other times this same block is called (indicating a TouchBegin event) when I simply move the mouse outside the view again.
> What gives? The stack trace doesn’t include the generation of the touch event so I can’t infer the conceptual policy here. Seems like line edit should at least retain focus when not clicking or dragging anywhere.

Hi Patrick, if you file a bug on bugreports.qt.io with the above info, we can track it and see if someone can find the cause of the error you are seeing. If can be anything from phantom touch events from your Mac to bugs in application or library or system software. Best we try to isolate the error. (qt-development is more for discussion on the development of Qt, than use of it). :-)

Andreas

From patrickkidd at gmail.com  Thu Aug  3 18:43:51 2017
From: patrickkidd at gmail.com (Patrick Stinson)
Date: Thu, 3 Aug 2017 09:43:51 -0700
Subject: [Development] Erroneous Qt TouchBegin event to QGraphicsView ?
In-Reply-To: <2A9DF7A0-19F8-4B93-B156-8993854BC665@gmail.com>
References: <2F8B3E9B-254E-4AC8-87F3-9413469B794B@gmail.com>
	<2A9DF7A0-19F8-4B93-B156-8993854BC665@gmail.com>
Message-ID: <B14E31ED-F5BF-4D43-AC26-69FB3BCCB283@gmail.com>

OK, thanks. I have filed bug reports before but am not sure where the line between bug discovery and bug reporting is. For example in this case I am partly asking if widget focus is supposed to work this way to avoid a superfluous bug report. But it sounds like I should just report based on my judgement in the future?

Thanks!


> On Aug 3, 2017, at 8:40 AM, Andreas Aardal Hanssen <andreas.aardal.hanssen at gmail.com> wrote:
> 
> 
>> 3. aug. 2017 kl. 04.54 skrev Patrick Stinson <patrickkidd at gmail.com>:
>> Hi there!
>> I am seeing a QEvent::TouchBegin being sent to the QGraphicsView viewport (on Mac) when moving the mouse into or out of the view with no buttons pressed. I noticed this because if a QLineEdit somewhere else on the window, and then I move the mouse over the view, the line edit loses focus within the last line in the following code block in Application::notify, where “widget” is the QGraphicsView viewport.
>> At other times this same block is called (indicating a TouchBegin event) when I simply move the mouse outside the view again.
>> What gives? The stack trace doesn’t include the generation of the touch event so I can’t infer the conceptual policy here. Seems like line edit should at least retain focus when not clicking or dragging anywhere.
> 
> Hi Patrick, if you file a bug on bugreports.qt.io with the above info, we can track it and see if someone can find the cause of the error you are seeing. If can be anything from phantom touch events from your Mac to bugs in application or library or system software. Best we try to isolate the error. (qt-development is more for discussion on the development of Qt, than use of it). :-)
> 
> Andreas
> _______________________________________________
> Development mailing list
> Development at qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 1403 bytes
Desc: not available
URL: <http://lists.qt-project.org/pipermail/development/attachments/20170803/ecb7c5b8/attachment.bin>

From edward.welbourne at qt.io  Fri Aug  4 11:10:20 2017
From: edward.welbourne at qt.io (Edward Welbourne)
Date: Fri, 4 Aug 2017 09:10:20 +0000
Subject: [Development] Erroneous Qt TouchBegin event to QGraphicsView ?
In-Reply-To: <B14E31ED-F5BF-4D43-AC26-69FB3BCCB283@gmail.com>
References: <2F8B3E9B-254E-4AC8-87F3-9413469B794B@gmail.com>
	<2A9DF7A0-19F8-4B93-B156-8993854BC665@gmail.com>,
	<B14E31ED-F5BF-4D43-AC26-69FB3BCCB283@gmail.com>
Message-ID: <AM4PR02MB3249144AED8F11524AD1D25087B60@AM4PR02MB3249.eurprd02.prod.outlook.com>

Patrick Stinson (3 August 2017 18:43)
> I have filed bug reports before but am not sure where the line between
> bug discovery and bug reporting is. For example in this case I am
> partly asking if widget focus is supposed to work this way to avoid a
> superfluous bug report. But it sounds like I should just report based
> on my judgement in the future?

As a rough rule of thumb, if the software's behaviour violates the [0]
principle of least surprise - e.g. by doing something weird that's not
what you expected - and you can't find documentation that overtly says
that's what you should have expected, then it's worth reporting.  It
might just be that we neglected to document it, or the documentation was
too hard to find, but even then we need the bug report, to fix that.  In
other cases, it'll mean the software is wrong - the more traditional bug.

[0] https://en.wikipedia.org/wiki/Principle_of_least_astonishment
(OK, so it has aliases)

	Eddy.


From jedrzej.nowacki at qt.io  Fri Aug  4 11:55:48 2017
From: jedrzej.nowacki at qt.io (=?utf-8?B?SsSZZHJ6ZWo=?= Nowacki)
Date: Fri, 04 Aug 2017 11:55:48 +0200
Subject: [Development] CI has infra problems
In-Reply-To: <2440538.JxO7cD1VFa@tjmaciei-mobl1>
References: <VI1PR02MB111940969B06BD683996A8B692B30@VI1PR02MB1119.eurprd02.prod.outlook.com>
	<VI1PR02MB11194865DA341947E73552DB92B30@VI1PR02MB1119.eurprd02.prod.outlook.com>
	<2440538.JxO7cD1VFa@tjmaciei-mobl1>
Message-ID: <3396187.GrxWG9D24D@42>

On tirsdag 1. august 2017 15.11.38 CEST Thiago Macieira wrote:
> No, another problem has now appeared:
> 
>  Module "qt/qtbase" (34adca0607ff9231b4c79949353827c1c8319c52) Failed
> repeatedly to launch build/test agent:
>  Failed 7 times to acquire the hardware
>          buildKey: qt/qtbase/eab0f32365c02540893fd3d1d75c2af2b4e6f6e8/
> LinuxUbuntu_16_04x86_64LinuxUbuntu_16_04x86_64GCCqtci-linux-Ubuntu-16.04-
> x86_64-1-bd2be3TestOnly_LicenseCheck/7ca30f915833d953146007e71743147e3e71950
> 0/ Test
>          agentLaunchRequest: AgentLaunchRequest(machineType=0,
> testConfiguration=TestConfiguration(testHack=None, features=[8, 7],
> vmTemplate='qtci-linux-Ubuntu-16.04-x86_64-1-bd2be3', configureArgs=None,
> toolsets=[Toolset(targetSourceDirectory='qt/qtqa-latest', branch='master',
> excludeSubModules=None,
> repositoryState=RepositoryState(sha1='f2fea571b9e17dc31eff349f6b744603c670dc
> d6', project='qt/qtqa',
> contentSha1='2e26fde8a7db0bb8e81edb44509ea8a64d257e1a', dependencies=[],
> gerritInstance='qt-project'), sourceOnly=True)],
> target=Machine(os=1, arch='x86_64', os_version=304, compiler=0),
> host=Machine(os=1, arch='x86_64', os_version=304, compiler=0), type=0),
> productVersion='5.9', buildKey='qt/qtbase/
> eab0f32365c02540893fd3d1d75c2af2b4e6f6e8/
> LinuxUbuntu_16_04x86_64LinuxUbuntu_16_04x86_64GCCqtci-linux-Ubuntu-16.04-
> x86_64-1-bd2be3TestOnly_LicenseCheck/7ca30f915833d953146007e71743147e3e71950
> 0/ Test', vmTemplate='qtci-linux-Ubuntu-16.04-x86_64-1-bd2be3', type=1)
> reasons:

Hi,

  So this kind of things should be fixed now.

Cheers,
  Jędrek


From patrickkidd at gmail.com  Fri Aug  4 14:35:39 2017
From: patrickkidd at gmail.com (Patrick Stinson)
Date: Fri, 4 Aug 2017 05:35:39 -0700
Subject: [Development] Erroneous Qt TouchBegin event to QGraphicsView ?
In-Reply-To: <AM4PR02MB3249144AED8F11524AD1D25087B60@AM4PR02MB3249.eurprd02.prod.outlook.com>
References: <2F8B3E9B-254E-4AC8-87F3-9413469B794B@gmail.com>
	<2A9DF7A0-19F8-4B93-B156-8993854BC665@gmail.com>
	<B14E31ED-F5BF-4D43-AC26-69FB3BCCB283@gmail.com>
	<AM4PR02MB3249144AED8F11524AD1D25087B60@AM4PR02MB3249.eurprd02.prod.outlook.com>
Message-ID: <AB698A6B-5036-43F0-B590-BC9FDCB3589F@gmail.com>

Perfect, thank you Edward.

> On Aug 4, 2017, at 2:10 AM, Edward Welbourne <edward.welbourne at qt.io> wrote:
> 
> Patrick Stinson (3 August 2017 18:43)
>> I have filed bug reports before but am not sure where the line between
>> bug discovery and bug reporting is. For example in this case I am
>> partly asking if widget focus is supposed to work this way to avoid a
>> superfluous bug report. But it sounds like I should just report based
>> on my judgement in the future?
> 
> As a rough rule of thumb, if the software's behaviour violates the [0]
> principle of least surprise - e.g. by doing something weird that's not
> what you expected - and you can't find documentation that overtly says
> that's what you should have expected, then it's worth reporting.  It
> might just be that we neglected to document it, or the documentation was
> too hard to find, but even then we need the bug report, to fix that.  In
> other cases, it'll mean the software is wrong - the more traditional bug.
> 
> [0] https://en.wikipedia.org/wiki/Principle_of_least_astonishment
> (OK, so it has aliases)
> 
>    Eddy.


From paul at smedley.id.au  Sat Aug  5 03:48:00 2017
From: paul at smedley.id.au (Paul Smedley)
Date: Sat, 5 Aug 2017 11:18:00 +0930
Subject: [Development] Updating community Qt4 port for OS/2 to Qt5
Message-ID: <om3849$eoo$1@blaine.gmane.org>

Hi All,

You may or may not be aware, that OS/2 has a Qt port that is currently 
at v4.7.3 (http://trac.netlabs.org/qt4)

This project has stagnated for time, but I need at least Qt 4.8.x for 
Wireshark 2.4.0 - so I've started looking at updating.

I have Qt 4.8.x building, with a few nits still to resolve.

I next want to look at building Qt 5.x.  I see that the way the OS 
specific GUI code is handled has changed significantly, instead of files 
like:
src\gui\kernel\*win.cpp

We now have all the OS specific files in (for eg)
qtbase\src\plugins\platforms\windows\*.cpp

Are there any tips on porting a platform from Qt 4.x to 5.x?

Is it likely that much of the GUI code can be re-used (albeit the file 
structure is different)?

Thanks in advance,

Paul



From kde at carewolf.com  Sat Aug  5 08:49:23 2017
From: kde at carewolf.com (Allan Sandfeld Jensen)
Date: Sat, 05 Aug 2017 08:49:23 +0200
Subject: [Development] Updating community Qt4 port for OS/2 to Qt5
In-Reply-To: <om3849$eoo$1@blaine.gmane.org>
References: <om3849$eoo$1@blaine.gmane.org>
Message-ID: <1569353.DBGdkthYmP@twilight>

On Samstag, 5. August 2017 03:48:00 CEST Paul Smedley wrote:
> Hi All,
> 
> You may or may not be aware, that OS/2 has a Qt port that is currently
> at v4.7.3 (http://trac.netlabs.org/qt4)
> 
> This project has stagnated for time, but I need at least Qt 4.8.x for
> Wireshark 2.4.0 - so I've started looking at updating.
> 
> I have Qt 4.8.x building, with a few nits still to resolve.
> 
> I next want to look at building Qt 5.x.  I see that the way the OS
> specific GUI code is handled has changed significantly, instead of files
> like:
> src\gui\kernel\*win.cpp
> 
> We now have all the OS specific files in (for eg)
> qtbase\src\plugins\platforms\windows\*.cpp
> 
> Are there any tips on porting a platform from Qt 4.x to 5.x?
> 
> Is it likely that much of the GUI code can be re-used (albeit the file
> structure is different)?
> 
A lot of the GUI code probably won't be relevant and won't need to be ported. 
I can see they have their own QPixmap type, but since 4.8 the raster engine is 
used for pixmaps, and that code can be removed. The same will apply to any 
native paint-engine.

Best regards
'Allan


From paul at smedley.id.au  Sat Aug  5 11:41:06 2017
From: paul at smedley.id.au (Paul Smedley)
Date: Sat, 5 Aug 2017 19:11:06 +0930
Subject: [Development] Updating community Qt4 port for OS/2 to Qt5
In-Reply-To: <1569353.DBGdkthYmP@twilight>
References: <om3849$eoo$1@blaine.gmane.org> <1569353.DBGdkthYmP@twilight>
Message-ID: <om43rb$evg$1@blaine.gmane.org>

Hi Allan!!

On 05/08/17 16:19, Allan Sandfeld Jensen wrote:
> On Samstag, 5. August 2017 03:48:00 CEST Paul Smedley wrote:
>> Hi All,
>>
>> You may or may not be aware, that OS/2 has a Qt port that is currently
>> at v4.7.3 (http://trac.netlabs.org/qt4)
>>
>> This project has stagnated for time, but I need at least Qt 4.8.x for
>> Wireshark 2.4.0 - so I've started looking at updating.
>>
>> I have Qt 4.8.x building, with a few nits still to resolve.
>>
>> I next want to look at building Qt 5.x.  I see that the way the OS
>> specific GUI code is handled has changed significantly, instead of files
>> like:
>> src\gui\kernel\*win.cpp
>>
>> We now have all the OS specific files in (for eg)
>> qtbase\src\plugins\platforms\windows\*.cpp
>>
>> Are there any tips on porting a platform from Qt 4.x to 5.x?
>>
>> Is it likely that much of the GUI code can be re-used (albeit the file
>> structure is different)?
>>
> A lot of the GUI code probably won't be relevant and won't need to be ported.
> I can see they have their own QPixmap type, but since 4.8 the raster engine is
> used for pixmaps, and that code can be removed. The same will apply to any
> native paint-engine.

Thanks for the reply. Any hints on the minimal files necessary for gui 
apps to work. At this stage, I'm not fussed about clipboard, drag and 
drop, etc, just the bare minimal to get gui apps working.

Cheers,

Paul



From soroush.rabiei at gmail.com  Sat Aug  5 14:08:23 2017
From: soroush.rabiei at gmail.com (Soroush Rabiei)
Date: Sat, 5 Aug 2017 16:38:23 +0430
Subject: [Development]  Calendar Systems proposal
In-Reply-To: <HE1PR0202MB2683F0D2023EE4E8B087751387440@HE1PR0202MB2683.eurprd02.prod.outlook.com>
References: <CAOMsk2Qn+kSmpLmadHT9i-_SW0mbNBgCKBUh1erW0hvmyiqVDw@mail.gmail.com>
	<CAOMsk2RTpwdqDT6sBSTSMSLRLwyGeCM4FMC6AiHL44KnVw9FRw@mail.gmail.com>
	<8680F22F-7B32-4DDD-9380-8EE517C10830@qt.io>
	<29088300.rDUCxivhrG@port-fma>
	<FF3422F2-66BD-4A5C-93E7-0771AFBB895B@qt.io>
	<HE1PR0202MB2683F0D2023EE4E8B087751387440@HE1PR0202MB2683.eurprd02.prod.outlook.com>
Message-ID: <CAOMsk2TRhSoMQKDbWgmHqOuQMCa7LNLrO4ZD=_+1SgT6nRdegw@mail.gmail.com>

I believe our proposed change (containing locale backend , date and time
classes and related widgets) is ready to be merged (maybe after some minor
improvements)

I would like to ask someone to review this change:

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

Cheers,
Soroush
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20170805/d0deb3bb/attachment.html>

From robin.burchell at crimson.no  Sat Aug  5 14:58:44 2017
From: robin.burchell at crimson.no (Robin Burchell)
Date: Sat, 05 Aug 2017 14:58:44 +0200
Subject: [Development] Updating community Qt4 port for OS/2 to Qt5
In-Reply-To: <om43rb$evg$1@blaine.gmane.org>
References: <om3849$eoo$1@blaine.gmane.org> <1569353.DBGdkthYmP@twilight>
	<om43rb$evg$1@blaine.gmane.org>
Message-ID: <1501937924.2846249.1064030752.2184270C@webmail.messagingengine.com>

On Sat, Aug 5, 2017, at 11:41 AM, Paul Smedley wrote:
> Thanks for the reply. Any hints on the minimal files necessary for gui 
> apps to work. At this stage, I'm not fussed about clipboard, drag and 
> drop, etc, just the bare minimal to get gui apps working.

Hi Paul,

So the basic idea you've probably already gathered is that each platform
needs to implement a "QPA" plugin:
https://wiki.qt.io/Getting_Started_With_Lighthouse covers some of the
basics here, but in a little more detail:

A QPA plugin provides the glue for things like windowing and input
between Qt and a native windowing system. To start with, take a look at
the 'minimal' QPA plugin (which just does software rendering, AFAIR
directed to image files on disk), and look at how to fill in things from
there -- the starting points you'll want are a QPlatformIntegration,
QPlatformWindow, and QPlatformBackingStore. You want to look at
QWindowSystemInterface to deliver events (like expose events saying
"please start/stop rendering the window", and input events) from your
QPA plugin to QtGui.

What you want past there is a bit more fuzzy and depends both on how
complete you want your integration to be and what your platform
provides, e.g. QPlatformClipboard and stuff like that, but I'd put most
of that stuff in the "optional extras" basket.

As you've already figured out, the structure and code involved is quite
different, so I doubt it'll be a 1:1 port - but the existing plugins
provide pretty good guidance on how to lay things out, and your existing
code would be adaptable without too much work I think.

Good luck,
Robin

-- 
  Robin Burchell
  robin at crimson.no


From thiago.macieira at intel.com  Sat Aug  5 18:14:43 2017
From: thiago.macieira at intel.com (Thiago Macieira)
Date: Sat, 05 Aug 2017 09:14:43 -0700
Subject: [Development] Calendar Systems proposal
In-Reply-To: <CAOMsk2TRhSoMQKDbWgmHqOuQMCa7LNLrO4ZD=_+1SgT6nRdegw@mail.gmail.com>
References: <CAOMsk2Qn+kSmpLmadHT9i-_SW0mbNBgCKBUh1erW0hvmyiqVDw@mail.gmail.com>
	<HE1PR0202MB2683F0D2023EE4E8B087751387440@HE1PR0202MB2683.eurprd02.prod.outlook.com>
	<CAOMsk2TRhSoMQKDbWgmHqOuQMCa7LNLrO4ZD=_+1SgT6nRdegw@mail.gmail.com>
Message-ID: <4336862.rKUTIhz69Y@tjmaciei-mobl1>

On Saturday, 5 August 2017 05:08:23 PDT Soroush Rabiei wrote:
> I believe our proposed change (containing locale backend , date and time
> classes and related widgets) is ready to be merged (maybe after some minor
> improvements)
> 
> I would like to ask someone to review this change:
> 
> https://codereview.qt-project.org/#/c/182341/

Will do, but it's a bit too late for the feature freeze in 3 days...

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center



From paul at smedley.id.au  Sun Aug  6 00:08:37 2017
From: paul at smedley.id.au (Paul Smedley)
Date: Sun, 6 Aug 2017 07:38:37 +0930
Subject: [Development] Updating community Qt4 port for OS/2 to Qt5
In-Reply-To: <1501937924.2846249.1064030752.2184270C@webmail.messagingengine.com>
References: <om3849$eoo$1@blaine.gmane.org> <1569353.DBGdkthYmP@twilight>
	<om43rb$evg$1@blaine.gmane.org>
	<1501937924.2846249.1064030752.2184270C@webmail.messagingengine.com>
Message-ID: <om5fkv$dov$1@blaine.gmane.org>

Hi Robin,

On 05/08/17 22:28, Robin Burchell wrote:
> On Sat, Aug 5, 2017, at 11:41 AM, Paul Smedley wrote:
>> Thanks for the reply. Any hints on the minimal files necessary for gui
>> apps to work. At this stage, I'm not fussed about clipboard, drag and
>> drop, etc, just the bare minimal to get gui apps working.
> 
> Hi Paul,
> 
> So the basic idea you've probably already gathered is that each platform
> needs to implement a "QPA" plugin:
> https://wiki.qt.io/Getting_Started_With_Lighthouse covers some of the
> basics here, but in a little more detail:
> 
> A QPA plugin provides the glue for things like windowing and input
> between Qt and a native windowing system. To start with, take a look at
> the 'minimal' QPA plugin (which just does software rendering, AFAIR
> directed to image files on disk), and look at how to fill in things from
> there -- the starting points you'll want are a QPlatformIntegration,
> QPlatformWindow, and QPlatformBackingStore. You want to look at
> QWindowSystemInterface to deliver events (like expose events saying
> "please start/stop rendering the window", and input events) from your
> QPA plugin to QtGui.
> 
> What you want past there is a bit more fuzzy and depends both on how
> complete you want your integration to be and what your platform
> provides, e.g. QPlatformClipboard and stuff like that, but I'd put most
> of that stuff in the "optional extras" basket.
> 
> As you've already figured out, the structure and code involved is quite
> different, so I doubt it'll be a 1:1 port - but the existing plugins
> provide pretty good guidance on how to lay things out, and your existing
> code would be adaptable without too much work I think.

Thanks - this is the kind of this I was looking for. Appreciate the tips!

Cheers,

Paul



From thiago.macieira at intel.com  Mon Aug  7 05:32:06 2017
From: thiago.macieira at intel.com (Thiago Macieira)
Date: Sun, 06 Aug 2017 20:32:06 -0700
Subject: [Development] Qt 5.10 schedule etc
In-Reply-To: <3843172.Ly00O2OvuP@tjmaciei-mobl1>
References: <HE1PR02MB3132DFFBCCFE0E6C6061CC579DB30@HE1PR02MB3132.eurprd02.prod.outlook.com>
	<3843172.Ly00O2OvuP@tjmaciei-mobl1>
Message-ID: <4031551.E8BmmReDRo@tjmaciei-mobl1>

On Tuesday, 1 August 2017 00:18:18 PDT Thiago Macieira wrote:
> https://codereview.qt-project.org/200068
> https://codereview.qt-project.org/200072

Thanks everyone for the efforts in getting the changes in. Almost everything 
merged. The two commits above are the only remaining new features.

The remaining issues below are bugfixes and can be accepted in the stable 
branch. Or they're not important.

I have another 15 patches to submit that require either rebasing the changes 
below or their acceptance. No new features, just refactoring.

> https://codereview.qt-project.org/200074
> https://codereview.qt-project.org/199000
> https://codereview.qt-project.org/200066
> https://codereview.qt-project.org/200180
> https://codereview.qt-project.org/200924
> https://codereview.qt-project.org/200832
> https://codereview.qt-project.org/200258


-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center



From thiago.macieira at intel.com  Mon Aug  7 06:14:02 2017
From: thiago.macieira at intel.com (Thiago Macieira)
Date: Sun, 6 Aug 2017 21:14:02 -0700
Subject: [Development] Calendar Systems proposal
In-Reply-To: <CAOMsk2TRhSoMQKDbWgmHqOuQMCa7LNLrO4ZD=_+1SgT6nRdegw@mail.gmail.com>
References: <CAOMsk2Qn+kSmpLmadHT9i-_SW0mbNBgCKBUh1erW0hvmyiqVDw@mail.gmail.com>
	<HE1PR0202MB2683F0D2023EE4E8B087751387440@HE1PR0202MB2683.eurprd02.prod.outlook.com>
	<CAOMsk2TRhSoMQKDbWgmHqOuQMCa7LNLrO4ZD=_+1SgT6nRdegw@mail.gmail.com>
Message-ID: <1612751.Htp1vzdW7U@tjmaciei-mobl1>

On Saturday, 5 August 2017 05:08:23 PDT Soroush Rabiei wrote:
> I believe our proposed change (containing locale backend , date and time
> classes and related widgets) is ready to be merged (maybe after some minor
> improvements)
> 
> I would like to ask someone to review this change:
> 
> https://codereview.qt-project.org/#/c/182341/

Ok, a quick review's quick conclusions:

I mostly like your API. It looks simple and well integrated into QDateTime and 
QLocale. There are a couple of minor problems in the API itself, like 
QCalendarWidget::calendar() returning a reference. That's just wrong and needs 
work.

But there are bigger problems with the implementation, starting with 
QAbstractCalendar having a static protected QMap member. The big problem is 
how you've implemented the new API in QDateTime and QLocale. There's code 
duplication that cannot be there in QLocale, but the way you've removed the 
duplication in QDateTime also needs changing for performance reasons.

int QDate::year() const
{
    return year(QGregorianCalendar());
}

This creates a polymorphic object and makes a call that ends up delegating to 
it in

	    if (cal.julianDayToDate(jd, y, m, d))

The commit also includes changes that look like unrelated clean-ups and will 
need to be split into different commits. It's at this point lacking 
documentation and there are a couple of coding style mistakes.

In all, good work and I like how this is coming along, but it's not "ready for 
beta" right now, so it shouldn't be included in dev until after 5.11 opens for 
new features.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center



From Simon.Hausmann at qt.io  Mon Aug  7 16:56:24 2017
From: Simon.Hausmann at qt.io (Simon Hausmann)
Date: Mon, 7 Aug 2017 14:56:24 +0000
Subject: [Development] State of 5.9 and dev branches
Message-ID: <VI1PR02MB1006973243F291B3795EFA838CB50@VI1PR02MB1006.eurprd02.prod.outlook.com>

Hi,


A brief update. All qtbase branches are blocked because of https://codereview.qt-project.org/#/c/201931/ (or the lack thereof).


Once that fix is in 5.9 we'd have to merge it to qtbase dev, to unblock that (and 5.6). However that will further block qt5.git's dev

as the merge will pull in the qt5 top-level cross-compile build regression we're fighting in. In other words: What's preventing us from moving forward in https://codereview.qt-project.org/#/c/199760/ will spill over dev and block dev, but at least we may have a chance of unblocking qtbase.


Any help is welcome. (Anyone feel free to take over the network fix if there's a better one, or cancel running builds, or help with the qt5 build issue)



Simon


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20170807/25d72ad5/attachment.html>

From Simon.Hausmann at qt.io  Mon Aug  7 22:36:19 2017
From: Simon.Hausmann at qt.io (Simon Hausmann)
Date: Mon, 7 Aug 2017 20:36:19 +0000
Subject: [Development] State of 5.9 and dev branches
In-Reply-To: <VI1PR02MB1006973243F291B3795EFA838CB50@VI1PR02MB1006.eurprd02.prod.outlook.com>
References: <VI1PR02MB1006973243F291B3795EFA838CB50@VI1PR02MB1006.eurprd02.prod.outlook.com>
Message-ID: <40FAFB42-E9F2-415F-8519-FB9A543BE6FA@qt.io>

Hi,

The 5.9 fix went in. Would be most grateful if somebody could do the cherry pick and merge. I won't have a keyboard until tomorrow late morning.

Simon

On 7. Aug 2017, at 16:56, Simon Hausmann <Simon.Hausmann at qt.io<mailto:Simon.Hausmann at qt.io>> wrote:


Hi,


A brief update. All qtbase branches are blocked because of https://codereview.qt-project.org/#/c/201931/ (or the lack thereof).


Once that fix is in 5.9 we'd have to merge it to qtbase dev, to unblock that (and 5.6). However that will further block qt5.git's dev

as the merge will pull in the qt5 top-level cross-compile build regression we're fighting in. In other words: What's preventing us from moving forward in https://codereview.qt-project.org/#/c/199760/ will spill over dev and block dev, but at least we may have a chance of unblocking qtbase.


Any help is welcome. (Anyone feel free to take over the network fix if there's a better one, or cancel running builds, or help with the qt5 build issue)



Simon


_______________________________________________
Development mailing list
Development at qt-project.org<mailto:Development at qt-project.org>
http://lists.qt-project.org/mailman/listinfo/development
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20170807/e3fed9da/attachment.html>

From thiago.macieira at intel.com  Mon Aug  7 22:54:22 2017
From: thiago.macieira at intel.com (Thiago Macieira)
Date: Mon, 7 Aug 2017 13:54:22 -0700
Subject: [Development] State of 5.9 and dev branches
In-Reply-To: <40FAFB42-E9F2-415F-8519-FB9A543BE6FA@qt.io>
References: <VI1PR02MB1006973243F291B3795EFA838CB50@VI1PR02MB1006.eurprd02.prod.outlook.com>
	<40FAFB42-E9F2-415F-8519-FB9A543BE6FA@qt.io>
Message-ID: <15230927.kpuOl23eBN@tjmaciei-mobl1>

On Monday, 7 August 2017 13:36:19 PDT Simon Hausmann wrote:
> Hi,
> 
> The 5.9 fix went in. Would be most grateful if somebody could do the cherry
> pick and merge. I won't have a keyboard until tomorrow late morning.
 
5.6: https://codereview.qt-project.org/201945
dev: https://codereview.qt-project.org/201946

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center



From Simon.Hausmann at qt.io  Tue Aug  8 09:40:33 2017
From: Simon.Hausmann at qt.io (Simon Hausmann)
Date: Tue, 8 Aug 2017 07:40:33 +0000
Subject: [Development] State of 5.9 and dev branches
In-Reply-To: <15230927.kpuOl23eBN@tjmaciei-mobl1>
References: <VI1PR02MB1006973243F291B3795EFA838CB50@VI1PR02MB1006.eurprd02.prod.outlook.com>
	<40FAFB42-E9F2-415F-8519-FB9A543BE6FA@qt.io>,
	<15230927.kpuOl23eBN@tjmaciei-mobl1>
Message-ID: <DB5PR02MB0998CE62D2D71A5D371F02618C8A0@DB5PR02MB0998.eurprd02.prod.outlook.com>


Thank you Thiago, Sergio and Lars!


qtbase 5.6 and 5.9 are good again.


Simon

________________________________
From: Development <development-bounces+simon.hausmann=qt.io at qt-project.org> on behalf of Thiago Macieira <thiago.macieira at intel.com>
Sent: Monday, August 7, 2017 10:54:22 PM
To: development at qt-project.org
Subject: Re: [Development] State of 5.9 and dev branches

On Monday, 7 August 2017 13:36:19 PDT Simon Hausmann wrote:
> Hi,
>
> The 5.9 fix went in. Would be most grateful if somebody could do the cherry
> pick and merge. I won't have a keyboard until tomorrow late morning.

5.6: https://codereview.qt-project.org/201945
dev: https://codereview.qt-project.org/201946

--
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: <http://lists.qt-project.org/pipermail/development/attachments/20170808/ff38ef3d/attachment.html>

From jani.heikkinen at qt.io  Tue Aug  8 10:41:02 2017
From: jani.heikkinen at qt.io (Jani Heikkinen)
Date: Tue, 8 Aug 2017 08:41:02 +0000
Subject: [Development] Qt 5.10 schedule etc
In-Reply-To: <HE1PR02MB3132DFFBCCFE0E6C6061CC579DB30@HE1PR02MB3132.eurprd02.prod.outlook.com>
References: <HE1PR02MB3132DFFBCCFE0E6C6061CC579DB30@HE1PR02MB3132.eurprd02.prod.outlook.com>
Message-ID: <VI1PR02MB3133A14A246A2F6772E63DB89D8A0@VI1PR02MB3133.eurprd02.prod.outlook.com>

Hi all,

We should have FF & branching today. Unfortunately we are still fighting with some issues in qt5.git integration in 'dev' . That's why we haven't been able to start soft branching yet :( But that doesn't mean we will officially delay the FF ;)

So let's freeze new features for Qt 5.10 today as planned. Please don't put any new features in for 5.10 anymore. We will start soft branching immediately when issues with qt5.git integration in' dev' are solved. And we will finalize branching ~ after a week from that date when soft branching starts. So there will be still enough time to get changes in which are currently suffering these issues in dev. 

br,
Jani


________________________________________
From: Development <development-bounces+jani.heikkinen=qt.io at qt-project.org> on behalf of Jani Heikkinen <jani.heikkinen at qt.io>
Sent: Tuesday, August 1, 2017 9:55 AM
To: development at qt-project.org
Cc: releasing at qt-project.org
Subject: [Development] Qt 5.10 schedule etc

Hi all,
Kindly reminder: According to schedule we should have Qt 5.10 feature freeze after a week, see https://wiki.qt.io/Qt_5.10_Release. So it is time to do remaining finalizations to 5.10 new features now and focus to bug fixing after that. Please fill new features page now as well (https://wiki.qt.io/New_Features_in_Qt_5.10); it seems to be quite empty at the moment.

And we should start soft branching today. But as Frederik informed yesterday we are planning to do some changes to coin infrastructure during this week (see http://lists.qt-project.org/pipermail/development/2017-July/030596.html). So let's postpone the start of soft branching a bit and do it after coin infra changes are in & working. Doing one more branch just now makes these coin changes more difficult & most probably causes more delays in the future.

So the plan with 5.10 is following:
1. Let's keep the agreed ff as it is (8.8.2017)
2. Get first 5.10 binary snapshot from 'dev' out as soon as possible
3. Start soft branching (from 'dev' to '5.10') immediately after coin infra changes are in & every branch ('5.6', 5.9' & 'dev') is working ok with infra changes
4. Finalize branching (~ a week from soft branching)
5. Release Qt 5.10 alpha as soon as possible after the branching. We should be able to do this quite quickly; As usual Alpha will be src packages only and we can already create needed ones from 'dev'.
   * Most probably we should be able to deliver binary snapshot with alpha as well. If not just at same time then quite soon after the release...

br,
Jani


_______________________________________________
Development mailing list
Development at qt-project.org
http://lists.qt-project.org/mailman/listinfo/development


From Morten.Sorvig at qt.io  Tue Aug  8 12:11:13 2017
From: Morten.Sorvig at qt.io (=?iso-8859-1?Q?Morten_S=F8rvig?=)
Date: Tue, 8 Aug 2017 10:11:13 +0000
Subject: [Development] State of 5.9 and dev branches
In-Reply-To: <DB5PR02MB0998CE62D2D71A5D371F02618C8A0@DB5PR02MB0998.eurprd02.prod.outlook.com>
References: <VI1PR02MB1006973243F291B3795EFA838CB50@VI1PR02MB1006.eurprd02.prod.outlook.com>
	<40FAFB42-E9F2-415F-8519-FB9A543BE6FA@qt.io>
	<15230927.kpuOl23eBN@tjmaciei-mobl1>
	<DB5PR02MB0998CE62D2D71A5D371F02618C8A0@DB5PR02MB0998.eurprd02.prod.outlook.com>
Message-ID: <30FABC82-4A79-4DA7-BC0A-1F1C3E216337@qt.io>

Thanks for cleaning this up quickly!

When it comes to testing, do we want to go one step further and 
make the tests be completely independent of the current time? We would
like to avoid time bombs like these, and if something _is_ going to
fail at some future date we would like to know so right away.

I coded up a strawman proposal here: 
    https://codereview.qt-project.org/201989

It adds a RAII class to QTestLib that allows setting the datetime
(as returned by QDateTime) for the duration of a test function:

    QTestTimeFixer fixedTime(QDateTime(QDate(2015, 1, 1)).toMSecsSinceEpoch());

This is then used to set the date time to sometime in the past for
tst_qnetworkcookiejar, which makes the unpatched version of it pass.
Going further we could set the time to the future and verify that
the cookies expire as expected.

Morten


> On 8 Aug 2017, at 09:40, Simon Hausmann <Simon.Hausmann at qt.io> wrote:
> 
> 
> Thank you Thiago, Sergio and Lars!
> 
> qtbase 5.6 and 5.9 are good again.
> 
> Simon
> From: Development <development-bounces+simon.hausmann=qt.io at qt-project.org> on behalf of Thiago Macieira <thiago.macieira at intel.com>
> Sent: Monday, August 7, 2017 10:54:22 PM
> To: development at qt-project.org
> Subject: Re: [Development] State of 5.9 and dev branches
>  
> On Monday, 7 August 2017 13:36:19 PDT Simon Hausmann wrote:
> > Hi,
> > 
> > The 5.9 fix went in. Would be most grateful if somebody could do the cherry
> > pick and merge. I won't have a keyboard until tomorrow late morning.
>  
> 5.6: https://codereview.qt-project.org/201945
> dev: https://codereview.qt-project.org/201946
> 
> -- 
> 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 Simon.Hausmann at qt.io  Tue Aug  8 13:06:35 2017
From: Simon.Hausmann at qt.io (Simon Hausmann)
Date: Tue, 8 Aug 2017 11:06:35 +0000
Subject: [Development] State of 5.9 and dev branches
In-Reply-To: <30FABC82-4A79-4DA7-BC0A-1F1C3E216337@qt.io>
References: <VI1PR02MB1006973243F291B3795EFA838CB50@VI1PR02MB1006.eurprd02.prod.outlook.com>
	<40FAFB42-E9F2-415F-8519-FB9A543BE6FA@qt.io>
	<15230927.kpuOl23eBN@tjmaciei-mobl1>
	<DB5PR02MB0998CE62D2D71A5D371F02618C8A0@DB5PR02MB0998.eurprd02.prod.outlook.com>,
	<30FABC82-4A79-4DA7-BC0A-1F1C3E216337@qt.io>
Message-ID: <DB5PR02MB0998CE31A196B27893686B518C8A0@DB5PR02MB0998.eurprd02.prod.outlook.com>

Hi,


I think that's a good idea, although I prefer the approach of making the test adapt the expected output relative to the current time instead of replacing the library state with mock data.




Simon

________________________________
From: Development <development-bounces+simon.hausmann=qt.io at qt-project.org> on behalf of Morten Sørvig <Morten.Sorvig at qt.io>
Sent: Tuesday, August 8, 2017 12:11:13 PM
To: development at qt-project.org
Subject: Re: [Development] State of 5.9 and dev branches

Thanks for cleaning this up quickly!

When it comes to testing, do we want to go one step further and
make the tests be completely independent of the current time? We would
like to avoid time bombs like these, and if something _is_ going to
fail at some future date we would like to know so right away.

I coded up a strawman proposal here:
    https://codereview.qt-project.org/201989

It adds a RAII class to QTestLib that allows setting the datetime
(as returned by QDateTime) for the duration of a test function:

    QTestTimeFixer fixedTime(QDateTime(QDate(2015, 1, 1)).toMSecsSinceEpoch());

This is then used to set the date time to sometime in the past for
tst_qnetworkcookiejar, which makes the unpatched version of it pass.
Going further we could set the time to the future and verify that
the cookies expire as expected.

Morten


> On 8 Aug 2017, at 09:40, Simon Hausmann <Simon.Hausmann at qt.io> wrote:
>
>
> Thank you Thiago, Sergio and Lars!
>
> qtbase 5.6 and 5.9 are good again.
>
> Simon
> From: Development <development-bounces+simon.hausmann=qt.io at qt-project.org> on behalf of Thiago Macieira <thiago.macieira at intel.com>
> Sent: Monday, August 7, 2017 10:54:22 PM
> To: development at qt-project.org
> Subject: Re: [Development] State of 5.9 and dev branches
>
> On Monday, 7 August 2017 13:36:19 PDT Simon Hausmann wrote:
> > Hi,
> >
> > The 5.9 fix went in. Would be most grateful if somebody could do the cherry
> > pick and merge. I won't have a keyboard until tomorrow late morning.
>
> 5.6: https://codereview.qt-project.org/201945
> dev: https://codereview.qt-project.org/201946
>
> --
> 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

_______________________________________________
Development mailing list
Development at qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20170808/6350ae47/attachment.html>

From Simon.Hausmann at qt.io  Tue Aug  8 15:15:16 2017
From: Simon.Hausmann at qt.io (Simon Hausmann)
Date: Tue, 8 Aug 2017 13:15:16 +0000
Subject: [Development] State of 5.9 and dev branches
In-Reply-To: <DB5PR02MB0998CE62D2D71A5D371F02618C8A0@DB5PR02MB0998.eurprd02.prod.outlook.com>
References: <VI1PR02MB1006973243F291B3795EFA838CB50@VI1PR02MB1006.eurprd02.prod.outlook.com>
	<40FAFB42-E9F2-415F-8519-FB9A543BE6FA@qt.io>,
	<15230927.kpuOl23eBN@tjmaciei-mobl1>,
	<DB5PR02MB0998CE62D2D71A5D371F02618C8A0@DB5PR02MB0998.eurprd02.prod.outlook.com>
Message-ID: <DB5PR02MB0998FBE15D3D4997C2C8E5218C8A0@DB5PR02MB0998.eurprd02.prod.outlook.com>


The dev merge went in, too, so qtbase dev is working again as well. Thanks everyone :)




Simon

________________________________
From: Development <development-bounces+simon.hausmann=qt.io at qt-project.org> on behalf of Simon Hausmann <Simon.Hausmann at qt.io>
Sent: Tuesday, August 8, 2017 9:40:33 AM
To: Thiago Macieira; development at qt-project.org
Subject: Re: [Development] State of 5.9 and dev branches



Thank you Thiago, Sergio and Lars!


qtbase 5.6 and 5.9 are good again.


Simon

________________________________
From: Development <development-bounces+simon.hausmann=qt.io at qt-project.org> on behalf of Thiago Macieira <thiago.macieira at intel.com>
Sent: Monday, August 7, 2017 10:54:22 PM
To: development at qt-project.org
Subject: Re: [Development] State of 5.9 and dev branches

On Monday, 7 August 2017 13:36:19 PDT Simon Hausmann wrote:
> Hi,
>
> The 5.9 fix went in. Would be most grateful if somebody could do the cherry
> pick and merge. I won't have a keyboard until tomorrow late morning.

5.6: https://codereview.qt-project.org/201945
dev: https://codereview.qt-project.org/201946

--
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: <http://lists.qt-project.org/pipermail/development/attachments/20170808/289db1c5/attachment.html>

From edward.welbourne at qt.io  Tue Aug  8 17:49:36 2017
From: edward.welbourne at qt.io (Edward Welbourne)
Date: Tue, 8 Aug 2017 15:49:36 +0000
Subject: [Development] Calendar Systems proposal
In-Reply-To: <1612751.Htp1vzdW7U@tjmaciei-mobl1>
References: <CAOMsk2Qn+kSmpLmadHT9i-_SW0mbNBgCKBUh1erW0hvmyiqVDw@mail.gmail.com>
	<HE1PR0202MB2683F0D2023EE4E8B087751387440@HE1PR0202MB2683.eurprd02.prod.outlook.com>
	<CAOMsk2TRhSoMQKDbWgmHqOuQMCa7LNLrO4ZD=_+1SgT6nRdegw@mail.gmail.com>,
	<1612751.Htp1vzdW7U@tjmaciei-mobl1>
Message-ID: <AM4PR02MB32494BE576F1D0745DFBD857878A0@AM4PR02MB3249.eurprd02.prod.outlook.com>

Thiago Macieira (7 August 2017 06:14)
> ... there are bigger problems with the implementation, starting with
> QAbstractCalendar having a static protected QMap member.

That's my fault.  We're going to need some way for QML/V4 to get at
calendars; and I want to ensure our design leaves scope for client code
to provide a calendar of its choice - e.g. so that a developer whose
target market uses a relatively obscure calendar can support them with a
minimum of pain, without Qt itself needing to contain code for every
calendar that ever has been or will be invented.  (Conversely, of
course, it's also worth making it easy to configure which, of the
calendar implementations present in Qt, actually get compiled into any
given build.)  Each calendar implementation needs a way to make itself
visible to QML/V4.

My naive idea for how to solve that was to let each calendar
implementation register a factory for its objects under a name
representing its calendar.  Then QML/V4 (and, for that matter, C++ APIs)
can look up a calendar by name and get a calendar object to use.
Indeed, we can even consult the map for a list of supported calendars,
to populate a UI's drop-down to select which to use.

Please suggest a better solution (and explain the problem with the
present solution), either here or in the review.

> The big problem is how you've implemented the new API in QDateTime and
> QLocale. There's code duplication that cannot be there in QLocale,

That's probably best addressed by you commenting on the review; I'm not
sure what duplication you're referring to ("cannot be there" is strong
language), although I do know about dateTimeToString().  There are a few
places I expect to find myself doing clean-up in the aftermath of
getting this all in, but I don't mind doing some of it before-hand.

Note, also, that this moves calendar-related data out of QLocale's
CLDR-derived data blob into calendar-specific data blobs - a step in the
general direction of making QLocale less monolithic.

> but the way you've removed the duplication in QDateTime also needs
> changing for performance reasons.
>
> int QDate::year() const
> {
>     return year(QGregorianCalendar());
> }
>
> This creates a polymorphic object and makes a call that ends up delegating to
> it in
>
>             if (cal.julianDayToDate(jd, y, m, d))

Please elaborate: why is this a problem ?  The Gregorian arithmetic
naturally belongs in a calendar implementation.  The date-time code
should naturally call it, rather than duplicating it in static functions
of its own (which have, naturally, been moved to become its methods).

> The commit also includes changes that look like unrelated clean-ups and will
> need to be split into different commits.

Please point these out on the review.  Some of them might not be as
unrelated as you think - I did a fair bit of pulling separable changes
out already, rebasing Soroush's work onto the results.  I may well have
missed some, but there were bits that couldn't be separated.

> It's at this point lacking documentation

Indeed, there remains work to be done.  On the other hand, deciding what
shape the API should be is worth doing before taking pains over
documenting every detail - that would all change if we decide we need to
change the API.

> and there are a couple of coding style mistakes.

Please note in Gerrit.

	Eddy.


From kde at carewolf.com  Tue Aug  8 18:56:01 2017
From: kde at carewolf.com (Allan Sandfeld Jensen)
Date: Tue, 08 Aug 2017 18:56:01 +0200
Subject: [Development] Qt 5.10 schedule etc
In-Reply-To: <VI1PR02MB3133A14A246A2F6772E63DB89D8A0@VI1PR02MB3133.eurprd02.prod.outlook.com>
References: <HE1PR02MB3132DFFBCCFE0E6C6061CC579DB30@HE1PR02MB3132.eurprd02.prod.outlook.com>
	<VI1PR02MB3133A14A246A2F6772E63DB89D8A0@VI1PR02MB3133.eurprd02.prod.outlook.com>
Message-ID: <1869660.3ysIREnbE4@twilight>

On Dienstag, 8. August 2017 10:41:02 CEST Jani Heikkinen wrote:
> Hi all,
> 
> We should have FF & branching today. Unfortunately we are still fighting
> with some issues in qt5.git integration in 'dev' . That's why we haven't
> been able to start soft branching yet :( But that doesn't mean we will
> officially delay the FF ;)
> 
> So let's freeze new features for Qt 5.10 today as planned. Please don't put
> any new features in for 5.10 anymore. We will start soft branching
> immediately when issues with qt5.git integration in' dev' are solved. And
> we will finalize branching ~ after a week from that date when soft
> branching starts. So there will be still enough time to get changes in
> which are currently suffering these issues in dev.
> 
I would suggest allowing features that couldnt get in due to git issues, still 
be allowed to integrate once it is fixed. I don't know of anything specific 
that has been caught by that though.

'Allan


From thiago.macieira at intel.com  Tue Aug  8 20:10:09 2017
From: thiago.macieira at intel.com (Thiago Macieira)
Date: Tue, 8 Aug 2017 11:10:09 -0700
Subject: [Development] Calendar Systems proposal
In-Reply-To: <AM4PR02MB32494BE576F1D0745DFBD857878A0@AM4PR02MB3249.eurprd02.prod.outlook.com>
References: <CAOMsk2Qn+kSmpLmadHT9i-_SW0mbNBgCKBUh1erW0hvmyiqVDw@mail.gmail.com>
	<1612751.Htp1vzdW7U@tjmaciei-mobl1>
	<AM4PR02MB32494BE576F1D0745DFBD857878A0@AM4PR02MB3249.eurprd02.prod.outlook.com>
Message-ID: <2498265.qbDuEcG3Rv@tjmaciei-mobl1>

On Tuesday, 8 August 2017 08:49:36 PDT Edward Welbourne wrote:
> Thiago Macieira (7 August 2017 06:14)
> 
> > ... there are bigger problems with the implementation, starting with
> > QAbstractCalendar having a static protected QMap member.
> 
> That's my fault.  We're going to need some way for QML/V4 to get at
> calendars; and I want to ensure our design leaves scope for client code
[cut]
> 
> Please suggest a better solution (and explain the problem with the
> present solution), either here or in the review.

The problem is the presence of a protected, static, non-POD member. Remove it.

Store the data in a Q_GLOBAL_STATIC in qabstractcalendar.cpp. If you need to 
get a listing or do any kind of searching, add static functions to 
QAbstractCalendar. See QTextCodec for inspiration.

> > The big problem is how you've implemented the new API in QDateTime and
> > QLocale. There's code duplication that cannot be there in QLocale,
> 
> That's probably best addressed by you commenting on the review; I'm not
> sure what duplication you're referring to ("cannot be there" is strong
> language), although I do know about dateTimeToString().  There are a few
> places I expect to find myself doing clean-up in the aftermath of
> getting this all in, but I don't mind doing some of it before-hand.

The big code block that was added in the commit to qlocale.cpp looks like a 
copy & paste of existing code.

> Note, also, that this moves calendar-related data out of QLocale's
> CLDR-derived data blob into calendar-specific data blobs - a step in the
> general direction of making QLocale less monolithic.

That's good.

> > but the way you've removed the duplication in QDateTime also needs
> > changing for performance reasons.
> > 
> > int QDate::year() const
> > {
> >     return year(QGregorianCalendar());
> > }
> > 
> > This creates a polymorphic object and makes a call that ends up delegating
> > to it in
> > 
> >             if (cal.julianDayToDate(jd, y, m, d))
> 
> Please elaborate: why is this a problem ?  The Gregorian arithmetic
> naturally belongs in a calendar implementation.  The date-time code
> should naturally call it, rather than duplicating it in static functions
> of its own (which have, naturally, been moved to become its methods).

The problems are:
 - creating a polymorphic type (QGregorianCalendar) [performance]
 - passing it by reference instead of a pointer [coding style]
 - calling a non-inline function to do the calculation [performance]

The performance problems are due to performance regressions. I'd rather you 
inverted the deduplication: let QDate have the calculation and call that from 
QGregorianCalendar.

> > The commit also includes changes that look like unrelated clean-ups and
> > will need to be split into different commits.
> 
> Please point these out on the review.  Some of them might not be as
> unrelated as you think - I did a fair bit of pulling separable changes
> out already, rebasing Soroush's work onto the results.  I may well have
> missed some, but there were bits that couldn't be separated.

I will.

> > It's at this point lacking documentation
> 
> Indeed, there remains work to be done.  On the other hand, deciding what
> shape the API should be is worth doing before taking pains over
> documenting every detail - that would all change if we decide we need to
> change the API.

Sure. I just replied here because it looked like it was a request to make it 
before the FF.

> 
> > and there are a couple of coding style mistakes.
> 
> Please note in Gerrit.

	s/\w& / &/g

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center



From sean.harmer at kdab.com  Tue Aug  8 21:16:42 2017
From: sean.harmer at kdab.com (Sean Harmer)
Date: Tue, 8 Aug 2017 20:16:42 +0100
Subject: [Development] Qt 5.10 schedule etc
In-Reply-To: <1869660.3ysIREnbE4@twilight>
References: <HE1PR02MB3132DFFBCCFE0E6C6061CC579DB30@HE1PR02MB3132.eurprd02.prod.outlook.com>
	<VI1PR02MB3133A14A246A2F6772E63DB89D8A0@VI1PR02MB3133.eurprd02.prod.outlook.com>
	<1869660.3ysIREnbE4@twilight>
Message-ID: <1da39bcd-8851-e97c-8375-fc177dec6042@kdab.com>

Hi,

On 08/08/2017 17:56, Allan Sandfeld Jensen wrote:
> On Dienstag, 8. August 2017 10:41:02 CEST Jani Heikkinen wrote:
>> Hi all,
>>
>> We should have FF & branching today. Unfortunately we are still fighting
>> with some issues in qt5.git integration in 'dev' . That's why we haven't
>> been able to start soft branching yet :( But that doesn't mean we will
>> officially delay the FF ;)
>>
>> So let's freeze new features for Qt 5.10 today as planned. Please don't put
>> any new features in for 5.10 anymore. We will start soft branching
>> immediately when issues with qt5.git integration in' dev' are solved. And
>> we will finalize branching ~ after a week from that date when soft
>> branching starts. So there will be still enough time to get changes in
>> which are currently suffering these issues in dev.
>>
> I would suggest allowing features that couldnt get in due to git issues, still
> be allowed to integrate once it is fixed. I don't know of anything specific
> that has been caught by that though.

+1 and on a related note, I keep hitting:

Project ERROR: Cannot run compiler 
'/home/qt/work/b2qt/toolchain/sysroots/x86_64-pokysdk-linux/usr/bin/arm-poky-linux-gnueabi/arm-poky-linux-gnueabi-g++'. 
Maybe you forgot to setup the environment?

when attempting to integrate changes to Qt 3D (for the skeletal 
animation feature).

Could somebody with CI-fu take a look please?

Thanks!

Sean

-- 
Dr Sean Harmer | sean.harmer at kdab.com | Managing Director UK
KDAB (UK) Ltd, a KDAB Group company
Tel. +44 (0)1625 809908; Sweden (HQ) +46-563-540090
Mobile: +44 (0)7545 140604
KDAB - Qt Experts


From Shawn.Rutledge at qt.io  Wed Aug  9 14:10:27 2017
From: Shawn.Rutledge at qt.io (Shawn Rutledge)
Date: Wed, 9 Aug 2017 12:10:27 +0000
Subject: [Development] Pointer Handlers will be Tech Preview in 5.10
Message-ID: <AD717B44-77CB-4E79-8D10-3BACD88AD5D6@qt.io>

We just finally got the wip/pointerhandler branch merged to dev branch (yes it’s a couple of days past the feature freeze, but has been in the works for years, and we really planned to get it in 5.10).

A PointerHandler is a QObject which can be declared as a child of an Item in Qt Quick, which will handle events from pointing devices (mouse, keyboard, or stylus) on behalf of that Item.  An Item can have multiple handlers.  So, handlers are intended to be smaller and more specific in implementation, compared to the existing Areas such as MouseArea which try to do everything you could ever want to do with the mouse (and then get used for handling touch events in practice besides); and also somewhat smaller in memory, not being full-fledged Items themselves.

It’s going to be Tech Preview because of still being incomplete.  So far we only have

TapHandler - the one you need to build a button, it handles press and release, tapping (clicking), long-press and multi-tapping (the most common use cases for MouseArea).  There are improvements like being able to constrain it to react only to certain device types, certain mouse buttons, or while holding down a modifier key; being able to count taps rather than only supporting single and double click; and being able to tap or press multiple Items with TapHandlers at the same time (which until now has required that you switch from MouseArea to MultiPointTouchArea).

DragHandler - declare one of these inside an Item and suddenly you can drag it.  It has some properties too.

PinchHandler - to enable 2-finger pinch gestures for rotation, scaling and dragging.  The major improvements over PinchArea are that you can zoom into any point (the point which is the centroid of your finger positions) rather than only zooming into the center or corner of an Item; and, you can require more than two fingers if you like, so it’s possible to have a 2-finger pinch which does one thing and a 3-finger pinch which does something else, for example.

So what have we left out? everything else that you could do with a mouse: for example hovering, and use of the mouse wheel, at least.  Scrolling via a 2-finger flick gesture on a touch pad (which is implemented via fake mouse wheel events on most platforms… but that’s not always good enough).  We need to write a few more handlers I think.

Handling of QTabletEvents (from a stylus on a Wacom tablet, Tablet PC or a Galaxy Note) is also not implemented yet (although I have had patches to get started with that for a long time now).  And I think we need another handler for the stylus anyway.  Now that we have path rendering in Qt Quick, maybe the next step is to be able to draw paths with a stylus; but we didn’t flesh out the mechanism for doing that yet.

DragHandler drags items around the scene, but we have made no attempt at proper DnD support yet.

Another reason is that we hope to have public C++ API eventually, so that you can subclass one of the pointer handler abstract classes and handle the kinds of gestures that we don’t already support, to do whatever you like.  But we have not yet made it suitable for that: it needs more API review, the classes need refactoring to follow the PIMPL pattern, more docs, etc.

So for 5.10 you will only be able to do

import Qt.labs.handlers 1.0

and instantiate those three types in QML; and you can play with the private API in C++, with the expectation that some of it will probably be public later on.

There is a prototype FakeFlickable which we have as a manual test so far, which shows how you can use two Items plus a DragHandler to implement something which behaves like Flickable, in pure QML.  Maybe we will re-implement Flickable itself that way, under the covers, which should result in some code de-duplication and more flexible event handling; but we haven’t gotten to that yet, and the behavior isn’t perfect yet anyway.  But it’s very difficult to fix Flickable to handle multi-touch properly: you can’t flick two of them at once with two fingers, and it only knows how to steal the grab from a mouse event, so there are some problems with stealing synthetic mouse events from handlers or items which are grabbing touchpoints already.  So we think that replacing it might streamline the code while also enabling more kinds of interaction.  But can we keep the API the same while totally replacing the implementation?  (or should we?)  won’t know until we try…

We still need to do a lot more dogfooding: for example try to replace all the custom C++ event handling code in qtlocation with pointer handlers.  We can’t say it’s ready to use if we don’t succeed with that.  Likewise, sets of controls such as QtQuick.Controls could make use of handlers… but we’ll see how that goes.  From one side, we need to do something like that in order to validate more of the possible use cases.  From another side, the total QObject count would go up (which means instantiation time and memory usage would probably increase), compared to the Controls 2.0 implementation with its monolithic base classes.  So we’ll see about that.  Maybe we can find some sort of middle ground which gives us code reuse without bloating the object count, somehow.  Such an approach amounts to having a different kind of C++ API.

The original idea was more about using attached properties, rather than having to declare the handlers.  We are still playing with some ideas there.

And actually, there are still known bugs we are fixing.  We will keep trying to get more of them fixed before 5.10 ships. But now is the chance for some early feedback.  After talking about this at the contributors’ summit for 3 years straight, we think it’s about time that we shipped something.

Sorry for getting it in at the last minute like this.  (It could have been a couple of months ago.  I was on vacation, and little has changed since this spring, except for some bug fixes which finally enabled integration.)  But if you don’t do the import, you can ignore it.  We kept all the old autotests passing, so we expect that the existence of this new stuff won’t impact existing QML.  And during the big event-delivery refactoring (some of which was in 5.9 already), we have tried to make event delivery more efficient for all use cases, so it will be interesting to get some feedback about that too.

Later on, it may be part of Qt Quick, not requiring a separate import anymore.  And then if it all goes really well, at some point maybe we should deprecate the old Areas (not sure when that will be).  And in Qt 6 I hope we can broaden the scope of the event delivery refactoring: promote the pointer event concept to qtbase, instead of just having it be a wrapper around the existing QInputEvents in qtdeclarative, as it is now.  I even hope we can go as far as to remove the one-mouse limitation eventually.  QtQuick will be ready for that by the time it’s possible in qtbase, anyway.

The main thrust of this gambit is to unify the delivery and handling of all pointer events instead of needing separate delivery paths for QMouseEvent, QTouchEvent and QTabletEvent (with their own behavioral idioscynrasies and bugs), and to enable proper multi-touch support such that we can some day stop relying on the synthesis of mouse events from touch events (because the delivery process is now agnostic about the type of event, even though an individual handler may care about some device-specific event details).


From marten.nordheim at qt.io  Thu Aug 10 14:41:19 2017
From: marten.nordheim at qt.io (=?UTF-8?Q?M=c3=a5rten_Nordheim?=)
Date: Thu, 10 Aug 2017 14:41:19 +0200
Subject: [Development] Introducing discussion about QStringFormatter
In-Reply-To: <7975da6a-aef3-67c6-fd92-a2252eb4daee@qt.io>
References: <AMSPR02MB1023DCF16E23874F122637BE6E10@AMSPR02MB102.eurprd02.prod.outlook.com>
	<AM4PR02MB32492323D55A70FBB2A682E287E60@AM4PR02MB3249.eurprd02.prod.outlook.com>
	<trinity-90cbcf77-e3e9-466c-bde8-213bb6416ff3-1494942618809@3capp-mailcom-bs11>
	<3721235.bBHMokTBBM@tjmaciei-mobl1>
	<7975da6a-aef3-67c6-fd92-a2252eb4daee@qt.io>
Message-ID: <100198fb-c2c9-f090-153a-4d9527d717df@qt.io>

Hello, I'm back with round 2 of QStringFormatter
=====

The WIP is still located over here:
https://codereview.qt-project.org/#/c/192873/

Name
-----

I think it would be nice to change the class' name as typing
QStringFormatter repeatedly is fairly cumbersome. One suggestion was
QFormat (unless it's already used, though I haven't seen any uses
from searching). If there're no objections or other suggestions then
I will rename the class.

API
-----

Changes since I last wrote about QStringFormatter on the mailing list:

- the in-string formatting's separator was changed from '$' to ':' to
   match other string formatting APIs.
- ::multiArg was introduced
   - Variadic template which simply forwards each parameter to a
     separate ::arg-call
   - Currently returns a QString directly. Should it return
     QStringFormatter& like ::arg?
- Static function ::format
   - Another variadic template, instantiates QStringFormatter and
     forwards arguments to multiArg
     - example:
       `QStringFormatter::format("{} {}", "Hello,", "World!");`
     - Remove? Nice to have?
- (QStringFormatter::)Formatting
   - ::arg methods have an optional Formatting argument which can be
     used to override or augment any previously specified in-string
     formatting
   - Can be constructed from a string of formatting options
     (e.g. "L<10") or using its methods (e.g. setLocale,
     setJustification)
- Named replacements uses an alias for QPair<QString, T> called
   Argument.
   - e.g. `QStringFormatter("Hello, {Name}").arg({"Name", "World"});`
   - A qMakePair-style function called `qArg` for use in
     situations with template argument deduction trouble.
     - e.g.
`QStringFormatter("Hello, {Name}").arg(QStringFormatter::qArg("Name", 47));`

Any feedback on API is appreciated. A proposal for the API for
formatting custom types follows.

Replacement format
-----

The replacement options now have formatting features matching
QString::arg. The current options (open to change) are:

- `L` for localization (localize numbers, like in QString::arg)
- `</>/=` for justification. Left, right and center justification
   - Followed by an optional padding character (excluding 1-9)
   - Followed by field-width
   - e.g. "==16" (pad using '=', centered, field-width 16),
     "<10" (left-justify using spaces, field-width 10),
     ">-3" (right-justify using '-', field-width 3)
- `f/g/G/e/E` for floating-point number formatting
   (https://doc.qt.io/qt-5/qstring.html#argument-formats)
   - followed by a dot and then precision
   - e.g. "f.2"
- `b/B` for setting base. Supports bases 2-36. Using 'b' produces
   lower-case letters for digits 10-35, and 'B' produces upper-case.
   For bases 2-10 they make no difference.
- `:` everything after the colon gets put into an 'extra' field, more
   on this later..
   - e.g. `{:<10:this is the extra field}`
   - or `{::yyyy-MM-dd HH:mm:ss}`

Currently the formatting options can come in any order (e.g. "L<10"
and "<10L" does the same, the only exception being ':').
However it would be good to enforce some sort of order for the sake
of consistency. With a defined order we could also change
justification format from [<>=]cn to c[<>=]n, which would allow
people to use 1-9 as a fill-character. If this is done, what should
the order be like?

QString::arg compatibility
-----

Currently QString::arg compatibility is activated using a parameter
in the constructor. All this does is let you use %nn style tokens and
'disable' use of the brace-style tokens. It also supports `%L` to
enable localization of numbers, but any other formatting must be done
using the `QStringFormatter::Formatting` class.

API for formatting custom types
-----

One idea I've been experimenting with a little bit is using template
specialization to deal with formatting custom types. To support a
custom type you'd create a specialization of a struct called
`Formatter`. It would use the `extra` field in `Formatting` which
you could optionally parse for custom formatting options. The parser
would be a separate class inheriting `Formatting` and be specified in
the Formatter using a typedef.

E.g.
`struct QStringFormatter::Formatter<QDateTime>
{
typedef DateTimeInfo FormatType;
QString operator()(const QDateTime &dateTime, const FormatType &format);
}`

`QStringFormatter` will then instantiate this struct when it receives
a `QDateTime` object, and create a `FormatType` object to parse the
data located in the `extra` field of formatting options. The
`FormatType` object is then expected to store whatever info it needs
and then the `Formatter` will use it later.

Feedback on the approach, pitfalls etc. is much appreciated!

Thanks,

-- Mårten Nordheim


From szehowe.koh at gmail.com  Fri Aug 11 02:53:39 2017
From: szehowe.koh at gmail.com (Sze Howe Koh)
Date: Fri, 11 Aug 2017 08:53:39 +0800
Subject: [Development] Introducing discussion about QStringFormatter
In-Reply-To: <100198fb-c2c9-f090-153a-4d9527d717df@qt.io>
References: <AMSPR02MB1023DCF16E23874F122637BE6E10@AMSPR02MB102.eurprd02.prod.outlook.com>
	<AM4PR02MB32492323D55A70FBB2A682E287E60@AM4PR02MB3249.eurprd02.prod.outlook.com>
	<trinity-90cbcf77-e3e9-466c-bde8-213bb6416ff3-1494942618809@3capp-mailcom-bs11>
	<3721235.bBHMokTBBM@tjmaciei-mobl1>
	<7975da6a-aef3-67c6-fd92-a2252eb4daee@qt.io>
	<100198fb-c2c9-f090-153a-4d9527d717df@qt.io>
Message-ID: <CALW8pfWHf2WbHYg56CDmTG1_ZZk7rKByaBa-yYXDi_zQNR+YYg@mail.gmail.com>

Hello,


On 10 August 2017 at 20:41, Mårten Nordheim <marten.nordheim at qt.io> wrote:
>
> Hello, I'm back with round 2 of QStringFormatter
> =====
>
> The WIP is still located over here:
> https://codereview.qt-project.org/#/c/192873/
>
> Name
> -----
>
> I think it would be nice to change the class' name as typing
> QStringFormatter repeatedly is fairly cumbersome. One suggestion was
> QFormat (unless it's already used, though I haven't seen any uses
> from searching). If there're no objections or other suggestions then
> I will rename the class.

IMHO, "QFormat" isn't a suitable name. First, this class itself does
not describe a format, unlike:

* QTextFormat
* Qt::DateFormat
* QSettings::Format
* QAudioFormat
* QImage::Format
* QPixelFormat
* QVideoFrame::PixelFormat
* QVideoSurfaceFormat
* QSurfaceFormat
* QOpenGLFramebufferObjectFormat

So, at the very least, call it "QFormatter"


Second, from a quick glance of the list above, I can guess the type of
format that most the classes/enums above describe.
"QFormat"/"QFormatter" doesn't contain any clues that it's related to
string formatting. (Minor tangent: I feel that QTextFormat and
QText(Char|Block|List|Table)Format would be clearer if renamed to
QTextDocumentFormat and QTextDocument(Char|Block|List|Table)Format
respectively)

Finally, one of the guidelines in
https://wiki.qt.io/API_Design_Principles#The_Art_of_Naming is "Do not
abbreviate".

For these reasons, I'd personally prefer sticking to "QStringFormatter".


Having said that, the verbosity of a name is a valid concern. It is
the reason why I personally prefer to write raw C string literals
instead of wrapping them in QStringLiteral, unless the performance
penalty is noticeable. I can't think of a better name than
"QStringFormatter" though. Perhaps, in our documentation/examples, we
can suggest that the user introduce a typedef in their own code (as
opposed to adding an official abbreviation) to shorten things?

    typedef QStringFormatter QSF;
    QSF formatter(...);


> API
> -----
>
> Changes since I last wrote about QStringFormatter on the mailing list:
>
> - the in-string formatting's separator was changed from '$' to ':' to
>   match other string formatting APIs.
> - ::multiArg was introduced
>   - Variadic template which simply forwards each parameter to a
>     separate ::arg-call
>   - Currently returns a QString directly. Should it return
>     QStringFormatter& like ::arg?
> - Static function ::format
>   - Another variadic template, instantiates QStringFormatter and
>     forwards arguments to multiArg
>     - example:
>       `QStringFormatter::format("{} {}", "Hello,", "World!");`
>     - Remove? Nice to have?
> - (QStringFormatter::)Formatting
>   - ::arg methods have an optional Formatting argument which can be
>     used to override or augment any previously specified in-string
>     formatting
>   - Can be constructed from a string of formatting options
>     (e.g. "L<10") or using its methods (e.g. setLocale,
>     setJustification)
> - Named replacements uses an alias for QPair<QString, T> called
>   Argument.
>   - e.g. `QStringFormatter("Hello, {Name}").arg({"Name", "World"});`
>   - A qMakePair-style function called `qArg` for use in
>     situations with template argument deduction trouble.
>     - e.g.
> `QStringFormatter("Hello, {Name}").arg(QStringFormatter::qArg("Name", 47));`
>
> Any feedback on API is appreciated. A proposal for the API for
> formatting custom types follows.
>
> Replacement format
> -----
>
> The replacement options now have formatting features matching
> QString::arg. The current options (open to change) are:
>
> - `L` for localization (localize numbers, like in QString::arg)
> - `</>/=` for justification. Left, right and center justification
>   - Followed by an optional padding character (excluding 1-9)
>   - Followed by field-width
>   - e.g. "==16" (pad using '=', centered, field-width 16),
>     "<10" (left-justify using spaces, field-width 10),
>     ">-3" (right-justify using '-', field-width 3)
> - `f/g/G/e/E` for floating-point number formatting
>   (https://doc.qt.io/qt-5/qstring.html#argument-formats)
>   - followed by a dot and then precision
>   - e.g. "f.2"
> - `b/B` for setting base. Supports bases 2-36. Using 'b' produces
>   lower-case letters for digits 10-35, and 'B' produces upper-case.
>   For bases 2-10 they make no difference.
> - `:` everything after the colon gets put into an 'extra' field, more
>   on this later..
>   - e.g. `{:<10:this is the extra field}`
>   - or `{::yyyy-MM-dd HH:mm:ss}`
>
> Currently the formatting options can come in any order (e.g. "L<10"
> and "<10L" does the same, the only exception being ':').
> However it would be good to enforce some sort of order for the sake
> of consistency. With a defined order we could also change
> justification format from [<>=]cn to c[<>=]n, which would allow
> people to use 1-9 as a fill-character. If this is done, what should
> the order be like?
>
> QString::arg compatibility
> -----
>
> Currently QString::arg compatibility is activated using a parameter
> in the constructor. All this does is let you use %nn style tokens and
> 'disable' use of the brace-style tokens. It also supports `%L` to
> enable localization of numbers, but any other formatting must be done
> using the `QStringFormatter::Formatting` class.
>
> API for formatting custom types
> -----
>
> One idea I've been experimenting with a little bit is using template
> specialization to deal with formatting custom types. To support a
> custom type you'd create a specialization of a struct called
> `Formatter`. It would use the `extra` field in `Formatting` which
> you could optionally parse for custom formatting options. The parser
> would be a separate class inheriting `Formatting` and be specified in
> the Formatter using a typedef.
>
> E.g.
> `struct QStringFormatter::Formatter<QDateTime>
> {
> typedef DateTimeInfo FormatType;
> QString operator()(const QDateTime &dateTime, const FormatType &format);
> }`
>
> `QStringFormatter` will then instantiate this struct when it receives
> a `QDateTime` object, and create a `FormatType` object to parse the
> data located in the `extra` field of formatting options. The
> `FormatType` object is then expected to store whatever info it needs
> and then the `Formatter` will use it later.
>
> Feedback on the approach, pitfalls etc. is much appreciated!
>
> Thanks,
>
>
> -- Mårten Nordheim


Regards,
Sze-Howe Koh


From thiago.macieira at intel.com  Fri Aug 11 04:20:30 2017
From: thiago.macieira at intel.com (Thiago Macieira)
Date: Thu, 10 Aug 2017 19:20:30 -0700
Subject: [Development] Introducing discussion about QStringFormatter
In-Reply-To: <CALW8pfWHf2WbHYg56CDmTG1_ZZk7rKByaBa-yYXDi_zQNR+YYg@mail.gmail.com>
References: <AMSPR02MB1023DCF16E23874F122637BE6E10@AMSPR02MB102.eurprd02.prod.outlook.com>
	<100198fb-c2c9-f090-153a-4d9527d717df@qt.io>
	<CALW8pfWHf2WbHYg56CDmTG1_ZZk7rKByaBa-yYXDi_zQNR+YYg@mail.gmail.com>
Message-ID: <1663009.8z0fJaXk2y@tjmaciei-mobl1>

On quinta-feira, 10 de agosto de 2017 17:53:39 PDT Sze Howe Koh wrote:
> On 10 August 2017 at 20:41, Mårten Nordheim <marten.nordheim at qt.io> wrote:
> IMHO, "QFormat" isn't a suitable name. First, this class itself does
> not describe a format, unlike:
[cut]
> For these reasons, I'd personally prefer sticking to "QStringFormatter".

Agreed, please use QStringFormatter.

> Having said that, the verbosity of a name is a valid concern. It is
> the reason why I personally prefer to write raw C string literals
> instead of wrapping them in QStringLiteral, unless the performance
> penalty is noticeable. I can't think of a better name than
> "QStringFormatter" though. Perhaps, in our documentation/examples, we
> can suggest that the user introduce a typedef in their own code (as
> opposed to adding an official abbreviation) to shorten things?
> 
>     typedef QStringFormatter QSF;
>     QSF formatter(...);

I disagree here. I don't find it convincing either on typing or on reading. 
First, we don't need to save on keystrokes: you can type "QSFo" and press Ctrl
+Space on Creator and it'll probably complete to the right class name (if you 
use an IDE that doesn't have this capability, file a suggestion, it's very 
handy; if you don't use an IDE, well, that's your own fault/choice).

As for the reading, I find that the name conveys just enough information 
without being too verbose.

> > - ::multiArg was introduced
> >   - Variadic template which simply forwards each parameter to a
> >     separate ::arg-call

Ok, could probably be improved, but no problem right now.

> >   
> >   - Currently returns a QString directly. Should it return
> >     QStringFormatter& like ::arg?

Yes. Please let all functions that perform replacement return the same thing.

> > - Static function ::format
> > 
> >   - Another variadic template, instantiates QStringFormatter and
> >     forwards arguments to multiArg
> >     
> >     - example:
> >       `QStringFormatter::format("{} {}", "Hello,", "World!");`

Where are the colons?

> >     - Remove? Nice to have?

No, keep. We have a lot of code doing:

	QString::fromLatin1("Something %1 $2").arg(arg).arg(arg2);

might as well keep it easy.

> > - (QStringFormatter::)Formatting
> >   - ::arg methods have an optional Formatting argument which can be
> >     used to override or augment any previously specified in-string
> >     formatting
> >   
> >   - Can be constructed from a string of formatting options
> >     (e.g. "L<10") or using its methods (e.g. setLocale,
> >     setJustification)

Are you saying that the function takes the shorthand-type formatter, instead 
of a more expressive set of information? I understand it makes easy for you, 
since it's the same code anyway, but it sounds contrived.

But ok, maybe just takes some getting used to.

> > - Named replacements uses an alias for QPair<QString, T> called
> >   Argument.
> >   - e.g. `QStringFormatter("Hello, {Name}").arg({"Name", "World"});`

Please pay attention to Marc's post about when to use QPair, std::pair, 
std::tuple in APIs: https://www.kdab.com/tuple-pair-cpp-apis/

If this is just an initializer_list, fair enough, but we need to look into it.

> >   - A qMakePair-style function called `qArg` for use in
> >     situations with template argument deduction trouble.
> >     - e.g.
> > 
> > `QStringFormatter("Hello, {Name}").arg(QStringFormatter::qArg("Name",
> > 47));`

Like this. That looks mighty ugly.

> > Replacement format
> > -----
> > 
> > The replacement options now have formatting features matching
> > QString::arg. The current options (open to change) are:
> > 
> > - `L` for localization (localize numbers, like in QString::arg)
> > - `</>/=` for justification. Left, right and center justification
> > 
> >   - Followed by an optional padding character (excluding 1-9)
> >   - Followed by field-width
> >   - e.g. "==16" (pad using '=', centered, field-width 16),
> >   
> >     "<10" (left-justify using spaces, field-width 10),
> >     ">-3" (right-justify using '-', field-width 3)

Is this inspired by any API? The one I can think of (printf) uses - for left 
justification and + for right justification. That would make just as much sense 
in using = for center.

> > - `b/B` for setting base. Supports bases 2-36. Using 'b' produces
> >   lower-case letters for digits 10-35, and 'B' produces upper-case.
> >   For bases 2-10 they make no difference.

With shorthands for hex and octal? Can you also make it so that a missing base 
number implies base 2?

> > - `:` everything after the colon gets put into an 'extra' field, more
> >   on this later..
> >   - e.g. `{:<10:this is the extra field}`
> >   - or `{::yyyy-MM-dd HH:mm:ss}`
> > 
> > Currently the formatting options can come in any order (e.g. "L<10"
> > and "<10L" does the same, the only exception being ':').
> > However it would be good to enforce some sort of order for the sake
> > of consistency. With a defined order we could also change
> > justification format from [<>=]cn to c[<>=]n, which would allow
> > people to use 1-9 as a fill-character. If this is done, what should
> > the order be like?

Agreed on requiring an order, at least in the beginning. What that should be, 
I don't know.

> > QString::arg compatibility
> > -----
> > 
> > Currently QString::arg compatibility is activated using a parameter
> > in the constructor. All this does is let you use %nn style tokens and
> > 'disable' use of the brace-style tokens. It also supports `%L` to
> > enable localization of numbers, but any other formatting must be done
> > using the `QStringFormatter::Formatting` class.

Can you already fully replace the QString::arg functions with 
QStringFormatter?

> > API for formatting custom types
> > -----
> > 
> > One idea I've been experimenting with a little bit is using template
> > specialization to deal with formatting custom types. To support a
> > custom type you'd create a specialization of a struct called
> > `Formatter`. It would use the `extra` field in `Formatting` which
> > you could optionally parse for custom formatting options. The parser
> > would be a separate class inheriting `Formatting` and be specified in
> > the Formatter using a typedef.
> > 
> > E.g.
> > `struct QStringFormatter::Formatter<QDateTime>
> > {
> > typedef DateTimeInfo FormatType;
> > QString operator()(const QDateTime &dateTime, const FormatType &format);
> > }`
> > 
> > `QStringFormatter` will then instantiate this struct when it receives
> > a `QDateTime` object, and create a `FormatType` object to parse the
> > data located in the `extra` field of formatting options. The
> > `FormatType` object is then expected to store whatever info it needs
> > and then the `Formatter` will use it later.
> > 
> > Feedback on the approach, pitfalls etc. is much appreciated!

Very interesting! I'm just confused why you need two classes here, but I'll 
look into the details when I look at the implementation.

> > Thanks,
> > 
> > 
> > -- Mårten Nordheim

Good work!

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center



From rjvbertin at gmail.com  Fri Aug 11 10:53:19 2017
From: rjvbertin at gmail.com (=?ISO-8859-1?Q?Ren=E9_J=2EV=2E?= Bertin)
Date: Fri, 11 Aug 2017 10:53:19 +0200
Subject: [Development] FYI: QtMultimedia and 3rd-party libopenal.dylib
 installs
Message-ID: <115600863.3PSCUs08jL@bola>

Hi,

For what it's worth, I notice that the QtMultiMedia build system picks up libopenal.dylib from the target prefix (and source of dependencies) if it's present, despite the fact that it is supposed to link to the OpenAL.framework . In my case that means it built against the software implementation (http://kcat.strangesoft.net/openal.html) which would probably lead to suboptimal 3D audio behaviour.

I have only observed this with Qt 5.8.0 on OS X 10.9 for now (so don't think a bug report is in order); you should be able to test this easily enough for yourselves if you're still using MacPorts as a source of dependencies (just install port:openal-soft).

Regards,
R.


From jani.heikkinen at qt.io  Fri Aug 11 10:53:58 2017
From: jani.heikkinen at qt.io (Jani Heikkinen)
Date: Fri, 11 Aug 2017 08:53:58 +0000
Subject: [Development] First Qt 5.10 (pre-alpha) binary snapshot available
Message-ID: <HE1PR02MB3132226E95EB2EE7059043059D890@HE1PR02MB3132.eurprd02.prod.outlook.com>

Hi all,

We have finally first binary snapshot (pre-alpha) available for Qt 5.10 via online installer. You can do clean installation by using online installer or add this under existing online installation by using its maintenance tool (detailed instructions here: https://wiki.qt.io/How_to_get_snapshot_via_online_installer). You will find Qt 5.10 under 'preview' node from installer UI.

Please take a tour to see where we are with Qt 5.10. Binaries are based on https://codereview.qt-project.org/#/c/199626/

And it is known issue that new qtwebglplugin -module (TP) is still missing from the installer. It will be added a bit later.

br,
Jan




From marten.nordheim at qt.io  Fri Aug 11 11:01:11 2017
From: marten.nordheim at qt.io (=?UTF-8?Q?M=c3=a5rten_Nordheim?=)
Date: Fri, 11 Aug 2017 11:01:11 +0200
Subject: [Development] Introducing discussion about QStringFormatter
In-Reply-To: <1663009.8z0fJaXk2y@tjmaciei-mobl1>
References: <AMSPR02MB1023DCF16E23874F122637BE6E10@AMSPR02MB102.eurprd02.prod.outlook.com>
	<100198fb-c2c9-f090-153a-4d9527d717df@qt.io>
	<CALW8pfWHf2WbHYg56CDmTG1_ZZk7rKByaBa-yYXDi_zQNR+YYg@mail.gmail.com>
	<1663009.8z0fJaXk2y@tjmaciei-mobl1>
Message-ID: <582e7d1a-8e21-6f16-5ebc-7145cae3e738@qt.io>

On 11.08.2017 04:20, Thiago Macieira wrote:
> On quinta-feira, 10 de agosto de 2017 17:53:39 PDT Sze Howe Koh wrote:
>> On 10 August 2017 at 20:41, Mårten Nordheim <marten.nordheim at qt.io> wrote:
>> IMHO, "QFormat" isn't a suitable name. First, this class itself does
>> not describe a format, unlike:
> [cut]
>> For these reasons, I'd personally prefer sticking to "QStringFormatter".
> 
> Agreed, please use QStringFormatter.
> 
>> Having said that, the verbosity of a name is a valid concern. It is
>> the reason why I personally prefer to write raw C string literals
>> instead of wrapping them in QStringLiteral, unless the performance
>> penalty is noticeable. I can't think of a better name than
>> "QStringFormatter" though. Perhaps, in our documentation/examples, we
>> can suggest that the user introduce a typedef in their own code (as
>> opposed to adding an official abbreviation) to shorten things?
>>
>>      typedef QStringFormatter QSF;
>>      QSF formatter(...);
> 
> I disagree here. I don't find it convincing either on typing or on reading.
> First, we don't need to save on keystrokes: you can type "QSFo" and press Ctrl
> +Space on Creator and it'll probably complete to the right class name (if you
> use an IDE that doesn't have this capability, file a suggestion, it's very
> handy; if you don't use an IDE, well, that's your own fault/choice).
> 
> As for the reading, I find that the name conveys just enough information
> without being too verbose.



>>> - ::multiArg was introduced
>>>    - Variadic template which simply forwards each parameter to a
>>>      separate ::arg-call
> 
> Ok, could probably be improved, but no problem right now.
> 
>>>    
>>>    - Currently returns a QString directly. Should it return
>>>      QStringFormatter& like ::arg?
> 
> Yes. Please let all functions that perform replacement return the same thing.
> 
>>> - Static function ::format
>>>
>>>    - Another variadic template, instantiates QStringFormatter and
>>>      forwards arguments to multiArg
>>>      
>>>      - example:
>>>        `QStringFormatter::format("{} {}", "Hello,", "World!");`
> 
> Where are the colons?

It was just a short example, it has the same features as the rest of the 
::args functions:

`QStringFormatter::format("{:<10} {:>10}", "Hello", "World!");`

Though I suppose it should be noted that both ::multiArg (and thus 
::format) currently don't accept any QStringFormatter::Formatting 
arguments, although that overload can be added as well.

>>>      - Remove? Nice to have?
> 
> No, keep. We have a lot of code doing:
> 
> 	QString::fromLatin1("Something %1 $2").arg(arg).arg(arg2);
> 
> might as well keep it easy.
> 
>>> - (QStringFormatter::)Formatting
>>>    - ::arg methods have an optional Formatting argument which can be
>>>      used to override or augment any previously specified in-string
>>>      formatting
>>>    
>>>    - Can be constructed from a string of formatting options
>>>      (e.g. "L<10") or using its methods (e.g. setLocale,
>>>      setJustification)
> 
> Are you saying that the function takes the shorthand-type formatter, instead
> of a more expressive set of information? I understand it makes easy for you,
> since it's the same code anyway, but it sounds contrived.
> 
> But ok, maybe just takes some getting used to.

Do you mean constructors like:
`Formatting(Justify type, int justifyAmount, char fillChar, <rest of 
options>)` ?

It currently lets you write:
`QStringFormatter::Formatting fmt;
fmt.setJustification(QStringFormatter::Left, 10, '-')`

With similar function for all the other formatting options.

>>> - Named replacements uses an alias for QPair<QString, T> called
>>>    Argument.
>>>    - e.g. `QStringFormatter("Hello, {Name}").arg({"Name", "World"});`
> 
> Please pay attention to Marc's post about when to use QPair, std::pair,
> std::tuple in APIs: https://www.kdab.com/tuple-pair-cpp-apis/

Thanks for the link. I agree with the points made in there, but it has 
never been my intention that developers would use Argument themselves 
for anything other than passing it directly to ::arg. Although rewriting 
Argument as a struct is little work.

> If this is just an initializer_list, fair enough, but we need to look into it.
> 
>>>    - A qMakePair-style function called `qArg` for use in
>>>      situations with template argument deduction trouble.
>>>      - e.g.
>>>
>>> `QStringFormatter("Hello, {Name}").arg(QStringFormatter::qArg("Name",
>>> 47));`
> 
> Like this. That looks mighty ugly.

It does. And I'm not sure how to do this part differently. Even if I 
rewrote Argument as a struct rather than a typedef for QPair I would 
still need qArg for when the class can't deduct the template arguments.
Or people would have to write
`QStringFormatter::Argument<int>("Name", 47)`
Which is what I hoped to avoid with "::qArg"

>>> Replacement format
>>> -----
>>>
>>> The replacement options now have formatting features matching
>>> QString::arg. The current options (open to change) are:
>>>
>>> - `L` for localization (localize numbers, like in QString::arg)
>>> - `</>/=` for justification. Left, right and center justification
>>>
>>>    - Followed by an optional padding character (excluding 1-9)
>>>    - Followed by field-width
>>>    - e.g. "==16" (pad using '=', centered, field-width 16),
>>>    
>>>      "<10" (left-justify using spaces, field-width 10),
>>>      ">-3" (right-justify using '-', field-width 3)
> 
> Is this inspired by any API? The one I can think of (printf) uses - for left
> justification and + for right justification. That would make just as much sense
> in using = for center.

Yes:
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/p0645r0.html
https://docs.python.org/3.6/library/string.html#format-specification-mini-language

Although I notice now that they use '^' for centering, and not '='. I 
should probably change to match that.

>>> - `b/B` for setting base. Supports bases 2-36. Using 'b' produces
>>>    lower-case letters for digits 10-35, and 'B' produces upper-case.
>>>    For bases 2-10 they make no difference.
> 
> With shorthands for hex and octal? Can you also make it so that a missing base
> number implies base 2?

No shorthands atm. but I can add those in.
'x'/'X' for hex, and 'o' for octal.

>>> - `:` everything after the colon gets put into an 'extra' field, more
>>>    on this later..
>>>    - e.g. `{:<10:this is the extra field}`
>>>    - or `{::yyyy-MM-dd HH:mm:ss}`
>>>
>>> Currently the formatting options can come in any order (e.g. "L<10"
>>> and "<10L" does the same, the only exception being ':').
>>> However it would be good to enforce some sort of order for the sake
>>> of consistency. With a defined order we could also change
>>> justification format from [<>=]cn to c[<>=]n, which would allow
>>> people to use 1-9 as a fill-character. If this is done, what should
>>> the order be like?
> 
> Agreed on requiring an order, at least in the beginning. What that should be,
> I don't know.
> 
>>> QString::arg compatibility
>>> -----
>>>
>>> Currently QString::arg compatibility is activated using a parameter
>>> in the constructor. All this does is let you use %nn style tokens and
>>> 'disable' use of the brace-style tokens. It also supports `%L` to
>>> enable localization of numbers, but any other formatting must be done
>>> using the `QStringFormatter::Formatting` class.
> 
> Can you already fully replace the QString::arg functions with
> QStringFormatter?

Unless there's something I've missed; yes, all of ::arg's formatting 
functions are implemented.

>>> API for formatting custom types
>>> -----
>>>
>>> One idea I've been experimenting with a little bit is using template
>>> specialization to deal with formatting custom types. To support a
>>> custom type you'd create a specialization of a struct called
>>> `Formatter`. It would use the `extra` field in `Formatting` which
>>> you could optionally parse for custom formatting options. The parser
>>> would be a separate class inheriting `Formatting` and be specified in
>>> the Formatter using a typedef.
>>>
>>> E.g.
>>> `struct QStringFormatter::Formatter<QDateTime>
>>> {
>>> typedef DateTimeInfo FormatType;
>>> QString operator()(const QDateTime &dateTime, const FormatType &format);
>>> }`
>>>
>>> `QStringFormatter` will then instantiate this struct when it receives
>>> a `QDateTime` object, and create a `FormatType` object to parse the
>>> data located in the `extra` field of formatting options. The
>>> `FormatType` object is then expected to store whatever info it needs
>>> and then the `Formatter` will use it later.
>>>
>>> Feedback on the approach, pitfalls etc. is much appreciated!
> 
> Very interesting! I'm just confused why you need two classes here, but I'll
> look into the details when I look at the implementation.

It was in case the developer didn't want/need extra formatting 
information for their type. Then they can write
`typedef QStringFormatter::Formatting FormatType;`
Formatting will then ignore the extra field and will later get passed to 
the class.

>>> Thanks,
>>>
>>>
>>> -- Mårten Nordheim
> 
> Good work!
> 



From thiago.macieira at intel.com  Fri Aug 11 18:10:23 2017
From: thiago.macieira at intel.com (Thiago Macieira)
Date: Fri, 11 Aug 2017 09:10:23 -0700
Subject: [Development] Introducing discussion about QStringFormatter
In-Reply-To: <582e7d1a-8e21-6f16-5ebc-7145cae3e738@qt.io>
References: <AMSPR02MB1023DCF16E23874F122637BE6E10@AMSPR02MB102.eurprd02.prod.outlook.com>
	<1663009.8z0fJaXk2y@tjmaciei-mobl1>
	<582e7d1a-8e21-6f16-5ebc-7145cae3e738@qt.io>
Message-ID: <10364726.Y4fmf8UK3S@tjmaciei-mobl1>

On sexta-feira, 11 de agosto de 2017 02:01:11 PDT Mårten Nordheim wrote:
> Replacement format
> 
> >>> -----
> >>> 
> >>> The replacement options now have formatting features matching
> >>> QString::arg. The current options (open to change) are:
> >>> 
> >>> - `L` for localization (localize numbers, like in QString::arg)
> >>> - `</>/=` for justification. Left, right and center justification
> >>> 
> >>> - Followed by an optional padding character (excluding 1-9)
> >>> - Followed by field-width
> >>> - e.g. "==16" (pad using '=', centered, field-width 16),
> >>> 
> >>> "<10" (left-justify using spaces, field-width 10),
> >>> ">-3" (right-justify using '-', field-width 3)
> > 
> > Is this inspired by any API? The one I can think of (printf) uses - for
> > left justification and + for right justification. That would make just as
> > much sense in using = for center.
> 
> Yes:
> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/p0645r0.html
> https://docs.python.org/3.6/library/string.html#format-specification-mini-la
> nguage
> 
> Although I notice now that they use '^' for centering, and not '='. I
> should probably change to match that.

Python is a compelling reason. A proposed paper for C++2a isn't, since we can 
give feedback and have that change. I don't see anything about left/center/
right in the C# page, while the Rust page says they use < and > for left and 
right, but ^ for center.

Has this ever been validated with people using RTL languages? The < and > 
symbols switch directions when used in RTL. For example:

    const char *fmt =
            "א {<10} ב"
            ;

Can you tell from the pasted text which direction this will justify? I 
intentionally put the semi-colon on a separate line so you can't tell which 
side the tail end of the line is. It's even worse in your text editor -- go 
ahead and copy it to Qt Creator to see how it formats this!

Or is that even a problem? Maybe it's even better this way?

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center



From marten.nordheim at qt.io  Mon Aug 14 16:12:30 2017
From: marten.nordheim at qt.io (=?UTF-8?Q?M=c3=a5rten_Nordheim?=)
Date: Mon, 14 Aug 2017 16:12:30 +0200
Subject: [Development] Introducing discussion about QStringFormatter
In-Reply-To: <10364726.Y4fmf8UK3S@tjmaciei-mobl1>
References: <AMSPR02MB1023DCF16E23874F122637BE6E10@AMSPR02MB102.eurprd02.prod.outlook.com>
	<1663009.8z0fJaXk2y@tjmaciei-mobl1>
	<582e7d1a-8e21-6f16-5ebc-7145cae3e738@qt.io>
	<10364726.Y4fmf8UK3S@tjmaciei-mobl1>
Message-ID: <cd353d0d-8861-8d55-857f-63df73bffad9@qt.io>

> Has this ever been validated with people using RTL languages? The < and >
> symbols switch directions when used in RTL. For example:
> 
>      const char *fmt =
>              "א {<10} ב"
>              ;
> 
> Can you tell from the pasted text which direction this will justify? I
> intentionally put the semi-colon on a separate line so you can't tell which
> side the tail end of the line is. It's even worse in your text editor -- go
> ahead and copy it to Qt Creator to see how it formats this!
> 
> Or is that even a problem? Maybe it's even better this way?
> 

When I first read this email the email-reader displayed the '{', '}' and 
'>' as flipped. So I would guess it's left. I was going to try it in 
python but I couldn't get it working without removing '<10'. I guess 
this is one of the situations where out-of-string formatting options are 
useful/needed. I'm not sure how to solve this otherwise.

And I see what you mean - navigating using the cursor in Qt Creator and 
VsCode and trying to guess where a character will appear if I press a 
button is quite the challenge.

Thanks,
- Mårten Nordheim


From thiago.macieira at intel.com  Mon Aug 14 18:20:14 2017
From: thiago.macieira at intel.com (Thiago Macieira)
Date: Mon, 14 Aug 2017 09:20:14 -0700
Subject: [Development] Introducing discussion about QStringFormatter
In-Reply-To: <cd353d0d-8861-8d55-857f-63df73bffad9@qt.io>
References: <AMSPR02MB1023DCF16E23874F122637BE6E10@AMSPR02MB102.eurprd02.prod.outlook.com>
	<10364726.Y4fmf8UK3S@tjmaciei-mobl1>
	<cd353d0d-8861-8d55-857f-63df73bffad9@qt.io>
Message-ID: <3024568.VCYigPjlT4@tjmaciei-mobl1>

On Monday, 14 August 2017 07:12:30 PDT Mårten Nordheim wrote:
> > Has this ever been validated with people using RTL languages? The < and >
> > 
> > symbols switch directions when used in RTL. For example:
> >      const char *fmt =
> >      
> >              "א {<10} ב"
> >              ;
> > 
> 
> When I first read this email the email-reader displayed the '{', '}' and
> '>' as flipped. So I would guess it's left. I was going to try it in
> python but I couldn't get it working without removing '<10'. I guess
> this is one of the situations where out-of-string formatting options are
> useful/needed. I'm not sure how to solve this otherwise.
> 
> And I see what you mean - navigating using the cursor in Qt Creator and
> VsCode and trying to guess where a character will appear if I press a
> button is quite the challenge.

I had the same problem, but I guess we can safely assume that anyone writing 
RTL text in their source code knows what they're doing and are used to the 
text direction changing (or they'll report bugs if the behaviour is wrong).

My question is whether people reading the code would be confused. There's two 
kind of people here:
 1) the people who wrote RTL
 2) a reviewer who doesn't read RTL (and isn't aware that < flips)

A - or + sign is clearly the same in RTL. So even if I don't know RTL, I know 
that "א {-10} ב" is left-justified (though I'll most likely ask the reviewer 
why the - is on the right of 10).

But like I said, maybe the < and > are beneficial, since in "א {<10} ב", the 
alignment is towards the Aleph, regardless of whether that's left or right. 
The sign that is visibly ">" is right alignment regardless of text direction, 
whereas the U+003C "less than" sign indicates alignment towards the beginning 
of the text.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center



From mwoehlke.floss at gmail.com  Tue Aug 15 18:05:06 2017
From: mwoehlke.floss at gmail.com (Matthew Woehlke)
Date: Tue, 15 Aug 2017 12:05:06 -0400
Subject: [Development] Introducing discussion about QStringFormatter
In-Reply-To: <1663009.8z0fJaXk2y@tjmaciei-mobl1>
References: <AMSPR02MB1023DCF16E23874F122637BE6E10@AMSPR02MB102.eurprd02.prod.outlook.com>
	<100198fb-c2c9-f090-153a-4d9527d717df@qt.io>
	<CALW8pfWHf2WbHYg56CDmTG1_ZZk7rKByaBa-yYXDi_zQNR+YYg@mail.gmail.com>
	<1663009.8z0fJaXk2y@tjmaciei-mobl1>
Message-ID: <e29eea15-7624-8652-aadd-7a7cbc3684e2@gmail.com>

On 2017-08-10 22:20, Thiago Macieira wrote:
> On quinta-feira, 10 de agosto de 2017 17:53:39 PDT Sze Howe Koh wrote:
>> On 10 August 2017 at 20:41, Mårten Nordheim <marten.nordheim at qt.io> wrote:
>> IMHO, "QFormat" isn't a suitable name. First, this class itself does
>> not describe a format, unlike:
> [cut]
>> For these reasons, I'd personally prefer sticking to "QStringFormatter".
> 
> Agreed, please use QStringFormatter.

Possibly there could be a qFormat (or even qFormatString) free function
providing extra convenience and abbreviation for the most common use
case? (This could be instead of the static ::format function...)

qFormatString is even less typing than QFormat::Format (13 vs. 15) but
minimal or no loss of clarity.

-- 
Matthew


From mwoehlke.floss at gmail.com  Tue Aug 15 18:05:06 2017
From: mwoehlke.floss at gmail.com (Matthew Woehlke)
Date: Tue, 15 Aug 2017 12:05:06 -0400
Subject: [Development] Introducing discussion about QStringFormatter
In-Reply-To: <1663009.8z0fJaXk2y@tjmaciei-mobl1>
References: <AMSPR02MB1023DCF16E23874F122637BE6E10@AMSPR02MB102.eurprd02.prod.outlook.com>
	<100198fb-c2c9-f090-153a-4d9527d717df@qt.io>
	<CALW8pfWHf2WbHYg56CDmTG1_ZZk7rKByaBa-yYXDi_zQNR+YYg@mail.gmail.com>
	<1663009.8z0fJaXk2y@tjmaciei-mobl1>
Message-ID: <e29eea15-7624-8652-aadd-7a7cbc3684e2@gmail.com>

On 2017-08-10 22:20, Thiago Macieira wrote:
> On quinta-feira, 10 de agosto de 2017 17:53:39 PDT Sze Howe Koh wrote:
>> On 10 August 2017 at 20:41, Mårten Nordheim <marten.nordheim at qt.io> wrote:
>> IMHO, "QFormat" isn't a suitable name. First, this class itself does
>> not describe a format, unlike:
> [cut]
>> For these reasons, I'd personally prefer sticking to "QStringFormatter".
> 
> Agreed, please use QStringFormatter.

Possibly there could be a qFormat (or even qFormatString) free function
providing extra convenience and abbreviation for the most common use
case? (This could be instead of the static ::format function...)

qFormatString is even less typing than QFormat::Format (13 vs. 15) but
minimal or no loss of clarity.

-- 
Matthew



From jani.heikkinen at qt.io  Wed Aug 16 13:43:49 2017
From: jani.heikkinen at qt.io (Jani Heikkinen)
Date: Wed, 16 Aug 2017 11:43:49 +0000
Subject: [Development] First Qt 5.6.3 snapshot available
Message-ID: <HE1PR02MB3132580C254D954F4580A35B9D820@HE1PR02MB3132.eurprd02.prod.outlook.com>

Hi,

We have finally first Qt 5.6.3 binary snapshot available for testing. Snapshot is available only via online installer and you can do clean installation or add it as a part of existing one. Detailed instructions here: https://wiki.qt.io/How_to_get_snapshot_via_online_installer . Note: snapshot can be found under 'Preview' node from installer ui.

Snapshot is based on https://codereview.qt-project.org/#/c/201968/ . RTA smoke is ran for this snapshot and it seems to be ok for bigger testing so please test the snapshot and report your effort via https://wiki.qt.io/Qt563_release_testing

Please test this snapshot as soon as possible; we need to get understanding where we are with the release. There is really much changes in since 5.6.2 which we released almost a year ago...

Br,
Jani

From marten.nordheim at qt.io  Thu Aug 17 10:20:09 2017
From: marten.nordheim at qt.io (=?UTF-8?Q?M=c3=a5rten_Nordheim?=)
Date: Thu, 17 Aug 2017 10:20:09 +0200
Subject: [Development] Introducing discussion about QStringFormatter
In-Reply-To: <3024568.VCYigPjlT4@tjmaciei-mobl1>
References: <AMSPR02MB1023DCF16E23874F122637BE6E10@AMSPR02MB102.eurprd02.prod.outlook.com>
	<10364726.Y4fmf8UK3S@tjmaciei-mobl1>
	<cd353d0d-8861-8d55-857f-63df73bffad9@qt.io>
	<3024568.VCYigPjlT4@tjmaciei-mobl1>
Message-ID: <35a56407-6943-c9fa-28a5-8b9f31c3fffa@qt.io>

On 14.08.2017 18:20, Thiago Macieira wrote:
> I had the same problem, but I guess we can safely assume that anyone writing
> RTL text in their source code knows what they're doing and are used to the
> text direction changing (or they'll report bugs if the behaviour is wrong).
> 
> My question is whether people reading the code would be confused. There's two
> kind of people here:
>   1) the people who wrote RTL
>   2) a reviewer who doesn't read RTL (and isn't aware that < flips)
> 
> A - or + sign is clearly the same in RTL. So even if I don't know RTL, I know
> that "א {-10} ב" is left-justified (though I'll most likely ask the reviewer
> why the - is on the right of 10).
> 
> But like I said, maybe the < and > are beneficial, since in "א {<10} ב", the
> alignment is towards the Aleph, regardless of whether that's left or right.
> The sign that is visibly ">" is right alignment regardless of text direction,
> whereas the U+003C "less than" sign indicates alignment towards the beginning
> of the text.
> 

It might be easier to reason about the alignment being towards a 
character rather than '-' being left/right depending on LTR or RTL. And 
reviewers would get used to it over time (at most there would be a 
little wasted time during reviews where reviewers ask why/how the 
options are valid, which you mentioned you would do anyway with the '-').

Thanks,
Mårten Nordheim


From marten.nordheim at qt.io  Thu Aug 17 10:24:50 2017
From: marten.nordheim at qt.io (=?UTF-8?Q?M=c3=a5rten_Nordheim?=)
Date: Thu, 17 Aug 2017 10:24:50 +0200
Subject: [Development] Introducing discussion about QStringFormatter
In-Reply-To: <e29eea15-7624-8652-aadd-7a7cbc3684e2@gmail.com>
References: <AMSPR02MB1023DCF16E23874F122637BE6E10@AMSPR02MB102.eurprd02.prod.outlook.com>
	<100198fb-c2c9-f090-153a-4d9527d717df@qt.io>
	<CALW8pfWHf2WbHYg56CDmTG1_ZZk7rKByaBa-yYXDi_zQNR+YYg@mail.gmail.com>
	<1663009.8z0fJaXk2y@tjmaciei-mobl1>
	<e29eea15-7624-8652-aadd-7a7cbc3684e2@gmail.com>
Message-ID: <26814457-3ab7-197a-a06a-a0fc3bff6a43@qt.io>

On 15.08.2017 18:05, Matthew Woehlke wrote:
> Possibly there could be a qFormat (or even qFormatString) free function
> providing extra convenience and abbreviation for the most common use
> case? (This could be instead of the static ::format function...)
> 
> qFormatString is even less typing than QFormat::Format (13 vs. 15) but
> minimal or no loss of clarity.

Good idea, this does make more sense as a shorthand rather than a static 
member function.

Thanks,
Mårten Nordheim


From announce at qt-project.org  Thu Aug 17 14:09:16 2017
From: announce at qt-project.org (List for announcements regarding Qt releases and development)
Date: Thu, 17 Aug 2017 12:09:16 +0000
Subject: [Development] [Announce] Qt Creator 4.4 RC released
Message-ID: <mailman.1198.1502972260.3911.announce@qt-project.org>

We are happy to announce the release of Qt Creator 4.4 RC!

http://blog.qt.io/blog/2017/08/17/qt-creator-4-4-rc-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 kollix at aon.at  Thu Aug 17 16:24:05 2017
From: kollix at aon.at (Martin Koller)
Date: Thu, 17 Aug 2017 16:24:05 +0200
Subject: [Development] QtWebKit is coming back (part 2)
In-Reply-To: <3501051500846330@web26g.yandex.ru>
References: <1711331493820157@web18j.yandex.ru>
	<1576000.qR13dCIJmj@lapi.koller>
	<3501051500846330@web26g.yandex.ru>
Message-ID: <2375263.ZnYfYMCM15@lapi.koller>

Hi,

is the 5.212 branch now as integrated in Qt as it was before in Qt 5.5 in the way that I can build Qt
with webkit support so that the help system and assistant also use it ?

What is the recommended way to build Qt and assistant to have webkit support ?

-- 
Best regards/Schöne Grüße

Martin
A: Because it breaks the logical sequence of discussion
Q: Why is top posting bad?

()  ascii ribbon campaign - against html e-mail 
/\                        - against proprietary attachments

Geschenkideen, Accessoires, Seifen, Kulinarisches: www.lillehus.at




From kollix at aon.at  Thu Aug 17 16:24:05 2017
From: kollix at aon.at (Martin Koller)
Date: Thu, 17 Aug 2017 16:24:05 +0200
Subject: [Development] QtWebKit is coming back (part 2)
In-Reply-To: <3501051500846330@web26g.yandex.ru>
References: <1711331493820157@web18j.yandex.ru>
	<1576000.qR13dCIJmj@lapi.koller>
	<3501051500846330@web26g.yandex.ru>
Message-ID: <2375263.ZnYfYMCM15@lapi.koller>

Hi,

is the 5.212 branch now as integrated in Qt as it was before in Qt 5.5 in the way that I can build Qt
with webkit support so that the help system and assistant also use it ?

What is the recommended way to build Qt and assistant to have webkit support ?

-- 
Best regards/Schöne Grüße

Martin
A: Because it breaks the logical sequence of discussion
Q: Why is top posting bad?

()  ascii ribbon campaign - against html e-mail 
/\                        - against proprietary attachments

Geschenkideen, Accessoires, Seifen, Kulinarisches: www.lillehus.at




From thiago.macieira at intel.com  Thu Aug 17 17:05:27 2017
From: thiago.macieira at intel.com (Thiago Macieira)
Date: Thu, 17 Aug 2017 08:05:27 -0700
Subject: [Development] QtWebKit is coming back (part 2)
In-Reply-To: <2375263.ZnYfYMCM15@lapi.koller>
References: <1711331493820157@web18j.yandex.ru>
	<3501051500846330@web26g.yandex.ru>
	<2375263.ZnYfYMCM15@lapi.koller>
Message-ID: <2488776.UWvkOuvzZc@tjmaciei-mobl1>

On Thursday, 17 August 2017 07:24:05 PDT Martin Koller wrote:
> Hi,
> 
> is the 5.212 branch now as integrated in Qt as it was before in Qt 5.5 in
> the way that I can build Qt with webkit support so that the help system and
> assistant also use it ?

No.

You need to use the split-build mechanism, the one that Linux distributions 
use. Build each of the regular modules individually, then qtwebkit, then 
qtwebkit-examples, qttools (for assistant).

> What is the recommended way to build Qt and assistant to have webkit support
> ?


-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center



From annulen at yandex.ru  Thu Aug 17 17:12:23 2017
From: annulen at yandex.ru (Konstantin Tokarev)
Date: Thu, 17 Aug 2017 18:12:23 +0300
Subject: [Development] QtWebKit is coming back (part 2)
In-Reply-To: <2488776.UWvkOuvzZc@tjmaciei-mobl1>
References: <1711331493820157@web18j.yandex.ru>
	<3501051500846330@web26g.yandex.ru>
	<2375263.ZnYfYMCM15@lapi.koller> <2488776.UWvkOuvzZc@tjmaciei-mobl1>
Message-ID: <511631502982743@web50g.yandex.ru>



17.08.2017, 18:06, "Thiago Macieira" <thiago.macieira at intel.com>:
> On Thursday, 17 August 2017 07:24:05 PDT Martin Koller wrote:
>>  Hi,
>>
>>  is the 5.212 branch now as integrated in Qt as it was before in Qt 5.5 in
>>  the way that I can build Qt with webkit support so that the help system and
>>  assistant also use it ?
>
> No.
>
> You need to use the split-build mechanism, the one that Linux distributions
> use. Build each of the regular modules individually, then qtwebkit, then
> qtwebkit-examples, qttools (for assistant).

Altrernatively, you can drop qtwebkit sources on the same level with other Qt modules,
however it will break if you customize installation paths, e.g. use custom libdir. Also,
cross-compilation is not supported in this way

>
>>  What is the recommended way to build Qt and assistant to have webkit support
>>  ?
>
> --
> 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

-- 
Regards,
Konstantin


From thiago.macieira at intel.com  Thu Aug 17 17:16:18 2017
From: thiago.macieira at intel.com (Thiago Macieira)
Date: Thu, 17 Aug 2017 08:16:18 -0700
Subject: [Development] QtWebKit is coming back (part 2)
In-Reply-To: <511631502982743@web50g.yandex.ru>
References: <1711331493820157@web18j.yandex.ru>
	<2488776.UWvkOuvzZc@tjmaciei-mobl1>
	<511631502982743@web50g.yandex.ru>
Message-ID: <1570107.06cTs7mIZn@tjmaciei-mobl1>

On Thursday, 17 August 2017 08:12:23 PDT Konstantin Tokarev wrote:
> Altrernatively, you can drop qtwebkit sources on the same level with other
> Qt modules, however it will break if you customize installation paths, e.g.
> use custom libdir. Also, cross-compilation is not supported in this way

That doesn't work anymore, as of this week, since commit 
5a0dc401fad4adccbd975392295d2c77d936900f.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center



From annulen at yandex.ru  Thu Aug 17 17:18:28 2017
From: annulen at yandex.ru (Konstantin Tokarev)
Date: Thu, 17 Aug 2017 18:18:28 +0300
Subject: [Development] QtWebKit is coming back (part 2)
In-Reply-To: <1570107.06cTs7mIZn@tjmaciei-mobl1>
References: <1711331493820157@web18j.yandex.ru>
	<2488776.UWvkOuvzZc@tjmaciei-mobl1>
	<511631502982743@web50g.yandex.ru> <1570107.06cTs7mIZn@tjmaciei-mobl1>
Message-ID: <524971502983108@web50g.yandex.ru>



17.08.2017, 18:17, "Thiago Macieira" <thiago.macieira at intel.com>:
> On Thursday, 17 August 2017 08:12:23 PDT Konstantin Tokarev wrote:
>>  Altrernatively, you can drop qtwebkit sources on the same level with other
>>  Qt modules, however it will break if you customize installation paths, e.g.
>>  use custom libdir. Also, cross-compilation is not supported in this way
>
> That doesn't work anymore, as of this week, since commit
> 5a0dc401fad4adccbd975392295d2c77d936900f.

Indeed, I forgot that .gitmodules is used for non-git builds too

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

-- 
Regards,
Konstantin


From julius.bullinger at intel.com  Fri Aug 18 11:50:57 2017
From: julius.bullinger at intel.com (Bullinger, Julius)
Date: Fri, 18 Aug 2017 09:50:57 +0000
Subject: [Development] Qt Creator 4.4 RC released
In-Reply-To: <mailman.1198.1502972260.3911.announce@qt-project.org>
References: <mailman.1198.1502972260.3911.announce@qt-project.org>
Message-ID: <7FC8D04D3E708B4AA8248F6D64E0CB2136BA9659@IRSMSX104.ger.corp.intel.com>

-----Original Message-----
From: Development [mailto:development-bounces+julius.bullinger=intel.com at qt-project.org] On Behalf Of List for announcements regarding Qt releases and development
Sent: Thursday, August 17, 2017 14:09
To: announce at qt-project.org
Subject: [Development] [Announce] Qt Creator 4.4 RC released

> We are happy to announce the release of Qt Creator 4.4 RC!
> 
> http://blog.qt.io/blog/2017/08/17/qt-creator-4-4-rc-released/

Hi Eike,

That looks like a great release. I was wondering whether there are any plans to make future pre-releases installable via the Qt installer.

At the moment, there's a bit of pain involved when you have to maintain two separate installations with separate user profiles (since the Creator instance bundled with Qt cannot be removed easily).

It would be really great if we were able to just upgrade and/or parallel install pre-releases via the Maintenance Tool.

Anyway, thanks a lot for your work and congratulations for the upcoming release.

Best regards,
Julius
Intel Deutschland GmbH
Registered Address: Am Campeon 10-12, 85579 Neubiberg, Germany
Tel: +49 89 99 8853-0, www.intel.de
Managing Directors: Christin Eisenschmid, Christian Lamprechter
Chairperson of the Supervisory Board: Nicole Lau
Registered Office: Munich
Commercial Register: Amtsgericht Muenchen HRB 186928

From iikka.eklund at qt.io  Fri Aug 18 13:44:52 2017
From: iikka.eklund at qt.io (Iikka Eklund)
Date: Fri, 18 Aug 2017 11:44:52 +0000
Subject: [Development] Qt Creator 4.4 RC released
In-Reply-To: <7FC8D04D3E708B4AA8248F6D64E0CB2136BA9659@IRSMSX104.ger.corp.intel.com>
References: <mailman.1198.1502972260.3911.announce@qt-project.org>,
	<7FC8D04D3E708B4AA8248F6D64E0CB2136BA9659@IRSMSX104.ger.corp.intel.com>
Message-ID: <HE1PR02MB31622DA956ECE2032EA5964885800@HE1PR02MB3162.eurprd02.prod.outlook.com>

> I was wondering whether there are any plans to make future pre-releases installable via the Qt installer.


This is actually planned already. Exact schedule is not know yet, but that is quite high on the current work list.




Iikka Eklund
Senior Software Engineer

The Qt Company
Elektroniikkatie 13
90590, Oulu, Finland
iikka.eklund at qt.io
http://qt.io<http://qt.io/>




________________________________
From: Development <development-bounces+iikka.eklund=qt.io at qt-project.org> on behalf of Bullinger, Julius <julius.bullinger at intel.com>
Sent: Friday, August 18, 2017 12:50:57 PM
To: development at qt-project.org
Subject: Re: [Development] Qt Creator 4.4 RC released

-----Original Message-----
From: Development [mailto:development-bounces+julius.bullinger=intel.com at qt-project.org] On Behalf Of List for announcements regarding Qt releases and development
Sent: Thursday, August 17, 2017 14:09
To: announce at qt-project.org
Subject: [Development] [Announce] Qt Creator 4.4 RC released

> We are happy to announce the release of Qt Creator 4.4 RC!
>
> http://blog.qt.io/blog/2017/08/17/qt-creator-4-4-rc-released/

Hi Eike,

That looks like a great release. I was wondering whether there are any plans to make future pre-releases installable via the Qt installer.

At the moment, there's a bit of pain involved when you have to maintain two separate installations with separate user profiles (since the Creator instance bundled with Qt cannot be removed easily).

It would be really great if we were able to just upgrade and/or parallel install pre-releases via the Maintenance Tool.

Anyway, thanks a lot for your work and congratulations for the upcoming release.

Best regards,
Julius
Intel Deutschland GmbH
Registered Address: Am Campeon 10-12, 85579 Neubiberg, Germany
Tel: +49 89 99 8853-0, www.intel.de<http://www.intel.de>
Managing Directors: Christin Eisenschmid, Christian Lamprechter
Chairperson of the Supervisory Board: Nicole Lau
Registered Office: Munich
Commercial Register: Amtsgericht Muenchen HRB 186928
_______________________________________________
Development mailing list
Development at qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20170818/8fbf8168/attachment.html>

From edward.welbourne at qt.io  Fri Aug 18 14:17:07 2017
From: edward.welbourne at qt.io (Edward Welbourne)
Date: Fri, 18 Aug 2017 12:17:07 +0000
Subject: [Development] Coding style for lambdas,
 particularly their open-brace
Message-ID: <AM4PR02MB3249F397368846F758EE5B1187800@AM4PR02MB3249.eurprd02.prod.outlook.com>

Hi all,

We have a draft policy for lambdas at [0], in a section that begins with

  Note: This section is not an accepted convention yet.
  This section serves as baseline for further discussions.

That section is now a quarter decade old; it's had a few updates since
it was added (2015-02-27), so may fairly be said to be evolving (albeit
it's had more formatting changes than substantive ones); but perhaps
it's about time we agreed that at least its low-level bits about
formatting can be promoted to [1], without such a caveat.

* [0] https://wiki.qt.io/Coding_Conventions#Conventions_for_C.2B.2B11_usage
* [1] https://wiki.qt.io/Qt_Coding_Style#Braces

In particular, I'd like to (at least) amend the first exception in [1],

  Function implementations and class declarations always have the left
  brace on the start of a line:

to include "(but not lambdas)" in a judicious place, so that lambdas are
excluded from the exception and fit into our general pattern, putting
the open-brace on the same line as its controlling preamble: e.g.

  Function implementations (but not lambdas) and class declarations
  always have the left brace on the start of a line:

Does anyone object to this minimal change ?
(How long do I have to wait before I can claim lazy consensus ?)

	Eddy.


From annulen at yandex.ru  Fri Aug 18 14:20:11 2017
From: annulen at yandex.ru (Konstantin Tokarev)
Date: Fri, 18 Aug 2017 15:20:11 +0300
Subject: [Development] Coding style for lambdas,
 particularly their open-brace
In-Reply-To: <AM4PR02MB3249F397368846F758EE5B1187800@AM4PR02MB3249.eurprd02.prod.outlook.com>
References: <AM4PR02MB3249F397368846F758EE5B1187800@AM4PR02MB3249.eurprd02.prod.outlook.com>
Message-ID: <27341503058811@web50o.yandex.ru>



18.08.2017, 15:17, "Edward Welbourne" <edward.welbourne at qt.io>:
> Hi all,
>
> We have a draft policy for lambdas at [0], in a section that begins with
>
>   Note: This section is not an accepted convention yet.
>   This section serves as baseline for further discussions.
>
> That section is now a quarter decade old; it's had a few updates since
> it was added (2015-02-27), so may fairly be said to be evolving (albeit
> it's had more formatting changes than substantive ones); but perhaps
> it's about time we agreed that at least its low-level bits about
> formatting can be promoted to [1], without such a caveat.
>
> * [0] https://wiki.qt.io/Coding_Conventions#Conventions_for_C.2B.2B11_usage
> * [1] https://wiki.qt.io/Qt_Coding_Style#Braces
>
> In particular, I'd like to (at least) amend the first exception in [1],
>
>   Function implementations and class declarations always have the left
>   brace on the start of a line:
>
> to include "(but not lambdas)" in a judicious place, so that lambdas are
> excluded from the exception and fit into our general pattern, putting
> the open-brace on the same line as its controlling preamble: e.g.
>
>   Function implementations (but not lambdas) and class declarations
>   always have the left brace on the start of a line:

+1

>
> Does anyone object to this minimal change ?
> (How long do I have to wait before I can claim lazy consensus ?)
>
>         Eddy.
> _______________________________________________
> Development mailing list
> Development at qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development

-- 
Regards,
Konstantin


From markg85 at gmail.com  Fri Aug 18 16:11:49 2017
From: markg85 at gmail.com (Mark Gaiser)
Date: Fri, 18 Aug 2017 16:11:49 +0200
Subject: [Development] Coding style for lambdas,
 particularly their open-brace
In-Reply-To: <AM4PR02MB3249F397368846F758EE5B1187800@AM4PR02MB3249.eurprd02.prod.outlook.com>
References: <AM4PR02MB3249F397368846F758EE5B1187800@AM4PR02MB3249.eurprd02.prod.outlook.com>
Message-ID: <CAPd6JnHcLxwbzQ7aFmwCq3f0r5OdVV+GbTDxtk+tg8APqa-w5w@mail.gmail.com>

On Fri, Aug 18, 2017 at 2:17 PM, Edward Welbourne <edward.welbourne at qt.io>
wrote:

> Hi all,
>
> We have a draft policy for lambdas at [0], in a section that begins with
>
>   Note: This section is not an accepted convention yet.
>   This section serves as baseline for further discussions.
>
> That section is now a quarter decade old; it's had a few updates since
> it was added (2015-02-27), so may fairly be said to be evolving (albeit
> it's had more formatting changes than substantive ones); but perhaps
> it's about time we agreed that at least its low-level bits about
> formatting can be promoted to [1], without such a caveat.
>
> * [0] https://wiki.qt.io/Coding_Conventions#Conventions_for_C.
> 2B.2B11_usage
> * [1] https://wiki.qt.io/Qt_Coding_Style#Braces
>
> In particular, I'd like to (at least) amend the first exception in [1],
>
>   Function implementations and class declarations always have the left
>   brace on the start of a line:
>
> to include "(but not lambdas)" in a judicious place, so that lambdas are
> excluded from the exception and fit into our general pattern, putting
> the open-brace on the same line as its controlling preamble: e.g.
>
>   Function implementations (but not lambdas) and class declarations
>   always have the left brace on the start of a line:
>
> Does anyone object to this minimal change ?
> (How long do I have to wait before I can claim lazy consensus ?)
>
>         Eddy.
> _______________________________________________
> Development mailing list
> Development at qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development
>

The explicit return type rule should probably be changed, as that was for
VS2010. And that compiler has been dropped in 5.7.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20170818/00be227c/attachment.html>

From thiago.macieira at intel.com  Fri Aug 18 20:57:09 2017
From: thiago.macieira at intel.com (Thiago Macieira)
Date: Fri, 18 Aug 2017 11:57:09 -0700
Subject: [Development] DTLS support in Qt
Message-ID: <300687443.6vTp0T0AZJ@tjmaciei-mobl1>

Hello

Last year at QCS, I joined the Networking discussions and one of my requests 
was DTLS support. Everything else needed to support IoT was already in place, 
in flight (the QNetworkDatagram class) or I could do it myself (new API for 
QNetworkInterface coming soon).

DTLS was the only thing I wasn't allowed to contribute and no one else has 
stepped up in the last year.

So I decided to implement it myself. I've now got a proof of concept to 
support DTLS over QUdpSocket and it already manages to connect one client and 
server, verify the certificate (haven't tested failure) and communicate with 
itself, with the "openssl" binary and with "gnutls-serv" binary. I've got 
approval from Intel to contribute it.

I'd like Qt to have DTLS support. Should *I* contribute it? This question is 
important because there used to be restrictions on "US persons" contributing 
cryptography-related code. I need an answer from the Qt Project.

If NO:
Then who will write it? When? Can you finish it by Qt 5.11 feature freeze?

If YES:
Then what module should it be in?
 a) QtNetwork
	Would be ideal, as there are quite a few changes to QSslSocketBackend, 
	QSslContext, etc. that are required. We'd also reuse the dynamic OpenSSL 
	loading. If I can implement DTLS support in QtNetwork, I can make these 
	changes myself.
 b) another module, outside of qtbase
	This module would be licenced LGPLv3, no commercial.
	Not ideal, but workable. The changes I mentioned above would still need to 
	be implemented, so we'd need a volunteer to implement them and work with 	
	me. It shouldn't be too difficult.
 c) not in Qt
	Really not ideal. Would make for a crappy API and would increase the 
	development time at least threefold, probably more.

I'll be really disappointed if the answer is "no, we won't accept this 
contribution and we won't develop it for 5.11 either".

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center



From timur.pocheptsov at qt.io  Fri Aug 18 22:07:13 2017
From: timur.pocheptsov at qt.io (Timur Pocheptsov)
Date: Fri, 18 Aug 2017 20:07:13 +0000
Subject: [Development] DTLS support in Qt
In-Reply-To: <300687443.6vTp0T0AZJ@tjmaciei-mobl1>
References: <300687443.6vTp0T0AZJ@tjmaciei-mobl1>
Message-ID: <HE1PR0202MB25887BCA2047FEB19BDA69CD91800@HE1PR0202MB2588.eurprd02.prod.outlook.com>

> Should *I* contribute it?


Well, yes, please, otherwise I'll do it myself 😊


> If NO:
Then who will write it? When?


I will, 5.11.


> Then what module should it be in?


Option 'a' is optimal.

________________________________
From: Development <development-bounces+timur.pocheptsov=qt.io at qt-project.org> on behalf of Thiago Macieira <thiago.macieira at intel.com>
Sent: Friday, August 18, 2017 8:57:09 PM
To: development at qt-project.org
Subject: [Development] DTLS support in Qt

Hello

Last year at QCS, I joined the Networking discussions and one of my requests
was DTLS support. Everything else needed to support IoT was already in place,
in flight (the QNetworkDatagram class) or I could do it myself (new API for
QNetworkInterface coming soon).

DTLS was the only thing I wasn't allowed to contribute and no one else has
stepped up in the last year.

So I decided to implement it myself. I've now got a proof of concept to
support DTLS over QUdpSocket and it already manages to connect one client and
server, verify the certificate (haven't tested failure) and communicate with
itself, with the "openssl" binary and with "gnutls-serv" binary. I've got
approval from Intel to contribute it.

I'd like Qt to have DTLS support. Should *I* contribute it? This question is
important because there used to be restrictions on "US persons" contributing
cryptography-related code. I need an answer from the Qt Project.

If NO:
Then who will write it? When? Can you finish it by Qt 5.11 feature freeze?

If YES:
Then what module should it be in?
 a) QtNetwork
        Would be ideal, as there are quite a few changes to QSslSocketBackend,
        QSslContext, etc. that are required. We'd also reuse the dynamic OpenSSL
        loading. If I can implement DTLS support in QtNetwork, I can make these
        changes myself.
 b) another module, outside of qtbase
        This module would be licenced LGPLv3, no commercial.
        Not ideal, but workable. The changes I mentioned above would still need to
        be implemented, so we'd need a volunteer to implement them and work with
        me. It shouldn't be too difficult.
 c) not in Qt
        Really not ideal. Would make for a crappy API and would increase the
        development time at least threefold, probably more.

I'll be really disappointed if the answer is "no, we won't accept this
contribution and we won't develop it for 5.11 either".

--
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: <http://lists.qt-project.org/pipermail/development/attachments/20170818/f53230a4/attachment.html>

From thiago.macieira at intel.com  Fri Aug 18 22:11:26 2017
From: thiago.macieira at intel.com (Thiago Macieira)
Date: Fri, 18 Aug 2017 13:11:26 -0700
Subject: [Development] DTLS support in Qt
In-Reply-To: <HE1PR0202MB25887BCA2047FEB19BDA69CD91800@HE1PR0202MB2588.eurprd02.prod.outlook.com>
References: <300687443.6vTp0T0AZJ@tjmaciei-mobl1>
	<HE1PR0202MB25887BCA2047FEB19BDA69CD91800@HE1PR0202MB2588.eurprd02.prod.outlook.com>
Message-ID: <17754295.D1oIBrrLcz@tjmaciei-mobl1>

On Friday, 18 August 2017 13:07:13 PDT Timur Pocheptsov wrote:
> > Should *I* contribute it?
> 
> Well, yes, please, otherwise I'll do it myself 😊

I think I need an answer from Lars or Tuukka, because of the legal 
implications.

> > If NO:
> 
> Then who will write it? When?
> 
> I will, 5.11.

Cool! I'll start a new thread discussing the non-crypto related parts until we 
get the conclusion of what I can or cannot be part of.

> > Then what module should it be in?
> 
> Option 'a' is optimal.

No doubt.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center



From thiago.macieira at intel.com  Fri Aug 18 22:37:52 2017
From: thiago.macieira at intel.com (Thiago Macieira)
Date: Fri, 18 Aug 2017 13:37:52 -0700
Subject: [Development] Multiclient UDP server
Message-ID: <2187944.kxPGXOVccJ@tjmaciei-mobl1>

Related to the DTLS discussion, but I'll try to keep this free from crypto for 
now.

The question is how to write a multi-client server operating on UDP, not TCP. 
It would be nice to understand SCTP case too (and maybe DCCP in the future).

On TCP, this is easy:
1) you create a socket, bind it and then put it in LISTENING mode
2) every time a new TCP connection arrives, you accept() a new socket
3) the server socket is from now on independent of the client

In our API, the QTcpServer creates new QTcpSockets and they're from that point 
on independent.

In UDP, that's different. There are two ways to proceed:

A) single UDP socket in unconnected mode

The code identifies each different client by the source address. 
QNetworkDatagram makes this easy, since it holds for you the source address 
and using makeReply() creates a QNetworkDatagram that you can use to reply.

Pros: uses a single socket, so limits the resource usage.

Cons: scalability. Since it's the same socket, only one thread can read from 
it at a time. You may pass the QNetworkDatagram to another thread to process 
the data, but you need to centralise sending of replies (QUdpSocket 
limitation, not of the OS API).

We don't need to implement anything to support this: that is simply QUdpSocket 
as it is today.

B) multiple UDP sockets

This is similar to TCP. Whenever a new client is detected, we create a new UDP 
socket and put it in connected mode with that particular client. Once you do 
that, this socket will only receive datagrams from that client, whereas the 
unconnected socket will not.

Pros: scalability, since you can move the QUdpSocket to another thread; the 
connected datagram socket has another advantage that it can relay ICMP errors 
like "port unreachable" to the upper level, whereas the unconnected one won't. 
I also believe the connected mode socket can do Path MTU calculation.

Cons: more resources, but more importantly, there's a race condition: the 
unconnected socket which you received the initial packet from the new client 
on may have queued more datagrams. Those datagrams can be:
 - from the same client
 - from other clients

So we are in a catch-22 situation: if you connect() this socket and create a 
new unconnected one, any packets from other clients will not be seen. If you 
create a new socket and connect() it, you may miss any packets from the same 
client. I think that for both CoAP and DTLS, we'd opt for connect()ing the new 
socket, since the client wouldn't be sending new commands until it receives a 
reply from us. That reply resolves the problem of race condition.

[food for thought: what happens if we receive a retransmission?]


So questions:
 - do we attempt to provide a "QUdpServer" or augment QUdpSocket's API to 
support (B) above? Or do we provide only a QDtlsServer API that implements 
(B)? This "QUdpServer" would be useful to implement a unencrypted CoAP server 
("coap"). It's not very difficult to rewrite the code, but the choice becomes 
hairy if we want to support both unencrypted and encrypted CoAP ("coaps").

 - do we need a QDtlsSocket at all, or just a wrapper on top of QUdpSocket? 
One advantage of having the class is that you could implement both "coap" and 
"coaps" clients on top of a plain QUdpSocket pointer, not having to worry  
about the encryption.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center



From sean.harmer at kdab.com  Sat Aug 19 11:19:20 2017
From: sean.harmer at kdab.com (Sean Harmer)
Date: Sat, 19 Aug 2017 10:19:20 +0100
Subject: [Development] Random CI Failures
Message-ID: <61ef71bd-0877-17cc-48ef-efbea832ed73@kdab.com>

Hi,


we seem to be getting a large number of random CI failures when trying 
to integrate Qt 3D changes for the last week or so. It manifests itelf 
as the win8-mingw node failing but no log file is recorded. On the odd 
occasion we get a log file it's like the node just stopped, there's no 
error. This is hitting us around 50% of the time which is making getting 
changees in very frustrating. Could somebody look into what is going on 
please?

Many thanks,

Sean



From Simon.Hausmann at qt.io  Sat Aug 19 12:59:56 2017
From: Simon.Hausmann at qt.io (Simon Hausmann)
Date: Sat, 19 Aug 2017 10:59:56 +0000
Subject: [Development] Random CI Failures
In-Reply-To: <61ef71bd-0877-17cc-48ef-efbea832ed73@kdab.com>
References: <61ef71bd-0877-17cc-48ef-efbea832ed73@kdab.com>
Message-ID: <6A14C47D-72B6-4BD6-84CB-BA5CF460B536@qt.io>

Hi,

We've had file system corruption in our base Windows images for the past weeks. Yesterday late afternoon I finally managed to get hold of it and fix it. This may have been the cause of your trouble. Did you still see failures yesterday evening and today?

Simon

> On 19. Aug 2017, at 11:19, Sean Harmer <sean.harmer at kdab.com> wrote:
> 
> Hi,
> 
> 
> we seem to be getting a large number of random CI failures when trying to integrate Qt 3D changes for the last week or so. It manifests itelf as the win8-mingw node failing but no log file is recorded. On the odd occasion we get a log file it's like the node just stopped, there's no error. This is hitting us around 50% of the time which is making getting changees in very frustrating. Could somebody look into what is going on please?
> 
> Many thanks,
> 
> Sean
> 
> _______________________________________________
> Development mailing list
> Development at qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development


From sean.harmer at kdab.com  Sat Aug 19 13:57:18 2017
From: sean.harmer at kdab.com (Sean Harmer)
Date: Sat, 19 Aug 2017 12:57:18 +0100
Subject: [Development] Random CI Failures
In-Reply-To: <6A14C47D-72B6-4BD6-84CB-BA5CF460B536@qt.io>
References: <61ef71bd-0877-17cc-48ef-efbea832ed73@kdab.com>
	<6A14C47D-72B6-4BD6-84CB-BA5CF460B536@qt.io>
Message-ID: <aa554609-4307-c399-242d-a9c17f762f67@kdab.com>

Hi Simon,

On 19/08/2017 11:59, Simon Hausmann wrote:
> Hi,
>
> We've had file system corruption in our base Windows images for the past weeks. Yesterday late afternoon I finally managed to get hold of it and fix it. This may have been the cause of your trouble. Did you still see failures yesterday evening and today?

Ah thanks that may well explain it. I don't think I've seen it since 
yesterday lunchtime'ish. So hopefully you've already squashed it. :)

Thanks,

Sean

-- 
Dr Sean Harmer | sean.harmer at kdab.com | Managing Director UK
KDAB (UK) Ltd, a KDAB Group company
Tel. +44 (0)1625 809908; Sweden (HQ) +46-563-540090
Mobile: +44 (0)7545 140604
KDAB - Qt Experts


From sean.harmer at kdab.com  Sat Aug 19 20:56:57 2017
From: sean.harmer at kdab.com (Sean Harmer)
Date: Sat, 19 Aug 2017 19:56:57 +0100
Subject: [Development] Random CI Failures
In-Reply-To: <aa554609-4307-c399-242d-a9c17f762f67@kdab.com>
References: <61ef71bd-0877-17cc-48ef-efbea832ed73@kdab.com>
	<6A14C47D-72B6-4BD6-84CB-BA5CF460B536@qt.io>
	<aa554609-4307-c399-242d-a9c17f762f67@kdab.com>
Message-ID: <2769489.TRaBl3jQOL@titan>

On Saturday, 19 August 2017 12:57:18 BST Sean Harmer wrote:
> Hi Simon,
> 
> On 19/08/2017 11:59, Simon Hausmann wrote:
> > Hi,
> > 
> > We've had file system corruption in our base Windows images for the past
> > weeks. Yesterday late afternoon I finally managed to get hold of it and
> > fix it. This may have been the cause of your trouble. Did you still see
> > failures yesterday evening and today?
> Ah thanks that may well explain it. I don't think I've seen it since
> yesterday lunchtime'ish. So hopefully you've already squashed it. :)

Spoke too soon. Simon already knows, but for the record, it happened twice 
more today on:

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

then eventually worked. But even on the successful run there is no log file 
recorded.

Cheers,

Sean
--
Dr Sean Harmer | sean.harmer at kdab.com | Managing Director UK
Klarälvdalens Datakonsult AB, a KDAB Group company
Tel. UK +44 (0)1625 809908, Sweden (HQ) +46-563-540090
KDAB - Qt Experts - Platform-independent software solutions


From sean.harmer at kdab.com  Mon Aug 21 11:12:15 2017
From: sean.harmer at kdab.com (Sean Harmer)
Date: Mon, 21 Aug 2017 10:12:15 +0100
Subject: [Development] Random CI Failures
In-Reply-To: <2769489.TRaBl3jQOL@titan>
References: <61ef71bd-0877-17cc-48ef-efbea832ed73@kdab.com>
	<aa554609-4307-c399-242d-a9c17f762f67@kdab.com>
	<2769489.TRaBl3jQOL@titan>
Message-ID: <1733006.e5EiAlo4zN@titan>

And again today on:

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

Same configuration type, win8-mingw. Can we remove this from the active set of 
configurations for qt3d until this is resolved please?

Thanks,

Sean

On Saturday, 19 August 2017 19:56:57 BST Sean Harmer wrote:
> On Saturday, 19 August 2017 12:57:18 BST Sean Harmer wrote:
> > Hi Simon,
> > 
> > On 19/08/2017 11:59, Simon Hausmann wrote:
> > > Hi,
> > > 
> > > We've had file system corruption in our base Windows images for the past
> > > weeks. Yesterday late afternoon I finally managed to get hold of it and
> > > fix it. This may have been the cause of your trouble. Did you still see
> > > failures yesterday evening and today?
> > 
> > Ah thanks that may well explain it. I don't think I've seen it since
> > yesterday lunchtime'ish. So hopefully you've already squashed it. :)
> 
> Spoke too soon. Simon already knows, but for the record, it happened twice
> more today on:
> 
> https://codereview.qt-project.org/#/c/202556/
> 
> then eventually worked. But even on the successful run there is no log file
> recorded.
> 
> Cheers,
> 
> Sean
> --
> Dr Sean Harmer | sean.harmer at kdab.com | Managing Director UK
> Klarälvdalens Datakonsult AB, a KDAB Group company
> Tel. UK +44 (0)1625 809908, Sweden (HQ) +46-563-540090
> KDAB - Qt Experts - Platform-independent software solutions
> _______________________________________________
> Development mailing list
> Development at qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development


-- 
--
Dr Sean Harmer | sean.harmer at kdab.com | Managing Director UK
Klarälvdalens Datakonsult AB, a KDAB Group company
Tel. UK +44 (0)1625 809908, Sweden (HQ) +46-563-540090
KDAB - Qt Experts - Platform-independent software solutions


From Simon.Hausmann at qt.io  Mon Aug 21 11:14:41 2017
From: Simon.Hausmann at qt.io (Simon Hausmann)
Date: Mon, 21 Aug 2017 09:14:41 +0000
Subject: [Development] Random CI Failures
In-Reply-To: <1733006.e5EiAlo4zN@titan>
References: <61ef71bd-0877-17cc-48ef-efbea832ed73@kdab.com>
	<aa554609-4307-c399-242d-a9c17f762f67@kdab.com>
	<2769489.TRaBl3jQOL@titan>,<1733006.e5EiAlo4zN@titan>
Message-ID: <VI1PR02MB1006741553E78DA3F83551198C870@VI1PR02MB1006.eurprd02.prod.outlook.com>

Hi,


It's windows 7 actually. I'm working on fixing this. The basic issue appears to be that the virtual machine is loosing network connectivity. Unfortunately we can't use the "native" virtio drivers as somehow the x86 version doesn't work :(. At the moment we're using an emulated e1000, but I'm trying to switch over the "other" paravirtualized vmxnet3 driver that we've been using before.



Simon

________________________________
From: Development <development-bounces+simon.hausmann=qt.io at qt-project.org> on behalf of Sean Harmer <sean.harmer at kdab.com>
Sent: Monday, August 21, 2017 11:12:15 AM
To: development at qt-project.org
Subject: Re: [Development] Random CI Failures

And again today on:

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

Same configuration type, win8-mingw. Can we remove this from the active set of
configurations for qt3d until this is resolved please?

Thanks,

Sean

On Saturday, 19 August 2017 19:56:57 BST Sean Harmer wrote:
> On Saturday, 19 August 2017 12:57:18 BST Sean Harmer wrote:
> > Hi Simon,
> >
> > On 19/08/2017 11:59, Simon Hausmann wrote:
> > > Hi,
> > >
> > > We've had file system corruption in our base Windows images for the past
> > > weeks. Yesterday late afternoon I finally managed to get hold of it and
> > > fix it. This may have been the cause of your trouble. Did you still see
> > > failures yesterday evening and today?
> >
> > Ah thanks that may well explain it. I don't think I've seen it since
> > yesterday lunchtime'ish. So hopefully you've already squashed it. :)
>
> Spoke too soon. Simon already knows, but for the record, it happened twice
> more today on:
>
> https://codereview.qt-project.org/#/c/202556/
>
> then eventually worked. But even on the successful run there is no log file
> recorded.
>
> Cheers,
>
> Sean
> --
> Dr Sean Harmer | sean.harmer at kdab.com | Managing Director UK
> Klarälvdalens Datakonsult AB, a KDAB Group company
> Tel. UK +44 (0)1625 809908, Sweden (HQ) +46-563-540090
> KDAB - Qt Experts - Platform-independent software solutions
> _______________________________________________
> Development mailing list
> Development at qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development


--
--
Dr Sean Harmer | sean.harmer at kdab.com | Managing Director UK
Klarälvdalens Datakonsult AB, a KDAB Group company
Tel. UK +44 (0)1625 809908, Sweden (HQ) +46-563-540090
KDAB - Qt Experts - Platform-independent software solutions
_______________________________________________
Development mailing list
Development at qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20170821/399617f1/attachment.html>

From sean.harmer at kdab.com  Mon Aug 21 11:16:09 2017
From: sean.harmer at kdab.com (Sean Harmer)
Date: Mon, 21 Aug 2017 10:16:09 +0100
Subject: [Development] Random CI Failures
In-Reply-To: <VI1PR02MB1006741553E78DA3F83551198C870@VI1PR02MB1006.eurprd02.prod.outlook.com>
References: <61ef71bd-0877-17cc-48ef-efbea832ed73@kdab.com>
	<1733006.e5EiAlo4zN@titan>
	<VI1PR02MB1006741553E78DA3F83551198C870@VI1PR02MB1006.eurprd02.prod.outlook.com>
Message-ID: <1925934.e7iqg34uHn@titan>

Hi Simon,

thanks for the update. Fingers crossed that resolves it.

Cheers,

Sean

On Monday, 21 August 2017 10:14:41 BST Simon Hausmann wrote:
> Hi,
> 
> 
> It's windows 7 actually. I'm working on fixing this. The basic issue appears
> to be that the virtual machine is loosing network connectivity.
> Unfortunately we can't use the "native" virtio drivers as somehow the x86
> version doesn't work :(. At the moment we're using an emulated e1000, but
> I'm trying to switch over the "other" paravirtualized vmxnet3 driver that
> we've been using before.
> 
> 
> 
> Simon
> 
> ________________________________
> From: Development <development-bounces+simon.hausmann=qt.io at qt-project.org>
> on behalf of Sean Harmer <sean.harmer at kdab.com> Sent: Monday, August 21,
> 2017 11:12:15 AM
> To: development at qt-project.org
> Subject: Re: [Development] Random CI Failures
> 
> And again today on:
> 
> https://codereview.qt-project.org/#/c/194936/
> 
> Same configuration type, win8-mingw. Can we remove this from the active set
> of configurations for qt3d until this is resolved please?
> 
> Thanks,
> 
> Sean
> 
> On Saturday, 19 August 2017 19:56:57 BST Sean Harmer wrote:
> > On Saturday, 19 August 2017 12:57:18 BST Sean Harmer wrote:
> > > Hi Simon,
> > > 
> > > On 19/08/2017 11:59, Simon Hausmann wrote:
> > > > Hi,
> > > > 
> > > > We've had file system corruption in our base Windows images for the
> > > > past
> > > > weeks. Yesterday late afternoon I finally managed to get hold of it
> > > > and
> > > > fix it. This may have been the cause of your trouble. Did you still
> > > > see
> > > > failures yesterday evening and today?
> > > 
> > > Ah thanks that may well explain it. I don't think I've seen it since
> > > yesterday lunchtime'ish. So hopefully you've already squashed it. :)
> > 
> > Spoke too soon. Simon already knows, but for the record, it happened twice
> > more today on:
> > 
> > https://codereview.qt-project.org/#/c/202556/
> > 
> > then eventually worked. But even on the successful run there is no log
> > file
> > recorded.
> > 
> > Cheers,
> > 
> > Sean
> > --
> > Dr Sean Harmer | sean.harmer at kdab.com | Managing Director UK
> > Klarälvdalens Datakonsult AB, a KDAB Group company
> > Tel. UK +44 (0)1625 809908, Sweden (HQ) +46-563-540090
> > KDAB - Qt Experts - Platform-independent software solutions
> > _______________________________________________
> > Development mailing list
> > Development at qt-project.org
> > http://lists.qt-project.org/mailman/listinfo/development
> 
> --
> --
> Dr Sean Harmer | sean.harmer at kdab.com | Managing Director UK
> Klarälvdalens Datakonsult AB, a KDAB Group company
> Tel. UK +44 (0)1625 809908, Sweden (HQ) +46-563-540090
> KDAB - Qt Experts - Platform-independent software solutions
> _______________________________________________
> Development mailing list
> Development at qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development


-- 
--
Dr Sean Harmer | sean.harmer at kdab.com | Managing Director UK
Klarälvdalens Datakonsult AB, a KDAB Group company
Tel. UK +44 (0)1625 809908, Sweden (HQ) +46-563-540090
KDAB - Qt Experts - Platform-independent software solutions


From andre.hartmann at iseg-hv.de  Tue Aug 22 08:21:22 2017
From: andre.hartmann at iseg-hv.de (=?UTF-8?Q?Andr=c3=a9_Hartmann?=)
Date: Tue, 22 Aug 2017 08:21:22 +0200
Subject: [Development] 5.10 branching status?
Message-ID: <2f773dd9-ee55-d0ff-0047-d651e11c9f5c@iseg-hv.de>

Hi all,

We had 5.10 feature freeze two weeks ago but I still see no 5.10 branch 
in Gerrit. That means everything submitted to master now will land in 
5.10?! That effectively blocks master for new features, and if I want 
fixes for 5.10 I have to push them to master also, not knowing when a 
5.10 branch is created.

So my question is: How is the status about 5.10 branching?

Best regards,
André


From jani.heikkinen at qt.io  Tue Aug 22 09:13:30 2017
From: jani.heikkinen at qt.io (Jani Heikkinen)
Date: Tue, 22 Aug 2017 07:13:30 +0000
Subject: [Development] 5.10 branching status?
In-Reply-To: <2f773dd9-ee55-d0ff-0047-d651e11c9f5c@iseg-hv.de>
References: <2f773dd9-ee55-d0ff-0047-d651e11c9f5c@iseg-hv.de>
Message-ID: <HE1PR02MB31321DB4F98F76E41EDAACED9D840@HE1PR02MB3132.eurprd02.prod.outlook.com>

Hi,

> -----Original Message-----
> From: Development [mailto:development-
> bounces+jani.heikkinen=qt.io at qt-project.org] On Behalf Of André
> Hartmann
> Sent: tiistai 22. elokuuta 2017 9.21
> To: development at qt-project.org
> Subject: [Development] 5.10 branching status?
> 
> Hi all,
> 
> We had 5.10 feature freeze two weeks ago but I still see no 5.10 branch in
> Gerrit. That means everything submitted to master now will land in 5.10?!
> That effectively blocks master for new features, and if I want fixes for 5.10 I
> have to push them to master also, not knowing when a
> 5.10 branch is created.
> 
> So my question is: How is the status about 5.10 branching?
> 

We are still waiting successfully qt5.git integration before we can start branching. There has been progress but few tests are still failing and so on blocking the successfully qt5.git integration. You can follow-up the progress from https://codereview.qt-project.org/#/c/201350/ & see open blockers from https://bugreports.qt.io/issues/?filter=18856
 
The plan is to start branching immediately after qt5.git integration succeed in 'dev' . Final downmerge from 'dev' to '5.10' will be done ~after a week from starting. So yes, unfortunately this means new feature development in blocked in 'dev' at the moment, sorry about that. We are doing our best to proceed as soon as possible

br,
Jani


From andre.hartmann at iseg-hv.de  Tue Aug 22 09:39:30 2017
From: andre.hartmann at iseg-hv.de (=?UTF-8?Q?Andr=c3=a9_Hartmann?=)
Date: Tue, 22 Aug 2017 09:39:30 +0200
Subject: [Development] 5.10 branching status?
In-Reply-To: <HE1PR02MB31321DB4F98F76E41EDAACED9D840@HE1PR02MB3132.eurprd02.prod.outlook.com>
References: <2f773dd9-ee55-d0ff-0047-d651e11c9f5c@iseg-hv.de>
	<HE1PR02MB31321DB4F98F76E41EDAACED9D840@HE1PR02MB3132.eurprd02.prod.outlook.com>
Message-ID: <be3b6a02-9d62-a2e7-8401-bc7bcc126b71@iseg-hv.de>

Hi Jani,

thanks for the update. Good luck getting the integration succeeding :)

Best regards,
André

Am 22.08.2017 um 09:13 schrieb Jani Heikkinen:
> Hi,
> 
>> -----Original Message-----
>> From: Development [mailto:development-
>> bounces+jani.heikkinen=qt.io at qt-project.org] On Behalf Of André
>> Hartmann
>> Sent: tiistai 22. elokuuta 2017 9.21
>> To: development at qt-project.org
>> Subject: [Development] 5.10 branching status?
>>
>> Hi all,
>>
>> We had 5.10 feature freeze two weeks ago but I still see no 5.10 branch in
>> Gerrit. That means everything submitted to master now will land in 5.10?!
>> That effectively blocks master for new features, and if I want fixes for 5.10 I
>> have to push them to master also, not knowing when a
>> 5.10 branch is created.
>>
>> So my question is: How is the status about 5.10 branching?
>>
> 
> We are still waiting successfully qt5.git integration before we can start branching. There has been progress but few tests are still failing and so on blocking the successfully qt5.git integration. You can follow-up the progress from https://codereview.qt-project.org/#/c/201350/ & see open blockers from https://bugreports.qt.io/issues/?filter=18856
>   
> The plan is to start branching immediately after qt5.git integration succeed in 'dev' . Final downmerge from 'dev' to '5.10' will be done ~after a week from starting. So yes, unfortunately this means new feature development in blocked in 'dev' at the moment, sorry about that. We are doing our best to proceed as soon as possible
> 
> br,
> Jani
> 


-- 
Best regards / Mit freundlichen Grüßen
André Hartmann, Dipl.-Ing. (FH)
Software Project Manager

iseg Spezialelektronik GmbH         |  phone: ++49 (0)351 26996-43
Bautzner Landstr. 23                |  fax:   ++49 (0)351 26996-21
D-01454 Radeberg / Rossendorf       |  web:   www.iseg-hv.com

Geschäftsführer / Managing director: Dr. F. Gleisberg, Dr. J. Pöthig
Amtsgericht / Lower district court: Dresden HRB 16250
Ust.-Id.-Nr. / VAT-ID: DE812508942

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 delete this e-mail.
Any unauthorized copying, disclosure or distribution of the material
in this e-mail is strictly forbidden.


From kollix at aon.at  Tue Aug 22 13:34:22 2017
From: kollix at aon.at (Martin Koller)
Date: Tue, 22 Aug 2017 13:34:22 +0200
Subject: [Development] QLowEnergyController and obsolete ctor
Message-ID: <2891099.FvB2LfqEYr@lapi.koller>

In Qt 5.9 I find that the following ctor is marked as obsolete:

    explicit QLowEnergyController(const QBluetoothAddress &remoteDevice,
                                  const QBluetoothAddress &localDevice,
                                  QObject *parent = Q_NULLPTR); // TODO Qt 6 remove ctor

but there is no other way to create a QLowEnergyController which does not use
the local default adapter.

How is this supposed to work ?

(I'm on Linux, openSuse)

-- 
Best regards/Schöne Grüße

Martin
A: Because it breaks the logical sequence of discussion
Q: Why is top posting bad?

()  ascii ribbon campaign - against html e-mail 
/\                        - against proprietary attachments

Geschenkideen, Accessoires, Seifen, Kulinarisches: www.lillehus.at




From lars.knoll at qt.io  Wed Aug 23 08:25:01 2017
From: lars.knoll at qt.io (Lars Knoll)
Date: Wed, 23 Aug 2017 06:25:01 +0000
Subject: [Development] DTLS support in Qt
In-Reply-To: <17754295.D1oIBrrLcz@tjmaciei-mobl1>
References: <300687443.6vTp0T0AZJ@tjmaciei-mobl1>
	<HE1PR0202MB25887BCA2047FEB19BDA69CD91800@HE1PR0202MB2588.eurprd02.prod.outlook.com>
	<17754295.D1oIBrrLcz@tjmaciei-mobl1>
Message-ID: <DD920922-4630-4EC6-914B-0DDF4803A632@qt.io>

Hi,

I’ll look into it. But it’ll take a few days.

Cheers,
Lars

> On 18 Aug 2017, at 22:11, Thiago Macieira <thiago.macieira at intel.com> wrote:
> 
> On Friday, 18 August 2017 13:07:13 PDT Timur Pocheptsov wrote:
>>> Should *I* contribute it?
>> 
>> Well, yes, please, otherwise I'll do it myself 😊
> 
> I think I need an answer from Lars or Tuukka, because of the legal 
> implications.
> 
>>> If NO:
>> 
>> Then who will write it? When?
>> 
>> I will, 5.11.
> 
> Cool! I'll start a new thread discussing the non-crypto related parts until we 
> get the conclusion of what I can or cannot be part of.
> 
>>> Then what module should it be in?
>> 
>> Option 'a' is optimal.
> 
> No doubt.
> 
> -- 
> 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 jani.heikkinen at qt.io  Wed Aug 23 11:20:26 2017
From: jani.heikkinen at qt.io (Jani Heikkinen)
Date: Wed, 23 Aug 2017 09:20:26 +0000
Subject: [Development] Qt 5.6.3 change files etc (was: Meeting minutes from
 Qt Release Team meeting 22.08.2017)
In-Reply-To: <VI1PR02MB10064CD6DEEB0A98E407E6B18C850@VI1PR02MB1006.eurprd02.prod.outlook.com>
References: <HE1PR02MB31327F3B088E78E3213B16B89D850@HE1PR02MB3132.eurprd02.prod.outlook.com>,
	<VI1PR02MB10064CD6DEEB0A98E407E6B18C850@VI1PR02MB1006.eurprd02.prod.outlook.com>
Message-ID: <HE1PR02MB313266963AE58BA5FEBF442E9D850@HE1PR02MB3132.eurprd02.prod.outlook.com>

>
>________________________________________
>From: Simon Hausmann
>Sent: Wednesday, August 23, 2017 10:11 AM
>To: Jani Heikkinen; releasing at qt-project.org
>Subject: Re: Meeting minutes from Qt Release Team meeting 22.08.2017
>
>Hi,
>
>
>Regarding the changelogs for 5.6.3, I have a suggestion:
>
>
>   (1) The changes for 5.6.3 target the 5.9 branch in Gerrit.
>
>    (2) Upon approval, Ossi could perhaps force-push them into the 5.9 branch of the module.
>
>    (3) Right afterwards cherry-pick them to 5.6 and also force push them there.
>

Sounds ok for me. Ossi, is this ok for you (there is again some extra work planned to you ;) )? 
If that is the way we agree to proceed the we could start creating 5.6.3 change files in '5.9' already now

>
>I see no value in running changes to dist/changelog-XXX through the CI.
>
>
>Simon

Me either ;)

Then I have another issue related to branching from '5.6' to '5.6.3':
- I don't think we need to do soft branching here, right? there isn't that much changes ongoing in '5.6' anymore so we could just do the branching immediately after all ready for it. Or does someone disagree


From s.stirtzel at googlemail.com  Wed Aug 23 11:32:11 2017
From: s.stirtzel at googlemail.com (Samuel Stirtzel)
Date: Wed, 23 Aug 2017 11:32:11 +0200
Subject: [Development] Multiclient UDP server
In-Reply-To: <2187944.kxPGXOVccJ@tjmaciei-mobl1>
References: <2187944.kxPGXOVccJ@tjmaciei-mobl1>
Message-ID: <CAGiJk9cOhs11WxSPyMMs9zX=HN=YT3oZ7qkY5g1bBZR4nH7sqA@mail.gmail.com>

2017-08-18 22:37 GMT+02:00 Thiago Macieira <thiago.macieira at intel.com>:
> Related to the DTLS discussion, but I'll try to keep this free from crypto for
> now.
>
> The question is how to write a multi-client server operating on UDP, not TCP.
> It would be nice to understand SCTP case too (and maybe DCCP in the future).

Hi Thiago,
maybe I can provide some feedback.

This response is based on the information provided by the following RFCs:
Stream Control Transmission Protocol: https://tools.ietf.org/html/rfc4960
DTLS Version 1.2: https://tools.ietf.org/html/rfc6347
The Constrained Application Protocol: https://tools.ietf.org/html/rfc7252
UDP Usage Guidelines: https://tools.ietf.org/html/rfc8085


> B) multiple UDP sockets
>
> This is similar to TCP. Whenever a new client is detected, we create a new UDP
> socket and put it in connected mode with that particular client. Once you do
> that, this socket will only receive datagrams from that client, whereas the
> unconnected socket will not.
>
> Pros: scalability, since you can move the QUdpSocket to another thread; the
> connected datagram socket has another advantage that it can relay ICMP errors
> like "port unreachable" to the upper level, whereas the unconnected one won't.
> I also believe the connected mode socket can do Path MTU calculation.
>
> Cons: more resources, but more importantly, there's a race condition: the
> unconnected socket which you received the initial packet from the new client
> on may have queued more datagrams. Those datagrams can be:
>  - from the same client
>  - from other clients
>
> So we are in a catch-22 situation: if you connect() this socket and create a
> new unconnected one, any packets from other clients will not be seen. If you
> create a new socket and connect() it, you may miss any packets from the same
> client. I think that for both CoAP and DTLS, we'd opt for connect()ing the new
> socket, since the client wouldn't be sending new commands until it receives a
> reply from us. That reply resolves the problem of race condition.
>

Yes connect()ing the new socket is the only sane way.
The old socket could recvfrom() the data and forward it until the new
socket takes over.

There still will be a time window where a race condition could result
in duplicated datagrams.
However, according to rfc8085 UDP based protocols should be resilient
to datagram duplication.
Both DTLS and CoAP, just for the sake of an example, can handle
duplicated datagrams gracefully.


For SCTP the sctp_peeloff() call results into net/sctp/socket.c
sctp_sock_migrate() and it should just work.
It also migrates messages in the old socket's receive queue that are
for the peeled off association to the new socket's receive queue.


-- 
Regards
Samuel


From thiago.macieira at intel.com  Wed Aug 23 17:30:11 2017
From: thiago.macieira at intel.com (Thiago Macieira)
Date: Wed, 23 Aug 2017 08:30:11 -0700
Subject: [Development] Multiclient UDP server
In-Reply-To: <CAGiJk9cOhs11WxSPyMMs9zX=HN=YT3oZ7qkY5g1bBZR4nH7sqA@mail.gmail.com>
References: <2187944.kxPGXOVccJ@tjmaciei-mobl1>
	<CAGiJk9cOhs11WxSPyMMs9zX=HN=YT3oZ7qkY5g1bBZR4nH7sqA@mail.gmail.com>
Message-ID: <1659086.W6ozFlVo4i@tjmaciei-mobl1>

On Wednesday, 23 August 2017 02:32:11 PDT Samuel Stirtzel via Development 
wrote:
> Yes connect()ing the new socket is the only sane way.
> The old socket could recvfrom() the data and forward it until the new
> socket takes over.
> 
> There still will be a time window where a race condition could result
> in duplicated datagrams.
> However, according to rfc8085 UDP based protocols should be resilient
> to datagram duplication.
> Both DTLS and CoAP, just for the sake of an example, can handle
> duplicated datagrams gracefully.

Indeed, I was considering that connect() is the only sane way. It will allow 
us to use getsockopt(IP_MTU) to get the path MTU, in addition to getting the 
ICMP errors.

The only problem is that "forward until the new socket takes over": that means 
the original socket needs to keep a link to the other socket. Otherwise, once 
it sees that retransmission that was already queued, it would conclude it's a 
new request and would create a new DTLS session object to handle it.

There are two ways to do that:

1) the obvious: just keep a list of all sessions (address 4-tuple) and a 
pointer to the session object that will handle the QNetworkDatagram that may 
be duplicated.

2) the buffer-draining solution: instead of starting the handling immediately 
for each datagram solution, it can ensure that it drained the queue after the 
connect() calls. That way, we know there are no more duplicates. 

I like #2, but I need to implement it to see if there are any timing problems.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center



From oswald.buddenhagen at qt.io  Thu Aug 24 10:24:58 2017
From: oswald.buddenhagen at qt.io (Oswald Buddenhagen)
Date: Thu, 24 Aug 2017 10:24:58 +0200
Subject: [Development] Qt 5.6.3 change files etc (was: Meeting minutes
 from Qt Release Team meeting 22.08.2017)
In-Reply-To: <HE1PR02MB313266963AE58BA5FEBF442E9D850@HE1PR02MB3132.eurprd02.prod.outlook.com>
References: <HE1PR02MB31327F3B088E78E3213B16B89D850@HE1PR02MB3132.eurprd02.prod.outlook.com>
	<VI1PR02MB10064CD6DEEB0A98E407E6B18C850@VI1PR02MB1006.eurprd02.prod.outlook.com>
	<HE1PR02MB313266963AE58BA5FEBF442E9D850@HE1PR02MB3132.eurprd02.prod.outlook.com>
Message-ID: <20170824082458.GA8257@ugly>

On Wed, Aug 23, 2017 at 11:20:26AM +0200, Jani Heikkinen wrote:
> >   (1) The changes for 5.6.3 target the 5.9 branch in Gerrit.
> >
> >    (2) Upon approval, Ossi could perhaps force-push them into the 5.9 branch of the module.
> >
> >    (3) Right afterwards cherry-pick them to 5.6 and also force push them there.
> >
> 
> Sounds ok for me. Ossi, is this ok for you (there is again some extra work planned to you ;) )? 
>
sure. a direct push (i very much hope it's not a forced push ;) isn't
exactly a lot of effort.


From thiago.macieira at intel.com  Thu Aug 24 23:00:01 2017
From: thiago.macieira at intel.com (Thiago Macieira)
Date: Thu, 24 Aug 2017 14:00:01 -0700
Subject: [Development] Qt and IoT infographic
Message-ID: <1692398.lzVxuX8aJu@tjmaciei-mobl1>

Re the inforgraphic at
  https://info.qt.io/whitepaper-building-the-internet-of-things
  (not the paper because it's asking information I won't give before I get it)

First of all, I like that Qt Company is taking this seriously. You can improve 
those graphics with target numbers for 2020, which are talking about 200 
billion devices connected (I think the analysis is from Gartner).

My criticism is what I *don't* see in this: local communication. Cloud 
communication *should* be secondary in IoT. In fact, few devices should 
communicate with the Cloud, hopefully only those that have hardened security 
and where the user can control the privacy settings on. In a given smart home, 
you should be able to count how many of those exist in the fingers of one hand.

So where's the information about local network discovery and communication? 
Where's the strategy on common protocols and data models? Publish and 
subscribe of notifications?

Please see this article from Monday that is relevant to this topic:
http://www.zdnet.com/article/sonos-accept-new-privacy-policy-speakers-cease-to-function/

See also my comment: https://plus.google.com/+ThiagoMacieira/posts/goErhFrhzoS

The infographic makes a spectacular error in this area. It says "Your data, 
your code, your cloud". Well, no: that's your code and it may be your cloud, 
but it's most definitely not your data. It's someone else's data.

And now you know why I'm working on QtNetwork and want to implement DTLS.

PS: it also says "Artificial Intelligence" in "The Backbone" part. How is that 
relevant to Qt or where is it exposed in Qt?

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center



From thiago.macieira at intel.com  Thu Aug 24 23:05:46 2017
From: thiago.macieira at intel.com (Thiago Macieira)
Date: Thu, 24 Aug 2017 14:05:46 -0700
Subject: [Development] Qt and IoT infographic
In-Reply-To: <1692398.lzVxuX8aJu@tjmaciei-mobl1>
References: <1692398.lzVxuX8aJu@tjmaciei-mobl1>
Message-ID: <2774496.JIjy4EJjQs@tjmaciei-mobl1>

On Thursday, 24 August 2017 14:00:01 PDT Thiago Macieira wrote:
> PS: it also says "Artificial Intelligence" in "The Backbone" part. How is
> that relevant to Qt or where is it exposed in Qt?

It also says "12+ supported platforms". Where does that number come from? I 
can count 7:

- Linux
- Windows
- macOS
- Android
- iOS / tvOS / watchOS
- QNX
- INTEGRITY

Even if you split the Apple embedded platforms, that's still 9. WinRT 
shouldn't be split from Windows, since it's still Windows; Embedded Linux is 
still Linux and so are all the different Linux distributions.

Don't add FreeBSD there just because I like developing with it more than on 
macOS.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center



From picaschaf at me.com  Thu Aug 24 23:22:22 2017
From: picaschaf at me.com (Alexander Nassian)
Date: Thu, 24 Aug 2017 23:22:22 +0200
Subject: [Development] Qt and IoT infographic
In-Reply-To: <2774496.JIjy4EJjQs@tjmaciei-mobl1>
References: <1692398.lzVxuX8aJu@tjmaciei-mobl1>
	<2774496.JIjy4EJjQs@tjmaciei-mobl1>
Message-ID: <335CD31D-57F8-4365-B033-E049E4799D31@me.com>

Maybe they count "platforms" not as OSs but as platform plugins in Qt xD

Beste Grüße / Best regards,
Alexander Nassian

> Am 24.08.2017 um 23:05 schrieb Thiago Macieira <thiago.macieira at intel.com>:
> 
>> On Thursday, 24 August 2017 14:00:01 PDT Thiago Macieira wrote:
>> PS: it also says "Artificial Intelligence" in "The Backbone" part. How is
>> that relevant to Qt or where is it exposed in Qt?
> 
> It also says "12+ supported platforms". Where does that number come from? I 
> can count 7:
> 
> - Linux
> - Windows
> - macOS
> - Android
> - iOS / tvOS / watchOS
> - QNX
> - INTEGRITY
> 
> Even if you split the Apple embedded platforms, that's still 9. WinRT 
> shouldn't be split from Windows, since it's still Windows; Embedded Linux is 
> still Linux and so are all the different Linux distributions.
> 
> Don't add FreeBSD there just because I like developing with it more than on 
> macOS.
> 
> -- 
> 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 aclight at gmail.com  Fri Aug 25 01:08:29 2017
From: aclight at gmail.com (Adam Light)
Date: Thu, 24 Aug 2017 16:08:29 -0700
Subject: [Development] Qt and IoT infographic
In-Reply-To: <1692398.lzVxuX8aJu@tjmaciei-mobl1>
References: <1692398.lzVxuX8aJu@tjmaciei-mobl1>
Message-ID: <CACTDJ6gT9d_xyz-evSk8UVEOvgJBZQs6gQPeBe3pz5Lpw4Eb1A@mail.gmail.com>

On Thu, Aug 24, 2017 at 2:00 PM, Thiago Macieira <thiago.macieira at intel.com>
wrote:

> Re the inforgraphic at
>   https://info.qt.io/whitepaper-building-the-internet-of-things
>   (not the paper because it's asking information I won't give before I get
> it)
>
>
"adaptable" is also misspelled as "adapteble" in #5, unless that's a
spelling that neither I nor Google is familiar with.

Adam
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20170824/df8e91d6/attachment.html>

From ritt.ks at gmail.com  Fri Aug 25 01:34:47 2017
From: ritt.ks at gmail.com (Konstantin Ritt)
Date: Fri, 25 Aug 2017 03:34:47 +0400
Subject: [Development] DTLS support in Qt
In-Reply-To: <DD920922-4630-4EC6-914B-0DDF4803A632@qt.io>
References: <300687443.6vTp0T0AZJ@tjmaciei-mobl1>
	<HE1PR0202MB25887BCA2047FEB19BDA69CD91800@HE1PR0202MB2588.eurprd02.prod.outlook.com>
	<17754295.D1oIBrrLcz@tjmaciei-mobl1>
	<DD920922-4630-4EC6-914B-0DDF4803A632@qt.io>
Message-ID: <CAGVE+R=Q17oUULCm+fgz0FyNoCgrpZVT7DD2za-jOmYR=z1w8A@mail.gmail.com>

> Then what module should it be in?

My +1 for QtNetwork (unless we're going to move QSsl related code to a
separate Qt module)

Regards,
Konstantin

2017-08-23 10:25 GMT+04:00 Lars Knoll <lars.knoll at qt.io>:

> Hi,
>
> I’ll look into it. But it’ll take a few days.
>
> Cheers,
> Lars
>
> > On 18 Aug 2017, at 22:11, Thiago Macieira <thiago.macieira at intel.com>
> wrote:
> >
> > On Friday, 18 August 2017 13:07:13 PDT Timur Pocheptsov wrote:
> >>> Should *I* contribute it?
> >>
> >> Well, yes, please, otherwise I'll do it myself 😊
> >
> > I think I need an answer from Lars or Tuukka, because of the legal
> > implications.
> >
> >>> If NO:
> >>
> >> Then who will write it? When?
> >>
> >> I will, 5.11.
> >
> > Cool! I'll start a new thread discussing the non-crypto related parts
> until we
> > get the conclusion of what I can or cannot be part of.
> >
> >>> Then what module should it be in?
> >>
> >> Option 'a' is optimal.
> >
> > No doubt.
> >
> > --
> > 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20170825/976b72ab/attachment.html>

From Jake.Petroules at qt.io  Fri Aug 25 05:06:56 2017
From: Jake.Petroules at qt.io (Jake Petroules)
Date: Fri, 25 Aug 2017 03:06:56 +0000
Subject: [Development] Qt and IoT infographic
In-Reply-To: <2774496.JIjy4EJjQs@tjmaciei-mobl1>
References: <1692398.lzVxuX8aJu@tjmaciei-mobl1>
	<2774496.JIjy4EJjQs@tjmaciei-mobl1>
Message-ID: <461A69DB-A5A2-41A6-A59E-A033B005FB90@qt.io>

I'll find out who wrote that and why.

In our license management systems, there happen to be exactly 12 "platforms" codified, so it's possible someone in marketing looked at a copy of that list in Salesforce or something. That list is:

- X11
- Embedded Linux
- Windows (desktop Windows)
- macOS
- Embedded Windows (i.e. Windows CE, and therefore obsolete)
- Android
- QNX
- VxWorks (which isn't actually an officially supported platform yet aside from that fork of 5.5)
- INTEGRITY
- iOS (tvOS and watchOS aren't yet officially supported either but use the same license platform as iOS)
- UWP (WinRT / Windows Runtime)
- Embedded Android (obsolete?)

Symbian and S40 used to be there too.

> On Aug 24, 2017, at 2:05 PM, Thiago Macieira <thiago.macieira at intel.com> wrote:
> 
> On Thursday, 24 August 2017 14:00:01 PDT Thiago Macieira wrote:
>> PS: it also says "Artificial Intelligence" in "The Backbone" part. How is
>> that relevant to Qt or where is it exposed in Qt?
> 
> It also says "12+ supported platforms". Where does that number come from? I 
> can count 7:
> 
> - Linux
> - Windows
> - macOS
> - Android
> - iOS / tvOS / watchOS
> - QNX
> - INTEGRITY
> 
> Even if you split the Apple embedded platforms, that's still 9. WinRT 
> shouldn't be split from Windows, since it's still Windows; Embedded Linux is 
> still Linux and so are all the different Linux distributions.
> 
> Don't add FreeBSD there just because I like developing with it more than on 
> macOS.
> 
> -- 
> 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

-- 
Jake Petroules - jake.petroules at qt.io
The Qt Company - Silicon Valley
Qbs build tool evangelist - qbs.io



From lorn.potter at gmail.com  Fri Aug 25 05:49:57 2017
From: lorn.potter at gmail.com (Lorn Potter)
Date: Fri, 25 Aug 2017 13:49:57 +1000
Subject: [Development] Qt and IoT infographic
In-Reply-To: <1692398.lzVxuX8aJu@tjmaciei-mobl1>
References: <1692398.lzVxuX8aJu@tjmaciei-mobl1>
Message-ID: <399F7BDF-D36C-4C57-9D60-D114119B16B1@gmail.com>


> On 25 Aug 2017, at 7:00 am, Thiago Macieira <thiago.macieira at intel.com> wrote:
> 
> My criticism is what I *don't* see in this: local communication. Cloud 
> communication *should* be secondary in IoT. In fact, few devices should 
> communicate with the Cloud, hopefully only those that have hardened security 
> and where the user can control the privacy settings on. In a given smart home, 
> you should be able to count how many of those exist in the fingers of one hand.
> 
> So where's the information about local network discovery and communication? 
> Where's the strategy on common protocols and data models? Publish and 
> subscribe of notifications?

I would agree. QtMqtt is interesting along these lines.
IoT is really about communication and interactions. 
See this:
https://medium.com/web11/iot-isnt-about-smart-things-it-s-about-smart-interactions-a80546fcd9b7

From thiago.macieira at intel.com  Fri Aug 25 06:08:56 2017
From: thiago.macieira at intel.com (Thiago Macieira)
Date: Thu, 24 Aug 2017 21:08:56 -0700
Subject: [Development] Qt and IoT infographic
In-Reply-To: <461A69DB-A5A2-41A6-A59E-A033B005FB90@qt.io>
References: <1692398.lzVxuX8aJu@tjmaciei-mobl1>
	<2774496.JIjy4EJjQs@tjmaciei-mobl1>
	<461A69DB-A5A2-41A6-A59E-A033B005FB90@qt.io>
Message-ID: <1706326.1RbfePFRdG@tjmaciei-mobl1>

On Thursday, 24 August 2017 20:06:56 PDT Jake Petroules wrote:
> In our license management systems, there happen to be exactly 12 "platforms"
> codified, so it's possible someone in marketing looked at a copy of that
> list in Salesforce or something. That list is:
> 
> - X11
> - Embedded Linux
> - Windows (desktop Windows)
> - macOS
> - Embedded Windows (i.e. Windows CE, and therefore obsolete)
> - Android
> - QNX
> - VxWorks (which isn't actually an officially supported platform yet aside
> from that fork of 5.5) 
> - INTEGRITY

Looks like the licence key mechanism we used to use for Qt 3 and 4, where X11 
and QWS were distinct implementations and we delivered different sources to 
customers. The order matches that order too (except for Android, that should 
be Symbian in that position).

A little bit of trivia:

In the beginning of time, we used to split the source repository (CVS, then 
Perforce) into multiple source packages, according to the file names. That's 
why there's "qt-x11-2.3.0" and "qt-embedded-2.3.0". In Qt 3 times, the Mac 
version was also made opensource, so "qt-mac-free-3.1.2". Then, for 4.0, 
Windows was made open source.

[🎵 "First there was Linux / and then there was Mac / now with Windows / on the 
Open Source track" 🎵 anyone?]

It was shortly before my time as release manager that we created the all-
desktop source package called "qt-all-opensource-src-4.3.0", which was the 
Perforce repository minus the *_qws* files and a few things that weren't part 
of any release (like the licence key decoder). Later, after the Git repository 
was opened up, we got permission to release all implementations in one source 
package. Since we had already used "all", we needed a different tag for that. 
We called it "qt-everywhere-opensource-src-4.6.0".

And that's what it is still called:
http://download.qt.io/official_releases/qt/5.9/5.9.1/single/qt-everywhere-opensource-src-5.9.1.tar.xz

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center



From Jake.Petroules at qt.io  Fri Aug 25 06:23:42 2017
From: Jake.Petroules at qt.io (Jake Petroules)
Date: Fri, 25 Aug 2017 04:23:42 +0000
Subject: [Development] Qt and IoT infographic
In-Reply-To: <1706326.1RbfePFRdG@tjmaciei-mobl1>
References: <1692398.lzVxuX8aJu@tjmaciei-mobl1>
	<2774496.JIjy4EJjQs@tjmaciei-mobl1>
	<461A69DB-A5A2-41A6-A59E-A033B005FB90@qt.io>
	<1706326.1RbfePFRdG@tjmaciei-mobl1>
Message-ID: <0BB0410B-23EE-4489-B6DB-91DF7004096B@qt.io>


> On Aug 24, 2017, at 9:08 PM, Thiago Macieira <thiago.macieira at intel.com> wrote:
> 
> On Thursday, 24 August 2017 20:06:56 PDT Jake Petroules wrote:
>> In our license management systems, there happen to be exactly 12 "platforms"
>> codified, so it's possible someone in marketing looked at a copy of that
>> list in Salesforce or something. That list is:
>> 
>> - X11
>> - Embedded Linux
>> - Windows (desktop Windows)
>> - macOS
>> - Embedded Windows (i.e. Windows CE, and therefore obsolete)
>> - Android
>> - QNX
>> - VxWorks (which isn't actually an officially supported platform yet aside
>> from that fork of 5.5) 
>> - INTEGRITY
> 
> Looks like the licence key mechanism we used to use for Qt 3 and 4,

and Qt 5

> where X11 
> and QWS were distinct implementations and we delivered different sources to 
> customers. The order matches that order too (except for Android, that should 
> be Symbian in that position).

Yep:

...
- Embedded Windows
- Symbian
- Android
- S40
- QNX
...

I imagine QWS was in the place where Embedded Linux is now as there's no other gaps in the bit set and the last platforms in the list are too new to have preceded it.

> A little bit of trivia:
> 
> In the beginning of time, we used to split the source repository (CVS, then 
> Perforce) into multiple source packages, according to the file names. That's 
> why there's "qt-x11-2.3.0" and "qt-embedded-2.3.0". In Qt 3 times, the Mac 
> version was also made opensource, so "qt-mac-free-3.1.2". Then, for 4.0, 
> Windows was made open source.
> 
> [🎵 "First there was Linux / and then there was Mac / now with Windows / on the 
> Open Source track" 🎵 anyone?]
> 
> It was shortly before my time as release manager that we created the all-
> desktop source package called "qt-all-opensource-src-4.3.0", which was the 
> Perforce repository minus the *_qws* files and a few things that weren't part 
> of any release (like the licence key decoder).

Funny enough, the key decoder is the only place where the full list of all 14 platforms still exists. All mention of Symbian got purged from the Qt sources pretty thoroughly.

Somehow, much older systems like IRIX, SCO, and others have survived longer. ;)

> Later, after the Git repository 
> was opened up, we got permission to release all implementations in one source 
> package. Since we had already used "all", we needed a different tag for that. 
> We called it "qt-everywhere-opensource-src-4.6.0".
> 
> And that's what it is still called:
> http://download.qt.io/official_releases/qt/5.9/5.9.1/single/qt-everywhere-opensource-src-5.9.1.tar.xz
> 
> -- 
> 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

-- 
Jake Petroules - jake.petroules at qt.io
The Qt Company - Silicon Valley
Qbs build tool evangelist - qbs.io


From thiago.macieira at intel.com  Fri Aug 25 06:58:02 2017
From: thiago.macieira at intel.com (Thiago Macieira)
Date: Thu, 24 Aug 2017 21:58:02 -0700
Subject: [Development] Qt and IoT infographic
In-Reply-To: <0BB0410B-23EE-4489-B6DB-91DF7004096B@qt.io>
References: <1692398.lzVxuX8aJu@tjmaciei-mobl1>
	<1706326.1RbfePFRdG@tjmaciei-mobl1>
	<0BB0410B-23EE-4489-B6DB-91DF7004096B@qt.io>
Message-ID: <1826047.oNM5aVyHNm@tjmaciei-mobl1>

On Thursday, 24 August 2017 21:23:42 PDT Jake Petroules wrote:
> Yep:
> 
> ...
> - Embedded Windows
> - Symbian
> - Android
> - S40
> - QNX
> ...
> 
> I imagine QWS was in the place where Embedded Linux is now as there's no
> other gaps in the bit set and the last platforms in the list are too new to
> have preceded it.

We originally called it "Qt/Embedded", then it got renamed to "QtopiaCore". 
When customers got confused, we renamed it back to "Qt for Embedded Linux" 
(avoiding the slash which is bad for the trademark).

Embedded Windows was clearly "Qt for Windows CE".

The position of Android in that list is explained by the fact that I was the 
one who added it. I was trying to be future-proof when I added Symbian, so I 
included Android and S40 too, expecting to port there one day. S40 was never 
used.

Then I added the three RTOS platforms (QNX, INTEGRITY and VxWorks).

Everything after that is after my time.
 
> Funny enough, the key decoder is the only place where the full list of all
> 14 platforms still exists. All mention of Symbian got purged from the Qt
> sources pretty thoroughly.

Oh, not so much. I cleaned up one Symbian reference not a month ago:

http://code.qt.io/cgit/qt/qtbase.git/commit/?
id=12339481ea016845ffb79e83d9b3dfb6849c7652

And S40 was never in the repository. I think the best we had was a proof-of-
concept port by Harald, Robert and the Munich team that basically proved that 
you couldn't do it. They introduced QT_NO_FILESYSTEM, but that was never 
merged.

It might have been possible if the rumoured Nokia project to port S40 to 
FreeBSD actually came through...
 
> Somehow, much older systems like IRIX, SCO, and others have survived longer.
> ;)

Another one I cleaned up a month ago in the same series: 
6c3a3d498a8797c481a394418fff8f7bf1886c61

-#elif defined(Q_OS_SOLARIS) || defined(Q_OS_IRIX) || defined(Q_OS_AIX) || 
defined(Q_OS_HPUX) \
-      || defined(Q_OS_OSF) || defined(Q_OS_QNX) || defined(Q_OS_SCO) \
-      || defined(Q_OS_UNIXWARE) || defined(Q_OS_RELIANT) || defined(Q_OS_NETBSD)

Really? OSF, SCO and Unixware are before my time. I know OSF (Tru64 Unix) did 
work in the past, but the other two I had no idea they ever were tested. I 
don't even know what Reliant is.

Now, NetBSD is probably my fault. When I joined in 2006, Brad used to run 
FreeBSD for his desktop, so I ran a NetBSD VM to test an extra platform.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center



From lorn.potter at gmail.com  Fri Aug 25 08:10:45 2017
From: lorn.potter at gmail.com (Lorn Potter)
Date: Fri, 25 Aug 2017 16:10:45 +1000
Subject: [Development] Qt and IoT infographic
In-Reply-To: <1706326.1RbfePFRdG@tjmaciei-mobl1>
References: <1692398.lzVxuX8aJu@tjmaciei-mobl1>
	<2774496.JIjy4EJjQs@tjmaciei-mobl1>
	<461A69DB-A5A2-41A6-A59E-A033B005FB90@qt.io>
	<1706326.1RbfePFRdG@tjmaciei-mobl1>
Message-ID: <7ffba512-7c83-6489-7897-d51b91c39504@gmail.com>



On 08/25/2017 02:08 PM, Thiago Macieira wrote:
> [🎵 "First there was Linux / and then there was Mac / now with Windows / on the 
> Open Source track" 🎵 anyone?]


ahh yes. The all time dance mega hit: Qt 4 Dance!

https://www.youtube.com/watch?v=NbTEVbQLC8s


From thiago.macieira at intel.com  Fri Aug 25 08:20:28 2017
From: thiago.macieira at intel.com (Thiago Macieira)
Date: Thu, 24 Aug 2017 23:20:28 -0700
Subject: [Development] Qt and IoT infographic
In-Reply-To: <7ffba512-7c83-6489-7897-d51b91c39504@gmail.com>
References: <1692398.lzVxuX8aJu@tjmaciei-mobl1>
	<1706326.1RbfePFRdG@tjmaciei-mobl1>
	<7ffba512-7c83-6489-7897-d51b91c39504@gmail.com>
Message-ID: <5720727.Tkq3qK1WQM@tjmaciei-mobl1>

On Thursday, 24 August 2017 23:10:45 PDT Lorn Potter wrote:
> On 08/25/2017 02:08 PM, Thiago Macieira wrote:
> > [🎵 "First there was Linux / and then there was Mac / now with Windows /
> > on the Open Source track" 🎵 anyone?]
> 
> ahh yes. The all time dance mega hit: Qt 4 Dance!
> 
> https://www.youtube.com/watch?v=NbTEVbQLC8s

Someone asked me today if there'll be a discussion about the Qt 6 dance at the 
Contributor Summit.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center



From andy.shaw at qt.io  Fri Aug 25 08:42:30 2017
From: andy.shaw at qt.io (Andy Shaw)
Date: Fri, 25 Aug 2017 06:42:30 +0000
Subject: [Development] Qt and IoT infographic
In-Reply-To: <5720727.Tkq3qK1WQM@tjmaciei-mobl1>
References: <1692398.lzVxuX8aJu@tjmaciei-mobl1>
	<1706326.1RbfePFRdG@tjmaciei-mobl1>
	<7ffba512-7c83-6489-7897-d51b91c39504@gmail.com>
	<5720727.Tkq3qK1WQM@tjmaciei-mobl1>
Message-ID: <F96F029B-384A-4694-A7BB-EFA7848BD901@qt.io>

If we have a Qt 6 dance will it be backported to Qt 5? ;)

Andy

Development på vegne av Thiago Macieira <development-bounces+andy.shaw=qt.io at qt-project.org på vegne av thiago.macieira at intel.com> skrev følgende den 25.08.2017, 08.20:

    On Thursday, 24 August 2017 23:10:45 PDT Lorn Potter wrote:
    > On 08/25/2017 02:08 PM, Thiago Macieira wrote:
    > > [🎵 "First there was Linux / and then there was Mac / now with Windows /
    > > on the Open Source track" 🎵 anyone?]
    > 
    > ahh yes. The all time dance mega hit: Qt 4 Dance!
    > 
    > https://www.youtube.com/watch?v=NbTEVbQLC8s
    
    Someone asked me today if there'll be a discussion about the Qt 6 dance at the 
    Contributor Summit.
    
    -- 
    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 jeanmichael.celerier at gmail.com  Fri Aug 25 09:17:02 2017
From: jeanmichael.celerier at gmail.com (=?UTF-8?Q?Jean=2DMicha=C3=ABl_Celerier?=)
Date: Fri, 25 Aug 2017 09:17:02 +0200
Subject: [Development] Qt and IoT infographic
In-Reply-To: <1692398.lzVxuX8aJu@tjmaciei-mobl1>
References: <1692398.lzVxuX8aJu@tjmaciei-mobl1>
Message-ID: <CAE1uMrV9WA4PMdwfQr2y-kW5vRpyZpyWjpiMpCB975DkdC_sSA@mail.gmail.com>

> So where's the information about local network discovery and
communication?
Where's the strategy on common protocols and data models? Publish and
subscribe of notifications?

(adding a vote for support of Zeroconf in Qt :
https://bugreports.qt.io/browse/QTBUG-30823)

I think that the Pub - Sub support is covered in part by the recent MQTT
addition :
https://blog.qt.io/blog/2017/08/14/introducing-qtmqtt-protocol/

though one would hope that each IoT *protocole du jour* won't have its own
separate implementation
and instead there can be some generic that implements pub-sub, a bit like
QIODevice.

Best,

-------
Jean-Michaël Celerier
http://www.jcelerier.name

On Thu, Aug 24, 2017 at 11:00 PM, Thiago Macieira <thiago.macieira at intel.com
> wrote:

> Re the inforgraphic at
>   https://info.qt.io/whitepaper-building-the-internet-of-things
>   (not the paper because it's asking information I won't give before I get
> it)
>
> First of all, I like that Qt Company is taking this seriously. You can
> improve
> those graphics with target numbers for 2020, which are talking about 200
> billion devices connected (I think the analysis is from Gartner).
>
> My criticism is what I *don't* see in this: local communication. Cloud
> communication *should* be secondary in IoT. In fact, few devices should
> communicate with the Cloud, hopefully only those that have hardened
> security
> and where the user can control the privacy settings on. In a given smart
> home,
> you should be able to count how many of those exist in the fingers of one
> hand.
>
> So where's the information about local network discovery and communication?
> Where's the strategy on common protocols and data models? Publish and
> subscribe of notifications?
>
> Please see this article from Monday that is relevant to this topic:
> http://www.zdnet.com/article/sonos-accept-new-privacy-
> policy-speakers-cease-to-function/
>
> See also my comment: https://plus.google.com/+ThiagoMacieira/posts/
> goErhFrhzoS
>
> The infographic makes a spectacular error in this area. It says "Your data,
> your code, your cloud". Well, no: that's your code and it may be your
> cloud,
> but it's most definitely not your data. It's someone else's data.
>
> And now you know why I'm working on QtNetwork and want to implement DTLS.
>
> PS: it also says "Artificial Intelligence" in "The Backbone" part. How is
> that
> relevant to Qt or where is it exposed in Qt?
>
> --
> 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: <http://lists.qt-project.org/pipermail/development/attachments/20170825/463ae5e4/attachment.html>

From tony.sarajarvi at qt.io  Fri Aug 25 12:44:30 2017
From: tony.sarajarvi at qt.io (=?iso-8859-1?Q?Tony_Saraj=E4rvi?=)
Date: Fri, 25 Aug 2017 10:44:30 +0000
Subject: [Development] Maintenance break tonight and tomorrow
Message-ID: <VI1PR02MB11198D8BE12A2A2B46340317929B0@VI1PR02MB1119.eurprd02.prod.outlook.com>

Hi

IT will transfer over some infra related services from the old facilities to the new one this weekend. Jenkins, Coin, IRC, mail services are affected in such that we will shut them down for ~15 minutes while the move is being made. We scheduled these to happen late in the evening, around 22:00 EET, so that the moves will minimize the effect you your development.

Thanks for your patience,
-Tony
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20170825/8e42c02f/attachment.html>

From thiago.macieira at intel.com  Fri Aug 25 17:29:31 2017
From: thiago.macieira at intel.com (Thiago Macieira)
Date: Fri, 25 Aug 2017 08:29:31 -0700
Subject: [Development] Qt and IoT infographic
In-Reply-To: <CAE1uMrV9WA4PMdwfQr2y-kW5vRpyZpyWjpiMpCB975DkdC_sSA@mail.gmail.com>
References: <1692398.lzVxuX8aJu@tjmaciei-mobl1>
	<CAE1uMrV9WA4PMdwfQr2y-kW5vRpyZpyWjpiMpCB975DkdC_sSA@mail.gmail.com>
Message-ID: <4761922.OYeZm2ct1g@tjmaciei-mobl1>

On Friday, 25 August 2017 00:17:02 PDT Jean-Michaël Celerier wrote:
> > So where's the information about local network discovery and
> 
> communication?
> Where's the strategy on common protocols and data models? Publish and
> subscribe of notifications?
> 
> (adding a vote for support of Zeroconf in Qt :
> https://bugreports.qt.io/browse/QTBUG-30823)
> 
> I think that the Pub - Sub support is covered in part by the recent MQTT
> addition :
> https://blog.qt.io/blog/2017/08/14/introducing-qtmqtt-protocol/

Haven't seen that in the repository, so it doesn't count.

> though one would hope that each IoT *protocole du jour* won't have its own
> separate implementation
> and instead there can be some generic that implements pub-sub, a bit like
> QIODevice.

Maybe, but it's actually unlikely. Each protocol woill probably be different 
enought hat we may need different API.

If only we could get the industry to agree to a single or at most a handful of 
protocols (from experience in the sector, that's not MQTT).

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center



From tony.sarajarvi at qt.io  Sat Aug 26 07:39:54 2017
From: tony.sarajarvi at qt.io (=?iso-8859-1?Q?Tony_Saraj=E4rvi?=)
Date: Sat, 26 Aug 2017 05:39:54 +0000
Subject: [Development] Maintenance break tonight and tomorrow
In-Reply-To: <VI1PR02MB11198D8BE12A2A2B46340317929B0@VI1PR02MB1119.eurprd02.prod.outlook.com>
References: <VI1PR02MB11198D8BE12A2A2B46340317929B0@VI1PR02MB1119.eurprd02.prod.outlook.com>
Message-ID: <VI1PR02MB111922C55F18314352C5E6DA92980@VI1PR02MB1119.eurprd02.prod.outlook.com>

Good morning.

We seem to suffer a loss of the network test server. That's why autotests haven't passed last night. We're on it, and hopefully will get it online again.

-Tony


From: Tony Sarajärvi
Sent: perjantai 25. elokuuta 2017 13.44
To: 'development at qt-project.org' <development at qt-project.org>
Subject: Maintenance break tonight and tomorrow

Hi

IT will transfer over some infra related services from the old facilities to the new one this weekend. Jenkins, Coin, IRC, mail services are affected in such that we will shut them down for ~15 minutes while the move is being made. We scheduled these to happen late in the evening, around 22:00 EET, so that the moves will minimize the effect you your development.

Thanks for your patience,
-Tony
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20170826/6a82027b/attachment.html>

From jani.heikkinen at qt.io  Sun Aug 27 11:02:05 2017
From: jani.heikkinen at qt.io (Jani Heikkinen)
Date: Sun, 27 Aug 2017 09:02:05 +0000
Subject: [Development] HEADS-UP: Branching from 'dev' to '5.10' started
Message-ID: <HE1PR02MB3132F6F3842254AC589E71479D990@HE1PR02MB3132.eurprd02.prod.outlook.com>

HI all,


We have finally soft branched '5.10' from 'dev'. Target is to have final downmerge from 'dev' to '5.10'  Friday 1st September



Please finalize ongoing changes in 'dev' and start using '5.10' for new changes targeted to Qt 5.10.0 release.



br,

Jani Heikkinen

Release Manager

The Qt Company



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20170827/f23a932f/attachment.html>

From tony.sarajarvi at qt.io  Mon Aug 28 10:44:52 2017
From: tony.sarajarvi at qt.io (=?iso-8859-1?Q?Tony_Saraj=E4rvi?=)
Date: Mon, 28 Aug 2017 08:44:52 +0000
Subject: [Development] Infra problems under investigation
Message-ID: <VI1PR02MB1119CB3026FA4E995151F6A0929E0@VI1PR02MB1119.eurprd02.prod.outlook.com>

Hi

We're experiencing internal network problems which are under investigation. An unknown amount of services could be affected.

-Tony
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20170828/76a3e97a/attachment.html>

From tony.sarajarvi at qt.io  Mon Aug 28 11:05:15 2017
From: tony.sarajarvi at qt.io (=?utf-8?B?VG9ueSBTYXJhasOkcnZp?=)
Date: Mon, 28 Aug 2017 09:05:15 +0000
Subject: [Development] Maintenance break tonight and tomorrow
In-Reply-To: <VI1PR02MB111922C55F18314352C5E6DA92980@VI1PR02MB1119.eurprd02.prod.outlook.com>
References: <VI1PR02MB11198D8BE12A2A2B46340317929B0@VI1PR02MB1119.eurprd02.prod.outlook.com>
	<VI1PR02MB111922C55F18314352C5E6DA92980@VI1PR02MB1119.eurprd02.prod.outlook.com>
Message-ID: <VI1PR02MB1119D9EC510A91B092495BD0929E0@VI1PR02MB1119.eurprd02.prod.outlook.com>

Hi

A brief update on last weekend. So on Friday evening we tried moving a few of our infra servers to the new site. After shutting down services and restarting them on the new site, a few VMs didn’t like that. There were badly configured gateways which competed during launch and things went south from there.

Also the network test server had its own problem. We have the NIC configured as eth0. However, once you restart the VM it brings up eth1. But it took a while to figure that one out. So, before that, we reverted to the old site on Saturday morning and launched the old server up. But, as said, the same problem occurred here. This time IT _had_ to figure out how to solve the problem and they changed the configs to work with the new eth1.

However, who knew we had configuring scripts for the network test server that specifically used eth0. Those we saw mid day Saturday. After fixing those, we got autotest passing again.

On Saturday evening we continued moving the rest of the VMs, at which point we knew what to do and things went much smoother this time. We could expect these kinds of problems. Despite that, one of the servers from Friday didn’t connect correctly until fixed on Sunday.

Shorter version: all works now (except for today’s new problems that are unrelated) 😊

-T

From: Tony Sarajärvi
Sent: lauantai 26. elokuuta 2017 8.40
To: 'development at qt-project.org' <development at qt-project.org>
Subject: RE: Maintenance break tonight and tomorrow

Good morning.

We seem to suffer a loss of the network test server. That’s why autotests haven’t passed last night. We’re on it, and hopefully will get it online again.

-Tony


From: Tony Sarajärvi
Sent: perjantai 25. elokuuta 2017 13.44
To: 'development at qt-project.org' <development at qt-project.org<mailto:development at qt-project.org>>
Subject: Maintenance break tonight and tomorrow

Hi

IT will transfer over some infra related services from the old facilities to the new one this weekend. Jenkins, Coin, IRC, mail services are affected in such that we will shut them down for ~15 minutes while the move is being made. We scheduled these to happen late in the evening, around 22:00 EET, so that the moves will minimize the effect you your development.

Thanks for your patience,
-Tony
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20170828/88e39d51/attachment.html>

From jhihn at gmx.com  Mon Aug 28 16:01:07 2017
From: jhihn at gmx.com (Jason H)
Date: Mon, 28 Aug 2017 16:01:07 +0200
Subject: [Development] Qt and IoT infographic
In-Reply-To: <1692398.lzVxuX8aJu@tjmaciei-mobl1>
References: <1692398.lzVxuX8aJu@tjmaciei-mobl1>
Message-ID: <trinity-5d006d9d-cdeb-4e90-a5c6-abfe5d8a6ab4-1503928867114@3c-app-mailcom-bs02>



> Sent: Thursday, August 24, 2017 at 5:00 PM
> From: "Thiago Macieira" <thiago.macieira at intel.com>
> To: development at qt-project.org
> Subject: [Development] Qt and IoT infographic
>
> Re the inforgraphic at
>   https://info.qt.io/whitepaper-building-the-internet-of-things
>   (not the paper because it's asking information I won't give before I get it)
> 
> First of all, I like that Qt Company is taking this seriously. You can improve 
> those graphics with target numbers for 2020, which are talking about 200 
> billion devices connected (I think the analysis is from Gartner).
> 
> My criticism is what I *don't* see in this: local communication. Cloud 
> communication *should* be secondary in IoT. In fact, few devices should 
> communicate with the Cloud, hopefully only those that have hardened security 
> and where the user can control the privacy settings on. In a given smart home, 
> you should be able to count how many of those exist in the fingers of one hand.
> 
> So where's the information about local network discovery and communication? 
> Where's the strategy on common protocols and data models? Publish and 
> subscribe of notifications?
> 
> Please see this article from Monday that is relevant to this topic:
> http://www.zdnet.com/article/sonos-accept-new-privacy-policy-speakers-cease-to-function/
> 
> See also my comment: https://plus.google.com/+ThiagoMacieira/posts/goErhFrhzoS
> 
> The infographic makes a spectacular error in this area. It says "Your data, 
> your code, your cloud". Well, no: that's your code and it may be your cloud, 
> but it's most definitely not your data. It's someone else's data.
> 
> And now you know why I'm working on QtNetwork and want to implement DTLS.
> 
> PS: it also says "Artificial Intelligence" in "The Backbone" part. How is that 
> relevant to Qt or where is it exposed in Qt?
> 
> -- 
> Thiago Macieira - thiago.macieira (AT) intel.com
>   Software Architect - Intel Open Source Technology Center


1. That URL takes me to a form I must complete despite being logged in with my Qt account.

Onto my criticisms of Qt wrt IoT:

2. ZeroConf should be a standard thing. Where's Qt's support?
3.  IoT generally use web services, namely RESTful APIs. Where's Qt's support for writing a RESTful server?
4. Qt has often neglected web architecture.  While I agree the web as a platform is terrible, and it's only ever been done right once (Wt), it's what we're stuck with. Qt has been amazing for making embedded apps, but fails at providing access to those apps over HTTP/S protocol. From QML's lack of Web Browser support, to the amount of work required to provide access via HTTP/S to QObjects, it's hard for me to take Qt seriously as a IoT platform.
a. QML needs an official web runtime, that is, make QMLWeb or one of the similar projects officially supported so it can be used for UI in browsers*, and,
b. Remove the GL dependency for QML, so that QML can function as a way to make a headless HTTP server that makes it trivial to map HTTP requests to QObjects or QML Elements**.

* The new 5.10 WebGL feature is nice, and amazing, but still leaves a lot to be desired. You really need to be able to partition the IoT offering as web service and UI. With WebGL, they are too tightly coupled. It does have merit for people who want to web-enable a device that supports one user at a time, but that is only a subset of IoT devices.
** If removing it is too hard an alternative engine may be provided. 

Until those conditions are met, you're better off not using Qt. At least not by itself. Which is where your problem lies. Now you have to have a C++ developer and a web backend developer and a web UI developer. For 99% of the market, you only get to hire someone who has two of those three skills.


 





From jeanmichael.celerier at gmail.com  Mon Aug 28 16:16:46 2017
From: jeanmichael.celerier at gmail.com (=?UTF-8?Q?Jean=2DMicha=C3=ABl_Celerier?=)
Date: Mon, 28 Aug 2017 16:16:46 +0200
Subject: [Development] Qt and IoT infographic
In-Reply-To: <trinity-5d006d9d-cdeb-4e90-a5c6-abfe5d8a6ab4-1503928867114@3c-app-mailcom-bs02>
References: <1692398.lzVxuX8aJu@tjmaciei-mobl1>
	<trinity-5d006d9d-cdeb-4e90-a5c6-abfe5d8a6ab4-1503928867114@3c-app-mailcom-bs02>
Message-ID: <CAE1uMrV-tAgJkSLwG67mqj+fTssvE4nH+_B+U=_N5UUnbqYavQ@mail.gmail.com>

> 3.  IoT generally use web services, namely RESTful APIs.
Cutelyst has been a nice project for writing web services in Qt:
https://github.com/cutelyst/cutelyst/wiki/Tutorial_02_CutelystBasics

> a. QML needs an official web runtime, that is, make QMLWeb or one of the
similar projects officially supported so it can be used for UI in
browsers*, and,

+1 * 10000
or merge the webassembly patches (
https://codereview.qt-project.org/#/c/178543/), whatever, but it would be
so good to run Qt apps in client side web browser


Best,
-------
Jean-Michaël Celerier
http://www.jcelerier.name

On Mon, Aug 28, 2017 at 4:01 PM, Jason H <jhihn at gmx.com> wrote:

>
>
> > Sent: Thursday, August 24, 2017 at 5:00 PM
> > From: "Thiago Macieira" <thiago.macieira at intel.com>
> > To: development at qt-project.org
> > Subject: [Development] Qt and IoT infographic
> >
> > Re the inforgraphic at
> >   https://info.qt.io/whitepaper-building-the-internet-of-things
> >   (not the paper because it's asking information I won't give before I
> get it)
> >
> > First of all, I like that Qt Company is taking this seriously. You can
> improve
> > those graphics with target numbers for 2020, which are talking about 200
> > billion devices connected (I think the analysis is from Gartner).
> >
> > My criticism is what I *don't* see in this: local communication. Cloud
> > communication *should* be secondary in IoT. In fact, few devices should
> > communicate with the Cloud, hopefully only those that have hardened
> security
> > and where the user can control the privacy settings on. In a given smart
> home,
> > you should be able to count how many of those exist in the fingers of
> one hand.
> >
> > So where's the information about local network discovery and
> communication?
> > Where's the strategy on common protocols and data models? Publish and
> > subscribe of notifications?
> >
> > Please see this article from Monday that is relevant to this topic:
> > http://www.zdnet.com/article/sonos-accept-new-privacy-
> policy-speakers-cease-to-function/
> >
> > See also my comment: https://plus.google.com/+ThiagoMacieira/posts/
> goErhFrhzoS
> >
> > The infographic makes a spectacular error in this area. It says "Your
> data,
> > your code, your cloud". Well, no: that's your code and it may be your
> cloud,
> > but it's most definitely not your data. It's someone else's data.
> >
> > And now you know why I'm working on QtNetwork and want to implement DTLS.
> >
> > PS: it also says "Artificial Intelligence" in "The Backbone" part. How
> is that
> > relevant to Qt or where is it exposed in Qt?
> >
> > --
> > Thiago Macieira - thiago.macieira (AT) intel.com
> >   Software Architect - Intel Open Source Technology Center
>
>
> 1. That URL takes me to a form I must complete despite being logged in
> with my Qt account.
>
> Onto my criticisms of Qt wrt IoT:
>
> 2. ZeroConf should be a standard thing. Where's Qt's support?
> 3.  IoT generally use web services, namely RESTful APIs. Where's Qt's
> support for writing a RESTful server?
> 4. Qt has often neglected web architecture.  While I agree the web as a
> platform is terrible, and it's only ever been done right once (Wt), it's
> what we're stuck with. Qt has been amazing for making embedded apps, but
> fails at providing access to those apps over HTTP/S protocol. From QML's
> lack of Web Browser support, to the amount of work required to provide
> access via HTTP/S to QObjects, it's hard for me to take Qt seriously as a
> IoT platform.
> a. QML needs an official web runtime, that is, make QMLWeb or one of the
> similar projects officially supported so it can be used for UI in
> browsers*, and,
> b. Remove the GL dependency for QML, so that QML can function as a way to
> make a headless HTTP server that makes it trivial to map HTTP requests to
> QObjects or QML Elements**.
>
> * The new 5.10 WebGL feature is nice, and amazing, but still leaves a lot
> to be desired. You really need to be able to partition the IoT offering as
> web service and UI. With WebGL, they are too tightly coupled. It does have
> merit for people who want to web-enable a device that supports one user at
> a time, but that is only a subset of IoT devices.
> ** If removing it is too hard an alternative engine may be provided.
>
> Until those conditions are met, you're better off not using Qt. At least
> not by itself. Which is where your problem lies. Now you have to have a C++
> developer and a web backend developer and a web UI developer. For 99% of
> the market, you only get to hire someone who has two of those three skills.
>
>
>
>
>
>
> _______________________________________________
> Development mailing list
> Development at qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20170828/18cb2157/attachment.html>

From thiago.macieira at intel.com  Mon Aug 28 17:38:01 2017
From: thiago.macieira at intel.com (Thiago Macieira)
Date: Mon, 28 Aug 2017 08:38:01 -0700
Subject: [Development] Qt and IoT infographic
In-Reply-To: <trinity-5d006d9d-cdeb-4e90-a5c6-abfe5d8a6ab4-1503928867114@3c-app-mailcom-bs02>
References: <1692398.lzVxuX8aJu@tjmaciei-mobl1>
	<trinity-5d006d9d-cdeb-4e90-a5c6-abfe5d8a6ab4-1503928867114@3c-app-mailcom-bs02>
Message-ID: <2364421.jUIFWPXPns@tjmaciei-mobl1>

On Monday, 28 August 2017 07:01:07 PDT Jason H wrote:
> Onto my criticisms of Qt wrt IoT:
> 
> 2. ZeroConf should be a standard thing. Where's Qt's support?

Right now, in KF5 (kdnssd).

> 3.  IoT generally use web services, namely RESTful APIs. Where's Qt's
> support for writing a RESTful server? 

Timur began working on an simple HTTP server. This is a controversial 
decision, since we've long said that Qt should not be the tool for server-side 
programs.

But I dispute your assertion that it should be "web services". That's why I 
want to work on CoAP, which is much simpler than HTTP. It's still REST, but 
not web.

> b. Remove
> the GL dependency for QML, so that QML can function as a way to make a
> headless HTTP server that makes it trivial to map HTTP requests to QObjects
> or QML Elements**.

QML does not have a GL dependency. Or, for that matter, a graphical one.

 ldd $QTLIBDIR/libQt5Qml.t.so.5
        linux-vdso.so.1 (0x00007ffe33fcf000)
        libQt5Network.t.so.5 => /home/tjmaciei/obj/qt/qt5/qtbase/lib/
libQt5Network.t.so.5 (0x00007fcaa427a000)
        libQt5Core.t.so.5 => /home/tjmaciei/obj/qt/qt5/qtbase/lib/
libQt5Core.t.so.5 (0x00007fcaa3bfd000)
        libpthread.so.0 => /lib64/libpthread.so.0 (0x00007fcaa39df000)
        libdl.so.2 => /lib64/libdl.so.2 (0x00007fcaa37db000)
        libstdc++.so.6 => /usr/lib64/libstdc++.so.6 (0x00007fcaa3453000)
        libm.so.6 => /lib64/libm.so.6 (0x00007fcaa3141000)
        libc.so.6 => /lib64/libc.so.6 (0x00007fcaa2d9b000)
        libz.so.1 => /lib64/libz.so.1 (0x00007fcaa2b84000)
        libssl.so.1.0.0 => /usr/lib64/libssl.so.1.0.0 (0x00007fcaa2916000)
        libcrypto.so.1.0.0 => /usr/lib64/libcrypto.so.1.0.0 
(0x00007fcaa24a9000)
        libsystemd.so.0 => /usr/lib64/libsystemd.so.0 (0x00007fcaa2215000)
        libicui18n.so.59.1 => /usr/lib64/libicui18n.so.59.1 
(0x00007fcaa1d88000)
        libicuuc.so.59.1 => /usr/lib64/libicuuc.so.59.1 (0x00007fcaa19d0000)
        libpcre2-16.so.0 => /usr/lib64/libpcre2-16.so.0 (0x00007fcaa1762000)
        libdouble-conversion.so.1 => /usr/lib64/libdouble-conversion.so.1 
(0x00007fcaa1551000)
        libglib-2.0.so.0 => /usr/lib64/libglib-2.0.so.0 (0x00007fcaa123b000)
        libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00007fcaa1024000)
        /lib64/ld-linux-x86-64.so.2 (0x00007fcaa4bd5000)
        libresolv.so.2 => /lib64/libresolv.so.2 (0x00007fcaa0e0e000)
        libselinux.so.1 => /lib64/libselinux.so.1 (0x00007fcaa0be7000)
        libcap.so.2 => /usr/lib64/libcap.so.2 (0x00007fcaa09e2000)
        librt.so.1 => /lib64/librt.so.1 (0x00007fcaa07da000)
        liblzma.so.5 => /usr/lib64/liblzma.so.5 (0x00007fcaa059f000)
        liblz4.so.1 => /usr/lib64/liblz4.so.1 (0x00007fcaa038b000)
        libgcrypt.so.20 => /usr/lib64/libgcrypt.so.20 (0x00007fcaa007b000)
        libgpg-error.so.0 => /usr/lib64/libgpg-error.so.0 (0x00007fca9fe66000)
        libicudata.so.59.1 => /usr/lib64/libicudata.so.59.1 
(0x00007fca9fc65000)
        libpcre.so.1 => /usr/lib64/libpcre.so.1 (0x00007fca9f9d8000)

No, QtGui, no GL, no X11, nothing.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center



From ville.voutilainen at gmail.com  Mon Aug 28 17:47:42 2017
From: ville.voutilainen at gmail.com (Ville Voutilainen)
Date: Mon, 28 Aug 2017 18:47:42 +0300
Subject: [Development] Qt and IoT infographic
In-Reply-To: <2364421.jUIFWPXPns@tjmaciei-mobl1>
References: <1692398.lzVxuX8aJu@tjmaciei-mobl1>
	<trinity-5d006d9d-cdeb-4e90-a5c6-abfe5d8a6ab4-1503928867114@3c-app-mailcom-bs02>
	<2364421.jUIFWPXPns@tjmaciei-mobl1>
Message-ID: <CAFk2RUas=ogrf6K9OSBkLgBWBEFQyadKmPs0UB6pvHWQD+DvUA@mail.gmail.com>

On 28 August 2017 at 18:38, Thiago Macieira <thiago.macieira at intel.com> wrote:
> Timur began working on an simple HTTP server. This is a controversial
> decision, since we've long said that Qt should not be the tool for server-side
> programs.

That might be worth reconsidering as a guideline decision, because
there are some indications
that C++ is being increasingly used as a server-side language.
Anecdotally, I've seen some such
projects, and in one of them there was a need to write a SOAP server
and KDSoap was a fairly
obvious candidate to choose for it. That particular shop was a heavy
user of Qt on the client side,
so having Qt-related parts on the server side was no downside for
them. I have also seen all sorts
of migrations where non-UI code that deals with business logic and
databases gets moved to
a server, and in a bunch of such cases users didn't think twice about
having Qt as a tool for
server-side programs.


From jhihn at gmx.com  Mon Aug 28 21:26:55 2017
From: jhihn at gmx.com (Jason H)
Date: Mon, 28 Aug 2017 21:26:55 +0200
Subject: [Development] Qt and IoT infographic
In-Reply-To: <2364421.jUIFWPXPns@tjmaciei-mobl1>
References: <1692398.lzVxuX8aJu@tjmaciei-mobl1>
	<trinity-5d006d9d-cdeb-4e90-a5c6-abfe5d8a6ab4-1503928867114@3c-app-mailcom-bs02>
	<2364421.jUIFWPXPns@tjmaciei-mobl1>
Message-ID: <trinity-8355173d-64ca-4588-955d-14fc86d4811f-1503948415322@3c-app-mailcom-bs15>

> Sent: Monday, August 28, 2017 at 11:38 AM
> From: "Thiago Macieira" <thiago.macieira at intel.com>
> To: development at qt-project.org
> Subject: Re: [Development] Qt and IoT infographic
>
> On Monday, 28 August 2017 07:01:07 PDT Jason H wrote:
> > Onto my criticisms of Qt wrt IoT:
> > 
> > 2. ZeroConf should be a standard thing. Where's Qt's support?
> 
> Right now, in KF5 (kdnssd).

And who puts/[wants to put] KDE on IoT?

 
> > 3.  IoT generally use web services, namely RESTful APIs. Where's Qt's
> > support for writing a RESTful server? 
> 
> Timur began working on an simple HTTP server. This is a controversial 
> decision, since we've long said that Qt should not be the tool for server-side 
> programs.

It shouldn't be that controversial. We're just observing MVC and pushing it from single-process to multi-process. We're not pushing Qt for the web per se, just making it an equal citizen.

> But I dispute your assertion that it should be "web services". That's why I 
> want to work on CoAP, which is much simpler than HTTP. It's still REST, but 
> not web.

Yes, and paint yourself into a corner of the internet again. While CoAP and REST are both mentioned on the web page, but it also says: "From a developer point of view, CoAP feels very much like HTTP. Obtaining a value from a sensor is not much different from obtaining a value from a Web API."

I don't see why full-on-HTTP shouldn't be supported. You (the customer) might be focused on IoT, but why restrict the other users to it as well? Just go for full-on HTTP. I'm not against CoAP, but please don't raise hurdles for those that don't need it. 

Over time the number of examples/demos where Qt consumes web services has grown dramatically, but Qt apps haven't really ever been able to provide the internet with services. Like it or not, the internet is a bus that enables modern society. And the data locked in my Qt programs can't easily contribute to that.

> > b. Remove
> > the GL dependency for QML, so that QML can function as a way to make a
> > headless HTTP server that makes it trivial to map HTTP requests to QObjects
> > or QML Elements**.
> 
> QML does not have a GL dependency. Or, for that matter, a graphical one.
> 
>  ldd $QTLIBDIR/libQt5Qml.t.so.5
>         linux-vdso.so.1 (0x00007ffe33fcf000)
>         libQt5Network.t.so.5 => /home/tjmaciei/obj/qt/qt5/qtbase/lib/
> libQt5Network.t.so.5 (0x00007fcaa427a000)
>         libQt5Core.t.so.5 => /home/tjmaciei/obj/qt/qt5/qtbase/lib/
> libQt5Core.t.so.5 (0x00007fcaa3bfd000)
>         libpthread.so.0 => /lib64/libpthread.so.0 (0x00007fcaa39df000)
>         libdl.so.2 => /lib64/libdl.so.2 (0x00007fcaa37db000)
>         libstdc++.so.6 => /usr/lib64/libstdc++.so.6 (0x00007fcaa3453000)
>         libm.so.6 => /lib64/libm.so.6 (0x00007fcaa3141000)
>         libc.so.6 => /lib64/libc.so.6 (0x00007fcaa2d9b000)
>         libz.so.1 => /lib64/libz.so.1 (0x00007fcaa2b84000)
>         libssl.so.1.0.0 => /usr/lib64/libssl.so.1.0.0 (0x00007fcaa2916000)
>         libcrypto.so.1.0.0 => /usr/lib64/libcrypto.so.1.0.0 
> (0x00007fcaa24a9000)
>         libsystemd.so.0 => /usr/lib64/libsystemd.so.0 (0x00007fcaa2215000)
>         libicui18n.so.59.1 => /usr/lib64/libicui18n.so.59.1 
> (0x00007fcaa1d88000)
>         libicuuc.so.59.1 => /usr/lib64/libicuuc.so.59.1 (0x00007fcaa19d0000)
>         libpcre2-16.so.0 => /usr/lib64/libpcre2-16.so.0 (0x00007fcaa1762000)
>         libdouble-conversion.so.1 => /usr/lib64/libdouble-conversion.so.1 
> (0x00007fcaa1551000)
>         libglib-2.0.so.0 => /usr/lib64/libglib-2.0.so.0 (0x00007fcaa123b000)
>         libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00007fcaa1024000)
>         /lib64/ld-linux-x86-64.so.2 (0x00007fcaa4bd5000)
>         libresolv.so.2 => /lib64/libresolv.so.2 (0x00007fcaa0e0e000)
>         libselinux.so.1 => /lib64/libselinux.so.1 (0x00007fcaa0be7000)
>         libcap.so.2 => /usr/lib64/libcap.so.2 (0x00007fcaa09e2000)
>         librt.so.1 => /lib64/librt.so.1 (0x00007fcaa07da000)
>         liblzma.so.5 => /usr/lib64/liblzma.so.5 (0x00007fcaa059f000)
>         liblz4.so.1 => /usr/lib64/liblz4.so.1 (0x00007fcaa038b000)
>         libgcrypt.so.20 => /usr/lib64/libgcrypt.so.20 (0x00007fcaa007b000)
>         libgpg-error.so.0 => /usr/lib64/libgpg-error.so.0 (0x00007fca9fe66000)
>         libicudata.so.59.1 => /usr/lib64/libicudata.so.59.1 
> (0x00007fca9fc65000)
>         libpcre.so.1 => /usr/lib64/libpcre.so.1 (0x00007fca9f9d8000)
> 
> No, QtGui, no GL, no X11, nothing.

I seem to remember a big deal about QtQuick 2.0 requiring GL? perhaps that's just for Items? If I'm mistaken, then I am very happily mistaken!


From jeanmichael.celerier at gmail.com  Mon Aug 28 21:41:15 2017
From: jeanmichael.celerier at gmail.com (=?UTF-8?Q?Jean=2DMicha=C3=ABl_Celerier?=)
Date: Mon, 28 Aug 2017 21:41:15 +0200
Subject: [Development] Qt and IoT infographic
In-Reply-To: <trinity-8355173d-64ca-4588-955d-14fc86d4811f-1503948415322@3c-app-mailcom-bs15>
References: <1692398.lzVxuX8aJu@tjmaciei-mobl1>
	<trinity-5d006d9d-cdeb-4e90-a5c6-abfe5d8a6ab4-1503928867114@3c-app-mailcom-bs02>
	<2364421.jUIFWPXPns@tjmaciei-mobl1>
	<trinity-8355173d-64ca-4588-955d-14fc86d4811f-1503948415322@3c-app-mailcom-bs15>
Message-ID: <CAE1uMrU8tMvwk9cQmOxHfXyvb3sh63d8v7teTyuw3GybDwDzjg@mail.gmail.com>

> I seem to remember a big deal about QtQuick 2.0 requiring GL? perhaps
that's just for Items? If I'm mistaken, then I am very happily mistaken!

QtQuick != QML. QML is a programming language and runtime for said
language, QtQuick is a scene graph. It's possible* to use QtQuick without
QML and QML without QtQuick.

* apparently QQuickWindow has some ties to the QML engine but in my
experience you can just create new QQuickItem from c++ and add them as
child of the rootItem and it works.



-------
Jean-Michaël Celerier
http://www.jcelerier.name

On Mon, Aug 28, 2017 at 9:26 PM, Jason H <jhihn at gmx.com> wrote:

> > Sent: Monday, August 28, 2017 at 11:38 AM
> > From: "Thiago Macieira" <thiago.macieira at intel.com>
> > To: development at qt-project.org
> > Subject: Re: [Development] Qt and IoT infographic
> >
> > On Monday, 28 August 2017 07:01:07 PDT Jason H wrote:
> > > Onto my criticisms of Qt wrt IoT:
> > >
> > > 2. ZeroConf should be a standard thing. Where's Qt's support?
> >
> > Right now, in KF5 (kdnssd).
>
> And who puts/[wants to put] KDE on IoT?
>
>
> > > 3.  IoT generally use web services, namely RESTful APIs. Where's Qt's
> > > support for writing a RESTful server?
> >
> > Timur began working on an simple HTTP server. This is a controversial
> > decision, since we've long said that Qt should not be the tool for
> server-side
> > programs.
>
> It shouldn't be that controversial. We're just observing MVC and pushing
> it from single-process to multi-process. We're not pushing Qt for the web
> per se, just making it an equal citizen.
>
> > But I dispute your assertion that it should be "web services". That's
> why I
> > want to work on CoAP, which is much simpler than HTTP. It's still REST,
> but
> > not web.
>
> Yes, and paint yourself into a corner of the internet again. While CoAP
> and REST are both mentioned on the web page, but it also says: "From a
> developer point of view, CoAP feels very much like HTTP. Obtaining a value
> from a sensor is not much different from obtaining a value from a Web API."
>
> I don't see why full-on-HTTP shouldn't be supported. You (the customer)
> might be focused on IoT, but why restrict the other users to it as well?
> Just go for full-on HTTP. I'm not against CoAP, but please don't raise
> hurdles for those that don't need it.
>
> Over time the number of examples/demos where Qt consumes web services has
> grown dramatically, but Qt apps haven't really ever been able to provide
> the internet with services. Like it or not, the internet is a bus that
> enables modern society. And the data locked in my Qt programs can't easily
> contribute to that.
>
> > > b. Remove
> > > the GL dependency for QML, so that QML can function as a way to make a
> > > headless HTTP server that makes it trivial to map HTTP requests to
> QObjects
> > > or QML Elements**.
> >
> > QML does not have a GL dependency. Or, for that matter, a graphical one.
> >
> >  ldd $QTLIBDIR/libQt5Qml.t.so.5
> >         linux-vdso.so.1 (0x00007ffe33fcf000)
> >         libQt5Network.t.so.5 => /home/tjmaciei/obj/qt/qt5/qtbase/lib/
> > libQt5Network.t.so.5 (0x00007fcaa427a000)
> >         libQt5Core.t.so.5 => /home/tjmaciei/obj/qt/qt5/qtbase/lib/
> > libQt5Core.t.so.5 (0x00007fcaa3bfd000)
> >         libpthread.so.0 => /lib64/libpthread.so.0 (0x00007fcaa39df000)
> >         libdl.so.2 => /lib64/libdl.so.2 (0x00007fcaa37db000)
> >         libstdc++.so.6 => /usr/lib64/libstdc++.so.6 (0x00007fcaa3453000)
> >         libm.so.6 => /lib64/libm.so.6 (0x00007fcaa3141000)
> >         libc.so.6 => /lib64/libc.so.6 (0x00007fcaa2d9b000)
> >         libz.so.1 => /lib64/libz.so.1 (0x00007fcaa2b84000)
> >         libssl.so.1.0.0 => /usr/lib64/libssl.so.1.0.0
> (0x00007fcaa2916000)
> >         libcrypto.so.1.0.0 => /usr/lib64/libcrypto.so.1.0.0
> > (0x00007fcaa24a9000)
> >         libsystemd.so.0 => /usr/lib64/libsystemd.so.0
> (0x00007fcaa2215000)
> >         libicui18n.so.59.1 => /usr/lib64/libicui18n.so.59.1
> > (0x00007fcaa1d88000)
> >         libicuuc.so.59.1 => /usr/lib64/libicuuc.so.59.1
> (0x00007fcaa19d0000)
> >         libpcre2-16.so.0 => /usr/lib64/libpcre2-16.so.0
> (0x00007fcaa1762000)
> >         libdouble-conversion.so.1 => /usr/lib64/libdouble-
> conversion.so.1
> > (0x00007fcaa1551000)
> >         libglib-2.0.so.0 => /usr/lib64/libglib-2.0.so.0
> (0x00007fcaa123b000)
> >         libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00007fcaa1024000)
> >         /lib64/ld-linux-x86-64.so.2 (0x00007fcaa4bd5000)
> >         libresolv.so.2 => /lib64/libresolv.so.2 (0x00007fcaa0e0e000)
> >         libselinux.so.1 => /lib64/libselinux.so.1 (0x00007fcaa0be7000)
> >         libcap.so.2 => /usr/lib64/libcap.so.2 (0x00007fcaa09e2000)
> >         librt.so.1 => /lib64/librt.so.1 (0x00007fcaa07da000)
> >         liblzma.so.5 => /usr/lib64/liblzma.so.5 (0x00007fcaa059f000)
> >         liblz4.so.1 => /usr/lib64/liblz4.so.1 (0x00007fcaa038b000)
> >         libgcrypt.so.20 => /usr/lib64/libgcrypt.so.20
> (0x00007fcaa007b000)
> >         libgpg-error.so.0 => /usr/lib64/libgpg-error.so.0
> (0x00007fca9fe66000)
> >         libicudata.so.59.1 => /usr/lib64/libicudata.so.59.1
> > (0x00007fca9fc65000)
> >         libpcre.so.1 => /usr/lib64/libpcre.so.1 (0x00007fca9f9d8000)
> >
> > No, QtGui, no GL, no X11, nothing.
>
> I seem to remember a big deal about QtQuick 2.0 requiring GL? perhaps
> that's just for Items? If I'm mistaken, then I am very happily mistaken!
> _______________________________________________
> Development mailing list
> Development at qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20170828/59f4cd72/attachment.html>

From thiago.macieira at intel.com  Mon Aug 28 22:01:29 2017
From: thiago.macieira at intel.com (Thiago Macieira)
Date: Mon, 28 Aug 2017 13:01:29 -0700
Subject: [Development] Qt and IoT infographic
In-Reply-To: <trinity-8355173d-64ca-4588-955d-14fc86d4811f-1503948415322@3c-app-mailcom-bs15>
References: <1692398.lzVxuX8aJu@tjmaciei-mobl1>
	<2364421.jUIFWPXPns@tjmaciei-mobl1>
	<trinity-8355173d-64ca-4588-955d-14fc86d4811f-1503948415322@3c-app-mailcom-bs15>
Message-ID: <17696992.PPTgx0HhA3@tjmaciei-mobl1>

On Monday, 28 August 2017 12:26:55 PDT Jason H wrote:
> > > 2. ZeroConf should be a standard thing. Where's Qt's support?
> > 
> > Right now, in KF5 (kdnssd).
> 
> And who puts/[wants to put] KDE on IoT?

a) it's just one library. KF5 was designed as multiple, smaller, independent 
libraries that can be added to Qt programs. That's one of the reasons we won't 
add a .zip file API to Qt -- just use KF5Archive.

b) and who puts Qt on IoT? If we're going to challenge that, then we may as 
well challenge the answer to KF5-on-IoT.

> > > 3.  IoT generally use web services, namely RESTful APIs. Where's Qt's
> > > support for writing a RESTful server?
> > 
> > Timur began working on an simple HTTP server. This is a controversial
> > decision, since we've long said that Qt should not be the tool for
> > server-side programs.
> 
> It shouldn't be that controversial. We're just observing MVC and pushing it
> from single-process to multi-process. We're not pushing Qt for the web per
> se, just making it an equal citizen.

Servers are much more complex beasts than clients. Almost every single 
vulnerability found in the Internet is related to servers.

Just think of the fact that QTcpSocket has an unlimited buffer. Does this 
spell "denial of service" to you?

> > But I dispute your assertion that it should be "web services". That's why
> > I
> > want to work on CoAP, which is much simpler than HTTP. It's still REST,
> > but
> > not web.
> 
> Yes, and paint yourself into a corner of the internet again. While CoAP and
> REST are both mentioned on the web page, but it also says: "From a
> developer point of view, CoAP feels very much like HTTP. Obtaining a value
> from a sensor is not much different from obtaining a value from a Web API."

If you're going to communicate with a tiny MCU connected over a mesh network 
like 6LoWPAN/Thread, you won't be using TCP. Much less HTTP.

No, UDP, DTLS and CoAP are much more important at this stage of IoT than HTTP 
servers.

> I don't see why full-on-HTTP shouldn't be supported. You (the customer)
> might be focused on IoT, but why restrict the other users to it as well?
> Just go for full-on HTTP. I'm not against CoAP, but please don't raise
> hurdles for those that don't need it.

I'm not saying we shouldn't, but there's a matter of priorities and resources. 
We can reasonably easily write a CoAP client *and* server, with multicast 
support, for 5.11. This will allow you to communicate with the MCU-class IoT 
devices, which should correspond to something like 80 to 90% of the 200 
billion that are expected.

An HTTP server will not happen for 5.11. It's MUCH more complex and will 
require a lot more reviewing. At best, expect an early technology preview at 
that time, subject to API change (and not in qtbase).

> Over time the number of examples/demos where Qt consumes web services has
> grown dramatically, but Qt apps haven't really ever been able to provide
> the internet with services. Like it or not, the internet is a bus that
> enables modern society. And the data locked in my Qt programs can't easily
> contribute to that.

That's by choice. Qt applications are meant to be clients to those services, 
not servers.

> > > b. Remove
> > > the GL dependency for QML, so that QML can function as a way to make a
> > > headless HTTP server that makes it trivial to map HTTP requests to
> > > QObjects
> > > or QML Elements**.

> > No, QtGui, no GL, no X11, nothing.
> 
> I seem to remember a big deal about QtQuick 2.0 requiring GL? perhaps that's
> just for Items? If I'm mistaken, then I am very happily mistaken!

You're confusing QtQuick with QML. You asked about QML requiring GL, and it 
doesn't. You were even talking about making requests to QObjects, which 
indicated to me that you did not mean any of the existing graphical elements.

QtQuick is the UI API on top of QML. It does require QtGui and it was designed 
on top of OpenGL. There was some talk a while ago about the Qt Company 
contributing a raster engine to it, but I haven't followed the discussion or 
checked the code. Of course, even if it happened, don't expect performance.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center



From rjvbertin at gmail.com  Mon Aug 28 23:10:22 2017
From: rjvbertin at gmail.com (=?ISO-8859-1?Q?Ren=E9_J=2EV=2E?= Bertin)
Date: Mon, 28 Aug 2017 23:10:22 +0200
Subject: [Development] Assistant (and others) burning CPU because of
 #f27d1ccbb24ec2fd4098f2976503478831006cc8 ?
Message-ID: <1600335.9fNCGNT7fm@portia.local>

Hi,

I noticed an annoying change after doing the periodic merge of changes in the qtbase/5.9 branch with my standalone Cocoa QPA.
Commit f27d1ccbb24ec2fd4098f2976503478831006cc8 introduced a delayed invocation of [NSMenu update], which looks like a good idea. However, in some applications, including the Assistant, this somehow causes QCocoaTimer::timerEvent() to be called continuously, always with timerId 454.

That's in Qt 5.9.1 (stock, release) but also in my own patched Qt 5.8.0; the former with the standalone QPA backported to OS X 10.9 and for the latter, backported to Qt 5.8 too.

I cannot really imagine that this is an effect of the backporting; QTimer has been around for too long and the consistency of the id=454 timer suggests something else is going on.

The other applications in which I notice the CPU burning issue are KDevelop and Creator : like Assistant they both use QtHelp functionality.

Thanks,
René


From rjvbertin at gmail.com  Tue Aug 29 02:06:18 2017
From: rjvbertin at gmail.com (=?ISO-8859-1?Q?Ren=E9_J=2EV=2E?= Bertin)
Date: Tue, 29 Aug 2017 02:06:18 +0200
Subject: [Development] [fix]: Assistant (and others) burning CPU because
 of #f27d1ccbb24ec2fd4098f2976503478831006cc8 ?
In-Reply-To: <1600335.9fNCGNT7fm@portia.local>
References: <1600335.9fNCGNT7fm@portia.local>
Message-ID: <6588846.MrPyxkD8tX@portia.local>

On Monday August 28 2017 23:10:22 René J.V. Bertin wrote:

I found a potential fix: shouldn't QCocoaMenu::timerEvent() call

        killTimer(m_updateTimer);

before setting m_updateTimer=0? Whether or not it's appropriate, this does solve the CPU burning for me.

R.

> Hi,
> 
> I noticed an annoying change after doing the periodic merge of changes in the qtbase/5.9 branch with my standalone Cocoa QPA.
> Commit f27d1ccbb24ec2fd4098f2976503478831006cc8 introduced a delayed invocation of [NSMenu update], which looks like a good idea. However, in some applications, including the Assistant, this somehow causes QCocoaTimer::timerEvent() to be called continuously, always with timerId 454.
> 
> That's in Qt 5.9.1 (stock, release) but also in my own patched Qt 5.8.0; the former with the standalone QPA backported to OS X 10.9 and for the latter, backported to Qt 5.8 too.
> 
> I cannot really imagine that this is an effect of the backporting; QTimer has been around for too long and the consistency of the id=454 timer suggests something else is going on.
> 
> The other applications in which I notice the CPU burning issue are KDevelop and Creator : like Assistant they both use QtHelp functionality.
> 
> Thanks,
> René



From thiago.macieira at intel.com  Tue Aug 29 04:00:51 2017
From: thiago.macieira at intel.com (Thiago Macieira)
Date: Mon, 28 Aug 2017 19:00:51 -0700
Subject: [Development] [fix]: Assistant (and others) burning CPU because
 of #f27d1ccbb24ec2fd4098f2976503478831006cc8 ?
In-Reply-To: <6588846.MrPyxkD8tX@portia.local>
References: <1600335.9fNCGNT7fm@portia.local> <6588846.MrPyxkD8tX@portia.local>
Message-ID: <1538122.08VYYKp83P@tjmaciei-mobl1>

On Monday, 28 August 2017 17:06:18 PDT René J.V. Bertin wrote:
>         killTimer(m_updateTimer);
> 
> before setting m_updateTimer=0? Whether or not it's appropriate, this does
> solve the CPU burning for me.

Yeah, if you don't kill the timer, it will keep firing.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center



From Gabriel.deDietrich at qt.io  Tue Aug 29 04:02:59 2017
From: Gabriel.deDietrich at qt.io (Gabriel de Dietrich)
Date: Tue, 29 Aug 2017 02:02:59 +0000
Subject: [Development] [fix]: Assistant (and others) burning CPU because
 of #f27d1ccbb24ec2fd4098f2976503478831006cc8 ?
In-Reply-To: <1538122.08VYYKp83P@tjmaciei-mobl1>
References: <1600335.9fNCGNT7fm@portia.local>
	<6588846.MrPyxkD8tX@portia.local> <1538122.08VYYKp83P@tjmaciei-mobl1>
Message-ID: <256B709E-1A47-47C1-92A5-DCF598705496@qt.io>

FYI: QCocoaMenu: Stop update timer (Merged)<https://codereview.qt-project.org/203791>

Best regards,

Dr. Gabriel de Dietrich
Senior Software Developer
The Qt Company

On Aug 29, 2017, at 9:00 AM, Thiago Macieira <thiago.macieira at intel.com<mailto:thiago.macieira at intel.com>> wrote:

On Monday, 28 August 2017 17:06:18 PDT René J.V. Bertin wrote:
       killTimer(m_updateTimer);

before setting m_updateTimer=0? Whether or not it's appropriate, this does
solve the CPU burning for me.

Yeah, if you don't kill the timer, it will keep firing.

--
Thiago Macieira - thiago.macieira (AT) intel.com<http://intel.com>
 Software Architect - Intel Open Source Technology Center

_______________________________________________
Development mailing list
Development at qt-project.org<mailto:Development at qt-project.org>
http://lists.qt-project.org/mailman/listinfo/development

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20170829/498cb90b/attachment.html>

From jani.heikkinen at qt.io  Tue Aug 29 06:53:28 2017
From: jani.heikkinen at qt.io (Jani Heikkinen)
Date: Tue, 29 Aug 2017 04:53:28 +0000
Subject: [Development] Maintainers,
 your actions needed: Change files for Qt 5.6.3
Message-ID: <HE1PR02MB313245A61F337ABC985752A09D9F0@HE1PR02MB3132.eurprd02.prod.outlook.com>

Hi all,

We have now created initial change files for Qt 5.6.3. Please do needed modifications immediately and get '+2' as soon as possible. We need to get these in to be able to proceed with Qt 5.6.3 release. You can find all open change files for Qt 5.6.3 here: https://codereview.qt-project.org/#/q/branch:5.9+status:open+message:%22Add+change+file%22,n,z

After approval those change files will be direct pushed in '5.9', cherry picked in '5.6.3' and finally direct pushed there, see http://lists.qt-project.org/pipermail/development/2017-August/030722.html

br,
Jani Heikkinen
Release Manager




From Uwe.Rathmann at tigertal.de  Tue Aug 29 08:02:40 2017
From: Uwe.Rathmann at tigertal.de (Uwe Rathmann)
Date: Tue, 29 Aug 2017 06:02:40 +0000 (UTC)
Subject: [Development] Qt and IoT infographic
References: <1692398.lzVxuX8aJu@tjmaciei-mobl1>
	<trinity-5d006d9d-cdeb-4e90-a5c6-abfe5d8a6ab4-1503928867114@3c-app-mailcom-bs02>
	<2364421.jUIFWPXPns@tjmaciei-mobl1>
	<trinity-8355173d-64ca-4588-955d-14fc86d4811f-1503948415322@3c-app-mailcom-bs15>
	<CAE1uMrU8tMvwk9cQmOxHfXyvb3sh63d8v7teTyuw3GybDwDzjg@mail.gmail.com>
Message-ID: <oo3020$e05$1@blaine.gmane.org>

On Mon, 28 Aug 2017 21:41:15 +0200, Jean-Michaël Celerier wrote:

> * apparently QQuickWindow has some ties to the QML engine but in my
> experience you can just create new QQuickItem from c++ and add them as
> child of the rootItem and it works.

F.e. https://github.com/uwerat/qskinny does exactly this.

This library is our platform for an ongoing development of a quite 
complex Qt/Quick user interface in the automotive area. Platform and 
application - both are written to 100% in C++.

In case someone is interested in the qskinny project: it is under heavy 
development, but already good enough to demonstrate, what needs to be 
done to solve the memory footprint + startup performance problems.

Uwe



From andre.hartmann at iseg-hv.de  Tue Aug 29 08:25:07 2017
From: andre.hartmann at iseg-hv.de (=?UTF-8?Q?Andr=c3=a9_Hartmann?=)
Date: Tue, 29 Aug 2017 08:25:07 +0200
Subject: [Development] Maintainers,
 your actions needed: Change files for Qt 5.6.3
In-Reply-To: <HE1PR02MB313245A61F337ABC985752A09D9F0@HE1PR02MB3132.eurprd02.prod.outlook.com>
References: <HE1PR02MB313245A61F337ABC985752A09D9F0@HE1PR02MB3132.eurprd02.prod.outlook.com>
Message-ID: <c875994d-a31e-7eac-7e14-f6ae47de66bd@iseg-hv.de>

Hi Jani,

I have some comments to the change file process:

1. The commit message is "Add change file for Qt 5.6.3" but it should be
    "Add changes file for Qt 5.6.3" (plural)
2. In the last releases, this initial version was WIP, so the maintainer
    needed to adjust the message so it could be merged. I think this is
    useful.
3. How about projects with no changes between 5.6.2 and 5.6.3
    (like qtserialbus)? Usually there is also a changes file with a line
    "No relevant changes in this release", but right now there is no file
    a all.

I know it is some effort for the release team to create these templates,
but with good templates you get consistent final files for the whole
project.

Best regards,
André

Am 29.08.2017 um 06:53 schrieb Jani Heikkinen:
> Hi all,
> 
> We have now created initial change files for Qt 5.6.3. Please do needed modifications immediately and get '+2' as soon as possible. We need to get these in to be able to proceed with Qt 5.6.3 release. You can find all open change files for Qt 5.6.3 here: https://codereview.qt-project.org/#/q/branch:5.9+status:open+message:%22Add+change+file%22,n,z
> 
> After approval those change files will be direct pushed in '5.9', cherry picked in '5.6.3' and finally direct pushed there, see http://lists.qt-project.org/pipermail/development/2017-August/030722.html
> 
> br,
> Jani Heikkinen
> Release Manager
> 
> 
> _______________________________________________
> Development mailing list
> Development at qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development
> 
> 


-- 
Best regards / Mit freundlichen Grüßen
André Hartmann, Dipl.-Ing. (FH)
Software Project Manager

iseg Spezialelektronik GmbH         |  phone: ++49 (0)351 26996-43
Bautzner Landstr. 23                |  fax:   ++49 (0)351 26996-21
D-01454 Radeberg / Rossendorf       |  web:   www.iseg-hv.com

Geschäftsführer / Managing director: Dr. F. Gleisberg, Dr. J. Pöthig
Amtsgericht / Lower district court: Dresden HRB 16250
Ust.-Id.-Nr. / VAT-ID: DE812508942

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 delete this e-mail.
Any unauthorized copying, disclosure or distribution of the material
in this e-mail is strictly forbidden.


From rjvbertin at gmail.com  Tue Aug 29 10:10:53 2017
From: rjvbertin at gmail.com (=?ISO-8859-1?Q?Ren=E9_J=2EV=2E?= Bertin)
Date: Tue, 29 Aug 2017 10:10:53 +0200
Subject: [Development] [fix]: Assistant (and others) burning CPU because
 of #f27d1ccbb24ec2fd4098f2976503478831006cc8 ?
In-Reply-To: <256B709E-1A47-47C1-92A5-DCF598705496@qt.io>
References: <1600335.9fNCGNT7fm@portia.local>
	<1538122.08VYYKp83P@tjmaciei-mobl1>
	<256B709E-1A47-47C1-92A5-DCF598705496@qt.io>
Message-ID: <2016136.MCHlo2iGPk@bola>

On Tuesday August 29 2017 02:02:59 Gabriel de Dietrich wrote:
>FYI: QCocoaMenu: Stop update timer (Merged)<https://codereview.qt-project.org/203791>

Thanks for the heads-up.

>
>On Aug 29, 2017, at 9:00 AM, Thiago Macieira <thiago.macieira at intel.com<mailto:thiago.macieira at intel.com>> wrote:
>
>On Monday, 28 August 2017 17:06:18 PDT René J.V. Bertin wrote:
>       killTimer(m_updateTimer);

>Yeah, if you don't kill the timer, it will keep firing.

Which we just rediscovered :) Funny though, apparently 1 misdirected startTimer() call can turn any application in a CPU hog that burns cycles without ever doing anything. Wouldn't it be safer for QObject::timerEvent() to kill any timer that triggers it, possibly even do an abort if it can do some kind of runtime debug mode detection? At least then it's set to a 0 (zero) interval?

It took me an unreasonable amount of time trying to figure out the reason for the burning, the fact that QCocoaMenu::timerEvent() could be being called as fast as possible and for nothing occurred to me only after trying all other possibilities. And I knew only the timer change could be the culprit; I can only imagine how much more time I'd have spent if this bug had been latent for a few months.

BTW, the 1st application in which I noticed this doesn't use the native menubar at all. I'm going to have to try and understand what business it has using QCocoaMenu...

R.


From jeanmichael.celerier at gmail.com  Tue Aug 29 10:20:17 2017
From: jeanmichael.celerier at gmail.com (=?UTF-8?Q?Jean=2DMicha=C3=ABl_Celerier?=)
Date: Tue, 29 Aug 2017 10:20:17 +0200
Subject: [Development] Qt and IoT infographic
In-Reply-To: <17696992.PPTgx0HhA3@tjmaciei-mobl1>
References: <1692398.lzVxuX8aJu@tjmaciei-mobl1>
	<2364421.jUIFWPXPns@tjmaciei-mobl1>
	<trinity-8355173d-64ca-4588-955d-14fc86d4811f-1503948415322@3c-app-mailcom-bs15>
	<17696992.PPTgx0HhA3@tjmaciei-mobl1>
Message-ID: <CAE1uMrVab8i1_MxLTa9kFpgO+-a-3XMZwPC=EmpQoiK5VLmDDA@mail.gmail.com>

> If you're going to communicate with a tiny MCU connected over a mesh
network
like 6LoWPAN/Thread, you won't be using TCP. Much less HTTP.

What makes me a bit sad is that if Qt's not doing it, then we end up having
to put up with bloated stuff like Node.JS on beagleboard or raspberries :
https://www.postscapes.com/javascript-and-the-internet-of-things/ which are
now more and more used.
Hell, sometimes people use python of all languages on constrained CPUs.
It's a niche that Qt *could* fill, and fill better than the alternatives.




-------
Jean-Michaël Celerier
http://www.jcelerier.name

On Mon, Aug 28, 2017 at 10:01 PM, Thiago Macieira <thiago.macieira at intel.com
> wrote:

> On Monday, 28 August 2017 12:26:55 PDT Jason H wrote:
> > > > 2. ZeroConf should be a standard thing. Where's Qt's support?
> > >
> > > Right now, in KF5 (kdnssd).
> >
> > And who puts/[wants to put] KDE on IoT?
>
> a) it's just one library. KF5 was designed as multiple, smaller,
> independent
> libraries that can be added to Qt programs. That's one of the reasons we
> won't
> add a .zip file API to Qt -- just use KF5Archive.
>
> b) and who puts Qt on IoT? If we're going to challenge that, then we may as
> well challenge the answer to KF5-on-IoT.
>
> > > > 3.  IoT generally use web services, namely RESTful APIs. Where's Qt's
> > > > support for writing a RESTful server?
> > >
> > > Timur began working on an simple HTTP server. This is a controversial
> > > decision, since we've long said that Qt should not be the tool for
> > > server-side programs.
> >
> > It shouldn't be that controversial. We're just observing MVC and pushing
> it
> > from single-process to multi-process. We're not pushing Qt for the web
> per
> > se, just making it an equal citizen.
>
> Servers are much more complex beasts than clients. Almost every single
> vulnerability found in the Internet is related to servers.
>
> Just think of the fact that QTcpSocket has an unlimited buffer. Does this
> spell "denial of service" to you?
>
> > > But I dispute your assertion that it should be "web services". That's
> why
> > > I
> > > want to work on CoAP, which is much simpler than HTTP. It's still REST,
> > > but
> > > not web.
> >
> > Yes, and paint yourself into a corner of the internet again. While CoAP
> and
> > REST are both mentioned on the web page, but it also says: "From a
> > developer point of view, CoAP feels very much like HTTP. Obtaining a
> value
> > from a sensor is not much different from obtaining a value from a Web
> API."
>
> If you're going to communicate with a tiny MCU connected over a mesh
> network
> like 6LoWPAN/Thread, you won't be using TCP. Much less HTTP.
>
> No, UDP, DTLS and CoAP are much more important at this stage of IoT than
> HTTP
> servers.
>
> > I don't see why full-on-HTTP shouldn't be supported. You (the customer)
> > might be focused on IoT, but why restrict the other users to it as well?
> > Just go for full-on HTTP. I'm not against CoAP, but please don't raise
> > hurdles for those that don't need it.
>
> I'm not saying we shouldn't, but there's a matter of priorities and
> resources.
> We can reasonably easily write a CoAP client *and* server, with multicast
> support, for 5.11. This will allow you to communicate with the MCU-class
> IoT
> devices, which should correspond to something like 80 to 90% of the 200
> billion that are expected.
>
> An HTTP server will not happen for 5.11. It's MUCH more complex and will
> require a lot more reviewing. At best, expect an early technology preview
> at
> that time, subject to API change (and not in qtbase).
>
> > Over time the number of examples/demos where Qt consumes web services has
> > grown dramatically, but Qt apps haven't really ever been able to provide
> > the internet with services. Like it or not, the internet is a bus that
> > enables modern society. And the data locked in my Qt programs can't
> easily
> > contribute to that.
>
> That's by choice. Qt applications are meant to be clients to those
> services,
> not servers.
>
> > > > b. Remove
> > > > the GL dependency for QML, so that QML can function as a way to make
> a
> > > > headless HTTP server that makes it trivial to map HTTP requests to
> > > > QObjects
> > > > or QML Elements**.
>
> > > No, QtGui, no GL, no X11, nothing.
> >
> > I seem to remember a big deal about QtQuick 2.0 requiring GL? perhaps
> that's
> > just for Items? If I'm mistaken, then I am very happily mistaken!
>
> You're confusing QtQuick with QML. You asked about QML requiring GL, and it
> doesn't. You were even talking about making requests to QObjects, which
> indicated to me that you did not mean any of the existing graphical
> elements.
>
> QtQuick is the UI API on top of QML. It does require QtGui and it was
> designed
> on top of OpenGL. There was some talk a while ago about the Qt Company
> contributing a raster engine to it, but I haven't followed the discussion
> or
> checked the code. Of course, even if it happened, don't expect performance.
>
> --
> 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: <http://lists.qt-project.org/pipermail/development/attachments/20170829/24d56cbc/attachment.html>

From edward.welbourne at qt.io  Tue Aug 29 10:44:34 2017
From: edward.welbourne at qt.io (Edward Welbourne)
Date: Tue, 29 Aug 2017 08:44:34 +0000
Subject: [Development] Qt and IoT infographic
In-Reply-To: <CAE1uMrVab8i1_MxLTa9kFpgO+-a-3XMZwPC=EmpQoiK5VLmDDA@mail.gmail.com>
References: <1692398.lzVxuX8aJu@tjmaciei-mobl1>
	<2364421.jUIFWPXPns@tjmaciei-mobl1>
	<trinity-8355173d-64ca-4588-955d-14fc86d4811f-1503948415322@3c-app-mailcom-bs15>
	<17696992.PPTgx0HhA3@tjmaciei-mobl1>,
	<CAE1uMrVab8i1_MxLTa9kFpgO+-a-3XMZwPC=EmpQoiK5VLmDDA@mail.gmail.com>
Message-ID: <AM4PR02MB3249886B4E6450751FA2D366879F0@AM4PR02MB3249.eurprd02.prod.outlook.com>

Thiago:
>> If you're going to communicate with a tiny MCU connected over a mesh
>> network like 6LoWPAN/Thread, you won't be using TCP. Much less HTTP.

and you'll want that MCU running something light-weight in C++, not a
web-bloat thing.  So Qt is just the thing for the job.

(... and I had to google MCU - microcontroller unit, not Marvel Comic Universe ;^)

Jean-Michaël Celerier (29 August 2017 10:20)
> What makes me a bit sad is that if Qt's not doing it, then we end up
> having to put up with bloated stuff like Node.JS on beagleboard or
> raspberries :
> https://www.postscapes.com/javascript-and-the-internet-of-things/
> which are now more and more used.  Hell, sometimes people use python
> of all languages on constrained CPUs.  It's a niche that Qt *could*
> fill, and fill better than the alternatives.

We are aware of it [*] and looking at what to do.
We are, however, short of hands and up to our necks in things to do.

[*] https://wiki.qt.io/Qt_Network_Workshop_2016#IoT

	Eddy.


From Shawn.Rutledge at qt.io  Tue Aug 29 11:43:44 2017
From: Shawn.Rutledge at qt.io (Shawn Rutledge)
Date: Tue, 29 Aug 2017 09:43:44 +0000
Subject: [Development] Qt and IoT infographic
In-Reply-To: <AM4PR02MB3249886B4E6450751FA2D366879F0@AM4PR02MB3249.eurprd02.prod.outlook.com>
References: <1692398.lzVxuX8aJu@tjmaciei-mobl1>
	<2364421.jUIFWPXPns@tjmaciei-mobl1>
	<trinity-8355173d-64ca-4588-955d-14fc86d4811f-1503948415322@3c-app-mailcom-bs15>
	<17696992.PPTgx0HhA3@tjmaciei-mobl1>
	<CAE1uMrVab8i1_MxLTa9kFpgO+-a-3XMZwPC=EmpQoiK5VLmDDA@mail.gmail.com>
	<AM4PR02MB3249886B4E6450751FA2D366879F0@AM4PR02MB3249.eurprd02.prod.outlook.com>
Message-ID: <07BE9501-B980-4593-B72C-98E7234E61B2@qt.io>


> On 29 Aug 2017, at 10:44, Edward Welbourne <edward.welbourne at qt.io> wrote:
> 
> Thiago:
>>> If you're going to communicate with a tiny MCU connected over a mesh
>>> network like 6LoWPAN/Thread, you won't be using TCP. Much less HTTP.
> 
> and you'll want that MCU running something light-weight in C++, not a
> web-bloat thing.  So Qt is just the thing for the job.

A tiny MCU means an Atmel with a couple kilobytes of RAM.  Or maybe an ESP8266, the canonical IOT device right now if you want to use TCP/IP (WiFi) (rather than some lower-powered network like BLE, Zigbee, Z-Wave or LoRa); that has oodles more power and memory, but still a few orders of magnitude less than you need for Linux + Qt.

I ran into the RAM shortage while hacking on this firmware (trying to add a few features):  https://github.com/radhoo/uradmonitor_kit1  It has enough memory to allocate ONE TCP packet: a 600 byte global static, plus a few more global variables, and reserve some space for the stack.  And yet it has a web server for serving up either a human-readable page or JSON on demand, and it also pushes data to a central server periodically.  I’d like to make it discoverable via Bonjour but that might be pushing it.  After reading about CoAP I think it would be a much better fit than HTTP for such a device, so I hope I find the time to try.  But then again, browsers don’t have CoAP yet, so I wonder if there could be a web client that uses JS to talk to it.  Having to build a dedicated Qt client for it would be a step backwards in a way, but also nice for a desktop widget or some such.

Qt for IoT is maybe primarily for devices that have graphically-rich screens.  But they can be clients reading data from truly-embedded sensors, and they might also have data of their own to serve to other clients (consolidated results, or just extra sensors that happen to be attached).

There are some PLCs powerful enough to run Linux, though, like these: https://www.bachmann.info/en/products/controller-system/  Some industrial applications can afford to use them, and so can the shipping industry, as I learned a couple of years ago on a certain consulting gig… and so they can afford to use Qt too, just for network comms, even though there is no GUI.


From jani.heikkinen at qt.io  Tue Aug 29 12:04:54 2017
From: jani.heikkinen at qt.io (Jani Heikkinen)
Date: Tue, 29 Aug 2017 10:04:54 +0000
Subject: [Development] Maintainers,
 your actions needed: Change files for Qt 5.6.3
In-Reply-To: <c875994d-a31e-7eac-7e14-f6ae47de66bd@iseg-hv.de>
References: <HE1PR02MB313245A61F337ABC985752A09D9F0@HE1PR02MB3132.eurprd02.prod.outlook.com>
	<c875994d-a31e-7eac-7e14-f6ae47de66bd@iseg-hv.de>
Message-ID: <HE1PR02MB31324BEC0AB264FD7106FDFA9D9F0@HE1PR02MB3132.eurprd02.prod.outlook.com>

> -----Original Message-----
> From: André Hartmann [mailto:andre.hartmann at iseg-hv.de]
> Sent: tiistai 29. elokuuta 2017 9.25
> To: Jani Heikkinen <jani.heikkinen at qt.io>; development at qt-project.org
> Subject: Re: [Development] Maintainers, your actions needed: Change files
> for Qt 5.6.3
> 
> Hi Jani,
> 
> I have some comments to the change file process:
> 
> 1. The commit message is "Add change file for Qt 5.6.3" but it should be
>     "Add changes file for Qt 5.6.3" (plural)

True, let's be more exact at next time

>2. In the last releases, this initial version was WIP, so the maintainer
>     needed to adjust the message so it could be merged. I think this is
>     useful.

There were also opposite comments earlier about this ;) But both is OK for us; I don't see that big difference there...


> 3. How about projects with no changes between 5.6.2 and 5.6.3
>     (like qtserialbus)? Usually there is also a changes file with a line
>     "No relevant changes in this release", but right now there is no file
>     a all.
Yes, this is a mistake. We try to do one for all but qtserialbus was ignored because of some reason. It is now done.

> 
> I know it is some effort for the release team to create these templates, but
> with good templates you get consistent final files for the whole project.

True, and I think we need to improve this somehow in the future. I think we should discuss this in contributor summit

- Jani
> 
> Best regards,
> André
> 
> Am 29.08.2017 um 06:53 schrieb Jani Heikkinen:
> > Hi all,
> >
> > We have now created initial change files for Qt 5.6.3. Please do
> > needed modifications immediately and get '+2' as soon as possible. We
> > need to get these in to be able to proceed with Qt 5.6.3 release. You
> > can find all open change files for Qt 5.6.3 here:
> > https://codereview.qt-
> project.org/#/q/branch:5.9+status:open+message:%
> > 22Add+change+file%22,n,z
> >
> > After approval those change files will be direct pushed in '5.9',
> > cherry picked in '5.6.3' and finally direct pushed there, see
> > http://lists.qt-project.org/pipermail/development/2017-August/030722.h
> > tml
> >
> > br,
> > Jani Heikkinen
> > Release Manager
> >
> >
> > _______________________________________________
> > Development mailing list
> > Development at qt-project.org
> > http://lists.qt-project.org/mailman/listinfo/development
> >
> >
> 
> 
> --
> Best regards / Mit freundlichen Grüßen
> André Hartmann, Dipl.-Ing. (FH)
> Software Project Manager
> 
> iseg Spezialelektronik GmbH         |  phone: ++49 (0)351 26996-43
> Bautzner Landstr. 23                |  fax:   ++49 (0)351 26996-21
> D-01454 Radeberg / Rossendorf       |  web:   www.iseg-hv.com
> 
> Geschäftsführer / Managing director: Dr. F. Gleisberg, Dr. J. Pöthig
> Amtsgericht / Lower district court: Dresden HRB 16250 Ust.-Id.-Nr. / VAT-ID:
> DE812508942
> 
> 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 delete this e-mail.
> Any unauthorized copying, disclosure or distribution of the material in this e-
> mail is strictly forbidden.

From alexander.blasche at qt.io  Tue Aug 29 13:18:02 2017
From: alexander.blasche at qt.io (Alex Blasche)
Date: Tue, 29 Aug 2017 11:18:02 +0000
Subject: [Development] QLowEnergyController and obsolete ctor
In-Reply-To: <2891099.FvB2LfqEYr@lapi.koller>
References: <2891099.FvB2LfqEYr@lapi.koller>
Message-ID: <DB4PR02MB02857E5FA9DAF6597CDA397BE79F0@DB4PR02MB0285.eurprd02.prod.outlook.com>

Hi Martin,

> -----Original Message-----
> From: Development [mailto:development-
> bounces+alexander.blasche=qt.io at qt-project.org] On Behalf Of Martin Koller

> In Qt 5.9 I find that the following ctor is marked as obsolete:
> 
>     explicit QLowEnergyController(const QBluetoothAddress &remoteDevice,
>                                   const QBluetoothAddress &localDevice,
>                                   QObject *parent = Q_NULLPTR); // TODO Qt 6 remove ctor
> 
> but there is no other way to create a QLowEnergyController which does not use
> the local default adapter.
> 
> How is this supposed to work ?

The ctor still exists and works. You can use it for Bluetooth Central use cases. Having two local adapters is a very rare use case and only supported when using Bluez. That's why it has moved to obsolete. The fix would be to overload QLEController::createCentral(). Could you file a bug for it and assign it to me?

--
Alex


From christian.kandeler at qt.io  Tue Aug 29 13:37:09 2017
From: christian.kandeler at qt.io (Christian Kandeler)
Date: Tue, 29 Aug 2017 13:37:09 +0200
Subject: [Development] QLowEnergyController and obsolete ctor
In-Reply-To: <DB4PR02MB02857E5FA9DAF6597CDA397BE79F0@DB4PR02MB0285.eurprd02.prod.outlook.com>
References: <2891099.FvB2LfqEYr@lapi.koller>
	<DB4PR02MB02857E5FA9DAF6597CDA397BE79F0@DB4PR02MB0285.eurprd02.prod.outlook.com>
Message-ID: <20170829133709.48733173@ckandeler-archlinux>

On Tue, 29 Aug 2017 11:18:02 +0000
Alex Blasche <alexander.blasche at qt.io> wrote:

> Hi Martin,
> 
> > -----Original Message-----
> > From: Development [mailto:development-
> > bounces+alexander.blasche=qt.io at qt-project.org] On Behalf Of Martin Koller  
> 
> > In Qt 5.9 I find that the following ctor is marked as obsolete:
> > 
> >     explicit QLowEnergyController(const QBluetoothAddress &remoteDevice,
> >                                   const QBluetoothAddress &localDevice,
> >                                   QObject *parent = Q_NULLPTR); // TODO Qt 6 remove ctor
> > 
> > but there is no other way to create a QLowEnergyController which does not use
> > the local default adapter.
> > 
> > How is this supposed to work ?  
> 
> The ctor still exists and works. You can use it for Bluetooth Central use cases. Having two local adapters is a very rare use case and only supported when using Bluez. That's why it has moved to obsolete. The fix would be to overload QLEController::createCentral(). Could you file a bug for it and assign it to me?

Real-world example use case: My laptop has a built-in Bluetooth controller that is not LE-capable. When I plug in a USB-based LE controller, it appears to be non-deterministic which of the two devices becomes the default one. So in order to do BLE stuff on that machine, I need to use that constructor.


Christian


From thiago.macieira at intel.com  Tue Aug 29 17:43:40 2017
From: thiago.macieira at intel.com (Thiago Macieira)
Date: Tue, 29 Aug 2017 08:43:40 -0700
Subject: [Development] Qt and IoT infographic
In-Reply-To: <AM4PR02MB3249886B4E6450751FA2D366879F0@AM4PR02MB3249.eurprd02.prod.outlook.com>
References: <1692398.lzVxuX8aJu@tjmaciei-mobl1>
	<CAE1uMrVab8i1_MxLTa9kFpgO+-a-3XMZwPC=EmpQoiK5VLmDDA@mail.gmail.com>
	<AM4PR02MB3249886B4E6450751FA2D366879F0@AM4PR02MB3249.eurprd02.prod.outlook.com>
Message-ID: <8312967.glRrcCu1Oc@tjmaciei-mobl1>

On Tuesday, 29 August 2017 01:44:34 PDT Edward Welbourne wrote:
> Thiago:
> >> If you're going to communicate with a tiny MCU connected over a mesh
> >> network like 6LoWPAN/Thread, you won't be using TCP. Much less HTTP.
> 
> and you'll want that MCU running something light-weight in C++, not a
> web-bloat thing.  So Qt is just the thing for the job.
> 
> (... and I had to google MCU - microcontroller unit, not Marvel Comic
> Universe ;^)

Actually, no, you're not going to run Qt on an MCU with less than 256 kB of 
RAM and less than 1 MB of Flash.

But in fact you *can* run JavaScript and Node.js-like code. See 
	https://github.com/01org/zephyr.js/blob/master/docs/API.md
	https://github.com/Samsung/iotjs
Both implemented using https://github.com/jerryscript-project/jerryscript

Zephyr.js runs on the Arduino 101 (24 kB RAM), provided you give slightly more 
than 128 kB Flash to the x86 MCU on the device.

Below 128 kB Flash, it's very hard to run the OS, your application and a TCP 
stack (unless you have some hardware offload). So you'll be looking at UDP from 
this point downward.

My point wasn't to run Qt *on* them, but use Qt to communicate *with* them.

> We are aware of it [*] and looking at what to do.
> We are, however, short of hands and up to our necks in things to do.
> 
> [*] https://wiki.qt.io/Qt_Network_Workshop_2016#IoT

Note how mDNS is there, DTLS, etc. I mentioned CoAP during the workshop but 
mentioned that it wasn't necessary to implement in Qt because it was so 
simple.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center



From thiago.macieira at intel.com  Tue Aug 29 18:00:36 2017
From: thiago.macieira at intel.com (Thiago Macieira)
Date: Tue, 29 Aug 2017 09:00:36 -0700
Subject: [Development] Qt and IoT infographic
In-Reply-To: <07BE9501-B980-4593-B72C-98E7234E61B2@qt.io>
References: <1692398.lzVxuX8aJu@tjmaciei-mobl1>
	<AM4PR02MB3249886B4E6450751FA2D366879F0@AM4PR02MB3249.eurprd02.prod.outlook.com>
	<07BE9501-B980-4593-B72C-98E7234E61B2@qt.io>
Message-ID: <1512005.VXTWK0GkGM@tjmaciei-mobl1>

On Tuesday, 29 August 2017 02:43:44 PDT Shawn Rutledge wrote:
> And yet it has a web server for serving up either a human-readable page or
> JSON on demand, and it also pushes data to a central server periodically.

Is that a static JSON? Because if you need to compose the data on the fly, you 
may also want to replace JSON with something simpler. See 
	https://github.com/01org/tinycbor/

You'll find that the maintainer is familiar :-)

As for the part about "pushes data to a central server", I hope it's a server 
on the local network, not on the Cloud.

> After
> reading about CoAP I think it would be a much better fit than HTTP for such
> a device, so I hope I find the time to try.  But then again, browsers don’t
> have CoAP yet, so I wonder if there could be a web client that uses JS to
> talk to it.  Having to build a dedicated Qt client for it would be a step
> backwards in a way, but also nice for a desktop widget or some such.

Firefox has a CoAP addon.
https://addons.mozilla.org/en-US/firefox/addon/copper-270430/

As for Chrome, I'll cat with Alexis and see what he thinks about the chances 
of adding it by default to the browser.
 
> Qt for IoT is maybe primarily for devices that have graphically-rich
> screens.  But they can be clients reading data from truly-embedded sensors,
> and they might also have data of their own to serve to other clients
> (consolidated results, or just extra sensors that happen to be attached).

Good point on the data of their own.

I really do think we need to reevaluate our position that Qt is for clients 
only. I'm not against the HTTP server stack. I'm just saying it's a much more 
complex beast. And unlike the server that serves a single page, any Qt 
solution that makes to API would need to be a lot more capable.

Otherwise, just lift the MiniHttpServer from the many unit tests.

> There are some PLCs powerful enough to run Linux, though, like these:
> https://www.bachmann.info/en/products/controller-system/  Some industrial
> applications can afford to use them, and so can the shipping industry, as I
> learned a couple of years ago on a certain consulting gig… and so they can
> afford to use Qt too, just for network comms, even though there is no GUI.

Intel has shown that Linux is a viable target at 2 MB of RAM. We can boot a 
kernel at 1 MB, but then there's nothing left for your application. Shrinking 
the kernel further is possible, but it depends on whether the upstream would 
accept such changes -- for example, disabling TCP and leaving only UDP 
enabled. The kernel network maintainers currently have the position that they 
don't want this and you should just switch to a microcontroller RTOS at that 
point.

For Qt, we have to make sure it runs comfortably at 128 MB and we should 
strive to make it possible for 32 MB of RAM.

But the question is whether this is worth the effort. Are there devices that 
have memory in this range? One anecdote I've heard is that you can't buy DRAM 
at less than 512 MB -- since there's just not enough volume for them, their 
prices went up, causing people to stop buying them, further causing the prices 
to go up...

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center



From thiago.macieira at intel.com  Tue Aug 29 17:30:56 2017
From: thiago.macieira at intel.com (Thiago Macieira)
Date: Tue, 29 Aug 2017 08:30:56 -0700
Subject: [Development] [fix]: Assistant (and others) burning CPU because
 of #f27d1ccbb24ec2fd4098f2976503478831006cc8 ?
In-Reply-To: <2016136.MCHlo2iGPk@bola>
References: <1600335.9fNCGNT7fm@portia.local>
	<256B709E-1A47-47C1-92A5-DCF598705496@qt.io>
	<2016136.MCHlo2iGPk@bola>
Message-ID: <9009568.Ri8CIgFy91@tjmaciei-mobl1>

On Tuesday, 29 August 2017 01:10:53 PDT René J.V. Bertin wrote:
> Which we just rediscovered :) Funny though, apparently 1 misdirected
> startTimer() call can turn any application in a CPU hog that burns cycles
> without ever doing anything. Wouldn't it be safer for QObject::timerEvent()
> to kill any timer that triggers it, possibly even do an abort if it can do
> some kind of runtime debug mode detection? At least then it's set to a 0
> (zero) interval?

Sure. Please tell that to Eirik and Håvard back in the early 90s when they're 
designing Qt. 
	http://doc.qt.io/archives/2.3/qobject.html#4c6b67
	(Qt 1 docs not online)

Unfortunately, we can't change anymore.

> It took me an unreasonable amount of time trying to figure out the reason
> for the burning, the fact that QCocoaMenu::timerEvent() could be being
> called as fast as possible and for nothing occurred to me only after trying
> all other possibilities. And I knew only the timer change could be the
> culprit; I can only imagine how much more time I'd have spent if this bug
> had been latent for a few months.

i'm glad you found it.

How did you?

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center



From jhihn at gmx.com  Tue Aug 29 18:53:14 2017
From: jhihn at gmx.com (Jason H)
Date: Tue, 29 Aug 2017 18:53:14 +0200
Subject: [Development] Qt and IoT infographic
In-Reply-To: <CAE1uMrVab8i1_MxLTa9kFpgO+-a-3XMZwPC=EmpQoiK5VLmDDA@mail.gmail.com>
References: <1692398.lzVxuX8aJu@tjmaciei-mobl1>
	<2364421.jUIFWPXPns@tjmaciei-mobl1>
	<trinity-8355173d-64ca-4588-955d-14fc86d4811f-1503948415322@3c-app-mailcom-bs15>
	<17696992.PPTgx0HhA3@tjmaciei-mobl1>
	<CAE1uMrVab8i1_MxLTa9kFpgO+-a-3XMZwPC=EmpQoiK5VLmDDA@mail.gmail.com>
Message-ID: <trinity-5be8a9d3-2693-415d-803f-938f4341e792-1504025594434@3c-app-mailcom-bs15>

An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20170829/75841d38/attachment.html>

From jhihn at gmx.com  Tue Aug 29 19:35:05 2017
From: jhihn at gmx.com (Jason H)
Date: Tue, 29 Aug 2017 19:35:05 +0200
Subject: [Development] Qt and IoT infographic
In-Reply-To: <1512005.VXTWK0GkGM@tjmaciei-mobl1>
References: <1692398.lzVxuX8aJu@tjmaciei-mobl1>
	<AM4PR02MB3249886B4E6450751FA2D366879F0@AM4PR02MB3249.eurprd02.prod.outlook.com>
	<07BE9501-B980-4593-B72C-98E7234E61B2@qt.io>
	<1512005.VXTWK0GkGM@tjmaciei-mobl1>
Message-ID: <trinity-06c7ea5a-b708-447d-959e-a9705fc62499-1504028105151@3c-app-mailcom-bs15>



> Sent: Tuesday, August 29, 2017 at 12:00 PM
> From: "Thiago Macieira" <thiago.macieira at intel.com>
> To: development at qt-project.org
> Subject: Re: [Development] Qt and IoT infographic
>
> On Tuesday, 29 August 2017 02:43:44 PDT Shawn Rutledge wrote:
> > And yet it has a web server for serving up either a human-readable page or
> > JSON on demand, and it also pushes data to a central server periodically.
> 
> Is that a static JSON? Because if you need to compose the data on the fly, you 
> may also want to replace JSON with something simpler. See 
> 	https://github.com/01org/tinycbor/
> 
> You'll find that the maintainer is familiar :-)
> 
> As for the part about "pushes data to a central server", I hope it's a server 
> on the local network, not on the Cloud.
> 
> > After
> > reading about CoAP I think it would be a much better fit than HTTP for such
> > a device, so I hope I find the time to try.  But then again, browsers don’t
> > have CoAP yet, so I wonder if there could be a web client that uses JS to
> > talk to it.  Having to build a dedicated Qt client for it would be a step
> > backwards in a way, but also nice for a desktop widget or some such.
> 
> Firefox has a CoAP addon.
> https://addons.mozilla.org/en-US/firefox/addon/copper-270430/
> 
> As for Chrome, I'll cat with Alexis and see what he thinks about the chances 
> of adding it by default to the browser.


I think the ideal tech solution here is not to do one or the other, rather both, in a layered approach. Use the HTTP/REST and provide a translation layer to CoAP. They make a statement about it being really close, so it shouldn't be that hard to proxy down/up to a full-on REST server?


> > Qt for IoT is maybe primarily for devices that have graphically-rich
> > screens.  But they can be clients reading data from truly-embedded sensors,
> > and they might also have data of their own to serve to other clients
> > (consolidated results, or just extra sensors that happen to be attached).
> 
> Good point on the data of their own.
> 
> I really do think we need to reevaluate our position that Qt is for clients 
> only. I'm not against the HTTP server stack. I'm just saying it's a much more 
> complex beast. And unlike the server that serves a single page, any Qt 
> solution that makes to API would need to be a lot more capable.
> 
> Otherwise, just lift the MiniHttpServer from the many unit tests.

I'm not saying re-write apache or node anything like that. (Although node libraries in QML would be great!) I'm only suggesting that we make Qt able to trivially provide data to the web in both a conceptually easy and easy to implement way.

No where could this be easier than with QML 
HttpServer {
port: 80

    // C++ QObject with Q_PROPERTIES: ["temperature", "cores", ...etc] automatically mapping Q_PROPERTY READ/WRITE methods as GET/POST respectively
    CpuSensor {
        id: cpu 
        onTemperatureChanged: { /*alarm if over 100, etc */ }
    }

    ObjectRequestMapper {
       url: '/cpu'
       object: cpu
    }

}
GET /cpu/temperature
GET /cpu/cores

As well as with a simple QObject tree

> > There are some PLCs powerful enough to run Linux, though, like these:
> > https://www.bachmann.info/en/products/controller-system/  Some industrial
> > applications can afford to use them, and so can the shipping industry, as I
> > learned a couple of years ago on a certain consulting gig… and so they can
> > afford to use Qt too, just for network comms, even though there is no GUI.
> 
> Intel has shown that Linux is a viable target at 2 MB of RAM. We can boot a 
> kernel at 1 MB, but then there's nothing left for your application. Shrinking 
> the kernel further is possible, but it depends on whether the upstream would 
> accept such changes -- for example, disabling TCP and leaving only UDP 
> enabled. The kernel network maintainers currently have the position that they 
> don't want this and you should just switch to a microcontroller RTOS at that 
> point.
> 
> For Qt, we have to make sure it runs comfortably at 128 MB and we should 
> strive to make it possible for 32 MB of RAM.
> 
> But the question is whether this is worth the effort. Are there devices that 
> have memory in this range? One anecdote I've heard is that you can't buy DRAM 
> at less than 512 MB -- since there's just not enough volume for them, their 
> prices went up, causing people to stop buying them, further causing the prices 
> to go up...

There is a pretty big gulf between MCUs and the IoT. 
Yeah, I've got Aurduino (even a uCSimm), various Pis and BeagleBoards, but with the Pi Zero at $5, it's the same price as an Arduino, and it runs Qt no problem. The calculus that has to be made is if IoT will be in quantities where costing < $5 but more than pennies will inhibit a market. I think IoT is not currently suffering from that as most IoT things I think of are luxury projects where a $5 CPU isn't cost prohibitive. Meanwhile, you've got the whole Moore's law thing going on. If it takes Qt 3 years to whittle down to fit on a board, or just quadruple the resources, then it's a wash. I don't see Qt reaching down much lower than a Raspberry Pi Zero. The future of IoT development isn't reaching down, its gluing things together with a minimal level of effort while prices on the more advanced stuff plummet and capabilities increase. There maybe a market for a lower-end CPUs reaching into the MCU space, but I just don't see Qt going there.




From annulen at yandex.ru  Tue Aug 29 20:50:27 2017
From: annulen at yandex.ru (Konstantin Tokarev)
Date: Tue, 29 Aug 2017 21:50:27 +0300
Subject: [Development] Qt and IoT infographic
In-Reply-To: <1512005.VXTWK0GkGM@tjmaciei-mobl1>
References: <1692398.lzVxuX8aJu@tjmaciei-mobl1>
	<AM4PR02MB3249886B4E6450751FA2D366879F0@AM4PR02MB3249.eurprd02.prod.outlook.com>
	<07BE9501-B980-4593-B72C-98E7234E61B2@qt.io>
	<1512005.VXTWK0GkGM@tjmaciei-mobl1>
Message-ID: <1932971504032627@web8g.yandex.ru>



29.08.2017, 19:00, "Thiago Macieira" <thiago.macieira at intel.com>:
> On Tuesday, 29 August 2017 02:43:44 PDT Shawn Rutledge wrote:
>>  And yet it has a web server for serving up either a human-readable page or
>>  JSON on demand, and it also pushes data to a central server periodically.
>
> Is that a static JSON? Because if you need to compose the data on the fly, you
> may also want to replace JSON with something simpler. See
>         https://github.com/01org/tinycbor/

This pesky people like to look up replies from their URLs in their browsers, so they
want HTTP and text-based serialization.

>
> You'll find that the maintainer is familiar :-)
>
> As for the part about "pushes data to a central server", I hope it's a server
> on the local network, not on the Cloud.
>
>>  After
>>  reading about CoAP I think it would be a much better fit than HTTP for such
>>  a device, so I hope I find the time to try. But then again, browsers don’t
>>  have CoAP yet, so I wonder if there could be a web client that uses JS to
>>  talk to it. Having to build a dedicated Qt client for it would be a step
>>  backwards in a way, but also nice for a desktop widget or some such.
>
> Firefox has a CoAP addon.
> https://addons.mozilla.org/en-US/firefox/addon/copper-270430/
>
> As for Chrome, I'll cat with Alexis and see what he thinks about the chances
> of adding it by default to the browser.
>
>>  Qt for IoT is maybe primarily for devices that have graphically-rich
>>  screens. But they can be clients reading data from truly-embedded sensors,
>>  and they might also have data of their own to serve to other clients
>>  (consolidated results, or just extra sensors that happen to be attached).
>
> Good point on the data of their own.
>
> I really do think we need to reevaluate our position that Qt is for clients
> only. I'm not against the HTTP server stack. I'm just saying it's a much more
> complex beast. And unlike the server that serves a single page, any Qt
> solution that makes to API would need to be a lot more capable.
>
> Otherwise, just lift the MiniHttpServer from the many unit tests.
>
>>  There are some PLCs powerful enough to run Linux, though, like these:
>>  https://www.bachmann.info/en/products/controller-system/ Some industrial
>>  applications can afford to use them, and so can the shipping industry, as I
>>  learned a couple of years ago on a certain consulting gig… and so they can
>>  afford to use Qt too, just for network comms, even though there is no GUI.
>
> Intel has shown that Linux is a viable target at 2 MB of RAM. We can boot a
> kernel at 1 MB, but then there's nothing left for your application. Shrinking
> the kernel further is possible, but it depends on whether the upstream would
> accept such changes -- for example, disabling TCP and leaving only UDP
> enabled. The kernel network maintainers currently have the position that they
> don't want this and you should just switch to a microcontroller RTOS at that
> point.
>
> For Qt, we have to make sure it runs comfortably at 128 MB and we should
> strive to make it possible for 32 MB of RAM.
>
> But the question is whether this is worth the effort. Are there devices that
> have memory in this range? One anecdote I've heard is that you can't buy DRAM
> at less than 512 MB -- since there's just not enough volume for them, their
> prices went up, causing people to stop buying them, further causing the prices
> to go up...
>
> --
> 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

-- 
Regards,
Konstantin


From thiago.macieira at intel.com  Tue Aug 29 21:05:00 2017
From: thiago.macieira at intel.com (Thiago Macieira)
Date: Tue, 29 Aug 2017 12:05:00 -0700
Subject: [Development] Qt and IoT infographic
In-Reply-To: <trinity-06c7ea5a-b708-447d-959e-a9705fc62499-1504028105151@3c-app-mailcom-bs15>
References: <1692398.lzVxuX8aJu@tjmaciei-mobl1>
	<1512005.VXTWK0GkGM@tjmaciei-mobl1>
	<trinity-06c7ea5a-b708-447d-959e-a9705fc62499-1504028105151@3c-app-mailcom-bs15>
Message-ID: <5154256.3fEKKNXxgl@tjmaciei-mobl1>

On Tuesday, 29 August 2017 10:35:05 PDT Jason H wrote:
> I think the ideal tech solution here is not to do one or the other, rather
> both, in a layered approach. Use the HTTP/REST and provide a translation
> layer to CoAP. They make a statement about it being really close, so it
> shouldn't be that hard to proxy down/up to a full-on REST server?

My colleagues in Intel Finland already have that. Using Node.js though.

> I'm not saying re-write apache or node anything like that. (Although node
> libraries in QML would be great!) I'm only suggesting that we make Qt able
> to trivially provide data to the web in both a conceptually easy and easy
> to implement way.

FamousLastWords™

> There is a pretty big gulf between MCUs and the IoT.
> Yeah, I've got Aurduino (even a uCSimm), various Pis and BeagleBoards, but
> with the Pi Zero at $5, it's the same price as an Arduino, and it runs Qt
> no problem.

Research shows NO ONE deploys Arduino for real products. It's a maker toy, 
stuff hobbyists use to make one-off things and some professional makers use 
for initial prototyping. When they get serious, Arduino goes out the window 
and they get real boards.

The Pi Zero doesn't cost *you* $5 if you want to make modifications. It costs 
$5 only due to the volume discount of the seller. If you want to modify the 
board, like for example depopulate it and remove some things you don't need, 
your price may actually rise instead of going down.

> The calculus that has to be made is if IoT will be in
> quantities where costing < $5 but more than pennies will inhibit a market.

I think it will. I think we'll see on smart devices's "smartness" costing 
$0.50. But those are the tiny MCUs we've been talking about.

The gap between those and the 512-MB devices is huge.

> I think IoT is not currently suffering from that as most IoT things I think
> of are luxury projects where a $5 CPU isn't cost prohibitive. Meanwhile,
> you've got the whole Moore's law thing going on. If it takes Qt 3 years to
> whittle down to fit on a board, or just quadruple the resources, then it's
> a wash. I don't see Qt reaching down much lower than a Raspberry Pi Zero.

Agreed, I don't see it reaching much lower than that either. Like I said, I 
think 32 MB RAM and 1 GB storage is a reasonable, albeit already difficult 
target.

But I don't see the power of the devices going up. Instead, we'll see the 
other effect of Moore's Law: the price for the same capacity go down. So what 
costs $0.50 today will cost $0.125 in 3 years.

> The future of IoT development isn't reaching down, its gluing things
> together with a minimal level of effort while prices on the more advanced
> stuff plummet and capabilities increase. There maybe a market for a
> lower-end CPUs reaching into the MCU space, but I just don't see Qt going
> there.

Right. I don't think Qt needs to run on the MCU space.

Qt needs to *consume* the data provided by the MCUs. And yes, it needs to 
provide data for larger integration.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center



From jeanmichael.celerier at gmail.com  Tue Aug 29 21:41:25 2017
From: jeanmichael.celerier at gmail.com (=?UTF-8?Q?Jean=2DMicha=C3=ABl_Celerier?=)
Date: Tue, 29 Aug 2017 21:41:25 +0200
Subject: [Development] Qt and IoT infographic
In-Reply-To: <5154256.3fEKKNXxgl@tjmaciei-mobl1>
References: <1692398.lzVxuX8aJu@tjmaciei-mobl1>
	<1512005.VXTWK0GkGM@tjmaciei-mobl1>
	<trinity-06c7ea5a-b708-447d-959e-a9705fc62499-1504028105151@3c-app-mailcom-bs15>
	<5154256.3fEKKNXxgl@tjmaciei-mobl1>
Message-ID: <CAE1uMrWJTsMvMM9=BJtOZ+Yh=6ntKBrU3_2aak+=946ovUs-kw@mail.gmail.com>

> Research shows NO ONE deploys Arduino for real products. It's a maker toy,
stuff hobbyists use to make one-off things and some professional makers use
for initial prototyping. When they get serious, Arduino goes out the window
and they get real boards.

Sure, but if you can't start prototyping with Qt there's not much chance
you're going to switch to Qt when your prototype is running and you have to
start working towards the actual product.

Besides, this comes a bit as disdainful. I work in music research and
*everything* embedded uses Arduinos, Pi, Beaglebones or similar. If you
have seen interactive artistic installations in museums, outdoor
expositions, or contemporary concerts, there is a huge chance there's a Pi
or an Arduino running somewhere. Sure, there aren't "products" that end up
produced thousand times and sold on the counter or at Moser, but they are
shows, expositions, etc. which generate revenue all the same, for the
artists, museums, etc. and need programmers to get the stuff running and
banging sound.



-------
Jean-Michaël Celerier
http://www.jcelerier.name

On Tue, Aug 29, 2017 at 9:05 PM, Thiago Macieira <thiago.macieira at intel.com>
wrote:

> On Tuesday, 29 August 2017 10:35:05 PDT Jason H wrote:
> > I think the ideal tech solution here is not to do one or the other,
> rather
> > both, in a layered approach. Use the HTTP/REST and provide a translation
> > layer to CoAP. They make a statement about it being really close, so it
> > shouldn't be that hard to proxy down/up to a full-on REST server?
>
> My colleagues in Intel Finland already have that. Using Node.js though.
>
> > I'm not saying re-write apache or node anything like that. (Although node
> > libraries in QML would be great!) I'm only suggesting that we make Qt
> able
> > to trivially provide data to the web in both a conceptually easy and easy
> > to implement way.
>
> FamousLastWords™
>
> > There is a pretty big gulf between MCUs and the IoT.
> > Yeah, I've got Aurduino (even a uCSimm), various Pis and BeagleBoards,
> but
> > with the Pi Zero at $5, it's the same price as an Arduino, and it runs Qt
> > no problem.
>
> Research shows NO ONE deploys Arduino for real products. It's a maker toy,
> stuff hobbyists use to make one-off things and some professional makers use
> for initial prototyping. When they get serious, Arduino goes out the window
> and they get real boards.
>
> The Pi Zero doesn't cost *you* $5 if you want to make modifications. It
> costs
> $5 only due to the volume discount of the seller. If you want to modify the
> board, like for example depopulate it and remove some things you don't
> need,
> your price may actually rise instead of going down.
>
> > The calculus that has to be made is if IoT will be in
> > quantities where costing < $5 but more than pennies will inhibit a
> market.
>
> I think it will. I think we'll see on smart devices's "smartness" costing
> $0.50. But those are the tiny MCUs we've been talking about.
>
> The gap between those and the 512-MB devices is huge.
>
> > I think IoT is not currently suffering from that as most IoT things I
> think
> > of are luxury projects where a $5 CPU isn't cost prohibitive. Meanwhile,
> > you've got the whole Moore's law thing going on. If it takes Qt 3 years
> to
> > whittle down to fit on a board, or just quadruple the resources, then
> it's
> > a wash. I don't see Qt reaching down much lower than a Raspberry Pi Zero.
>
> Agreed, I don't see it reaching much lower than that either. Like I said, I
> think 32 MB RAM and 1 GB storage is a reasonable, albeit already difficult
> target.
>
> But I don't see the power of the devices going up. Instead, we'll see the
> other effect of Moore's Law: the price for the same capacity go down. So
> what
> costs $0.50 today will cost $0.125 in 3 years.
>
> > The future of IoT development isn't reaching down, its gluing things
> > together with a minimal level of effort while prices on the more advanced
> > stuff plummet and capabilities increase. There maybe a market for a
> > lower-end CPUs reaching into the MCU space, but I just don't see Qt going
> > there.
>
> Right. I don't think Qt needs to run on the MCU space.
>
> Qt needs to *consume* the data provided by the MCUs. And yes, it needs to
> provide data for larger integration.
>
> --
> 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: <http://lists.qt-project.org/pipermail/development/attachments/20170829/94df249f/attachment.html>

From thiago.macieira at intel.com  Tue Aug 29 23:07:20 2017
From: thiago.macieira at intel.com (Thiago Macieira)
Date: Tue, 29 Aug 2017 14:07:20 -0700
Subject: [Development] Qt and IoT infographic
In-Reply-To: <CAE1uMrWJTsMvMM9=BJtOZ+Yh=6ntKBrU3_2aak+=946ovUs-kw@mail.gmail.com>
References: <1692398.lzVxuX8aJu@tjmaciei-mobl1>
	<5154256.3fEKKNXxgl@tjmaciei-mobl1>
	<CAE1uMrWJTsMvMM9=BJtOZ+Yh=6ntKBrU3_2aak+=946ovUs-kw@mail.gmail.com>
Message-ID: <3123873.vLZO8E3TcY@tjmaciei-mobl1>

On Tuesday, 29 August 2017 12:41:25 PDT Jean-Michaël Celerier wrote:
> > Research shows NO ONE deploys Arduino for real products. It's a maker toy,
> > stuff hobbyists use to make one-off things and some professional makers
> > use
> > for initial prototyping. When they get serious, Arduino goes out the
> > window
> > and they get real boards.
> 
> Sure, but if you can't start prototyping with Qt there's not much chance
> you're going to switch to Qt when your prototype is running and you have to
> start working towards the actual product.

Actually, the Arduino case here is relevant. People do start with Arduino and 
then they switch to something else. So there is a precedent on rewriting.

But I do take your point.

> Besides, this comes a bit as disdainful. I work in music research and
> *everything* embedded uses Arduinos, Pi, Beaglebones or similar. If you
> have seen interactive artistic installations in museums, outdoor
> expositions, or contemporary concerts, there is a huge chance there's a Pi
> or an Arduino running somewhere. Sure, there aren't "products" that end up
> produced thousand times and sold on the counter or at Moser, but they are
> shows, expositions, etc. which generate revenue all the same, for the
> artists, museums, etc. and need programmers to get the stuff running and
> banging sound.

I was talking about production runs, where you make thousands to millions of 
exact copies. I guess I wasn't very clear about that.

For one-offs or maybe tens of copies, sure, there's a lot of Arduinos. And a 
lot of Raspberry Pis too.

For production runs, that number goes very quickly to zero.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center



From olivier at woboq.com  Wed Aug 30 09:30:05 2017
From: olivier at woboq.com (Olivier Goffart)
Date: Wed, 30 Aug 2017 09:30:05 +0200
Subject: [Development] [fix]: Assistant (and others) burning CPU because
 of #f27d1ccbb24ec2fd4098f2976503478831006cc8 ?
In-Reply-To: <9009568.Ri8CIgFy91@tjmaciei-mobl1>
References: <1600335.9fNCGNT7fm@portia.local> <2016136.MCHlo2iGPk@bola>
	<9009568.Ri8CIgFy91@tjmaciei-mobl1>
Message-ID: <2209541.uETthxIbLi@maurice>

Am Dienstag, 29. August 2017, 17:30:56 CEST schrieb Thiago Macieira:
> On Tuesday, 29 August 2017 01:10:53 PDT René J.V. Bertin wrote:
> > Which we just rediscovered :) Funny though, apparently 1 misdirected
> > startTimer() call can turn any application in a CPU hog that burns cycles
> > without ever doing anything. Wouldn't it be safer for
> > QObject::timerEvent()
> > to kill any timer that triggers it, possibly even do an abort if it can do
> > some kind of runtime debug mode detection? At least then it's set to a 0
> > (zero) interval?
> 
> Sure. Please tell that to Eirik and Håvard back in the early 90s when
> they're designing Qt.
> 	http://doc.qt.io/archives/2.3/qobject.html#4c6b67
> 	(Qt 1 docs not online)
> 
> Unfortunately, we can't change anymore.

We can change the documentation and recommend against using killTimer and 
startTimer. QBasicTimer should be used instead. This would have probably 
avoided the problem in this case (as one would have called stop instead of 
m_updateTimer = 0). And in general is easier to use for 0 overhead.

-- 
Olivier

Woboq - Qt services and support - https://woboq.com - https://code.woboq.org


From lars.knoll at qt.io  Wed Aug 30 10:06:35 2017
From: lars.knoll at qt.io (Lars Knoll)
Date: Wed, 30 Aug 2017 08:06:35 +0000
Subject: [Development] [fix]: Assistant (and others) burning CPU because
 of #f27d1ccbb24ec2fd4098f2976503478831006cc8 ?
In-Reply-To: <2209541.uETthxIbLi@maurice>
References: <1600335.9fNCGNT7fm@portia.local> <2016136.MCHlo2iGPk@bola>
	<9009568.Ri8CIgFy91@tjmaciei-mobl1> <2209541.uETthxIbLi@maurice>
Message-ID: <E5D30A95-0DA4-496D-838E-D08A3D0BDB2D@qt.io>


On 30 Aug 2017, at 09:30, Olivier Goffart <olivier at woboq.com<mailto:olivier at woboq.com>> wrote:

Am Dienstag, 29. August 2017, 17:30:56 CEST schrieb Thiago Macieira:
On Tuesday, 29 August 2017 01:10:53 PDT René J.V. Bertin wrote:
Which we just rediscovered :) Funny though, apparently 1 misdirected
startTimer() call can turn any application in a CPU hog that burns cycles
without ever doing anything. Wouldn't it be safer for
QObject::timerEvent()
to kill any timer that triggers it, possibly even do an abort if it can do
some kind of runtime debug mode detection? At least then it's set to a 0
(zero) interval?

Sure. Please tell that to Eirik and Håvard back in the early 90s when
they're designing Qt.
http://doc.qt.io/archives/2.3/qobject.html#4c6b67
(Qt 1 docs not online)

Unfortunately, we can't change anymore.

We can change the documentation and recommend against using killTimer and
startTimer. QBasicTimer should be used instead. This would have probably
avoided the problem in this case (as one would have called stop instead of
m_updateTimer = 0). And in general is easier to use for 0 overhead.

+1. Maybe even deprecate startTimer and killTimer?

Cheers,
Lars

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20170830/ce6de22c/attachment.html>

From philwave at gmail.com  Wed Aug 30 10:22:51 2017
From: philwave at gmail.com (Philippe)
Date: Wed, 30 Aug 2017 10:22:51 +0200
Subject: [Development] [fix]: Assistant (and others) burning CPU because
 of #f27d1ccbb24ec2fd4098f2976503478831006cc8 ?
In-Reply-To: <E5D30A95-0DA4-496D-838E-D08A3D0BDB2D@qt.io>
References: <2209541.uETthxIbLi@maurice>
	<E5D30A95-0DA4-496D-838E-D08A3D0BDB2D@qt.io>
Message-ID: <20170830102250.E84C.6F0322A@gmail.com>

Maybe even deprecate startTimer and killTimer?

-1

I like this low level insight, which gives me a higher sense of control about what's going on.

Philippe

On Wed, 30 Aug 2017 08:06:35 +0000
Lars Knoll <lars.knoll at qt.io> wrote:


>> On 30 Aug 2017, at 09:30, Olivier Goffart <olivier at woboq.com> wrote:
>> 
>> Am Dienstag, 29. August 2017, 17:30:56 CEST schrieb Thiago Macieira:
>> On Tuesday, 29 August 2017 01:10:53 PDT René J.V. Bertin wrote:
>>> Which we just rediscovered :) Funny though, apparently 1 misdirected
>>>> startTimer() call can turn any application in a CPU hog that burns cycles
>>>> without ever doing anything. Wouldn't it be safer for
>>>> QObject::timerEvent()
>>>> to kill any timer that triggers it, possibly even do an abort if it can do
>>>> some kind of runtime debug mode detection? At least then it's set to a 0
>>>> (zero) interval?

Sure. Please tell that to Eirik and Håvard back in the early 90s when
they're designing Qt.
http://doc.qt.io/archives/2.3/qobject.html#4c6b67
(Qt 1 docs not online)

Unfortunately, we can't change anymore.

We can change the documentation and recommend against using killTimer and 
startTimer. QBasicTimer should be used instead. This would have probably 
avoided the problem in this case (as one would have called stop instead of 
m_updateTimer = 0). And in general is easier to use for 0 overhead.



+1. Maybe even deprecate startTimer and killTimer?


Cheers,
Lars



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20170830/db30195b/attachment.html>

From edward.welbourne at qt.io  Wed Aug 30 10:29:50 2017
From: edward.welbourne at qt.io (Edward Welbourne)
Date: Wed, 30 Aug 2017 08:29:50 +0000
Subject: [Development] Qt and IoT infographic
In-Reply-To: <3123873.vLZO8E3TcY@tjmaciei-mobl1>
References: <1692398.lzVxuX8aJu@tjmaciei-mobl1>
	<5154256.3fEKKNXxgl@tjmaciei-mobl1>
	<CAE1uMrWJTsMvMM9=BJtOZ+Yh=6ntKBrU3_2aak+=946ovUs-kw@mail.gmail.com>,
	<3123873.vLZO8E3TcY@tjmaciei-mobl1>
Message-ID: <AM4PR02MB32497E4821935F609786745B879C0@AM4PR02MB3249.eurprd02.prod.outlook.com>

Thiago Macieira (earlier):
>>> Research shows NO ONE deploys Arduino for real products. It's a
>>> maker toy, stuff hobbyists use to make one-off things and some
>>> professional makers use for initial prototyping. When they get
>>> serious, Arduino goes out the window and they get real boards.
[...]
On Tuesday, 29 August 2017 12:41:25 PDT Jean-Michaël Celerier wrote:
[...]
>> Besides, this comes a bit as disdainful. I work in music research and
>> *everything* embedded uses Arduinos, Pi, Beaglebones or similar. If you
>> have seen interactive artistic installations in museums, outdoor
>> expositions, or contemporary concerts, there is a huge chance there's a Pi
>> or an Arduino running somewhere. Sure, there aren't "products" that end up
>> produced thousand times and sold on the counter or at Moser, but they are
>> shows, expositions, etc. which generate revenue all the same, for the
>> artists, museums, etc. and need programmers to get the stuff running and
>> banging sound.

Thiago Macieira 29 August 2017 23:07:
> I was talking about production runs, where you make thousands to millions of
> exact copies. I guess I wasn't very clear about that.

No, you were clear; and Jean-Michaël got it - he's clearly aware of that
(fourth sentence).

> For one-offs or maybe tens of copies, sure, there's a lot of Arduinos. And a
> lot of Raspberry Pis too.
>
> For production runs, that number goes very quickly to zero.

While the number of Pis or Arduinos goes to zero, the product prototyped
on them could well use Qt; and, if that gives significant benefits
compared to something more bare-bones (the most the available developer
resources can put together in raw C++ or C, without a rich tool-kit to
save them most of the work), it may serve as a motivator to pay the
extra dollar or three to have something capable of carrying (a
sufficient) Qt-Lite.  So, while the final product might not be Arduino
or Pi, the availability of Qt on those platforms may increase the uptake
of Qt in final products, for all that those are on some more
stripped-down device.

Still, indeed, Qt's strengths are a better fit to the system to which
the device ends up talking - albeit, I'm afraid, IoT standard practice
is for that to go via the manufacturer's privacy-busting cloud "service".

	Eddy.


From Shawn.Rutledge at qt.io  Wed Aug 30 11:22:41 2017
From: Shawn.Rutledge at qt.io (Shawn Rutledge)
Date: Wed, 30 Aug 2017 09:22:41 +0000
Subject: [Development] Qt and IoT infographic
In-Reply-To: <1512005.VXTWK0GkGM@tjmaciei-mobl1>
References: <1692398.lzVxuX8aJu@tjmaciei-mobl1>
	<AM4PR02MB3249886B4E6450751FA2D366879F0@AM4PR02MB3249.eurprd02.prod.outlook.com>
	<07BE9501-B980-4593-B72C-98E7234E61B2@qt.io>
	<1512005.VXTWK0GkGM@tjmaciei-mobl1>
Message-ID: <13AF374A-F78C-4CA8-AC58-A3CFD6295D96@qt.io>


> On 29 Aug 2017, at 18:00, Thiago Macieira <thiago.macieira at intel.com> wrote:
> 
> On Tuesday, 29 August 2017 02:43:44 PDT Shawn Rutledge wrote:
>> And yet it has a web server for serving up either a human-readable page or
>> JSON on demand, and it also pushes data to a central server periodically.
> 
> Is that a static JSON? Because if you need to compose the data on the fly, you 
> may also want to replace JSON with something simpler. See 
> 	https://github.com/01org/tinycbor/

OK

> You'll find that the maintainer is familiar :-)
> 
> As for the part about "pushes data to a central server", I hope it's a server 
> on the local network, not on the Cloud.(

The creator’s reason for making the device is to show radiation levels and pollution (and incidentally weather) worldwide on a map, so yeah, it pushes data to his server; it has to be aggregated somewhere.  https://www.uradmonitor.com/

I have a Go program pulling the JSON and inserting readings into influx locally too, periodically (cron job).

I want to figure out a way to use IPFS or IPLD for time-series data though.

> Firefox has a CoAP addon.
> https://addons.mozilla.org/en-US/firefox/addon/copper-270430/

Cool

> Intel has shown that Linux is a viable target at 2 MB of RAM. We can boot a 
> kernel at 1 MB, but then there's nothing left for your application. Shrinking

Yep, I tried that back in the late 90’s on a 386-based embedded touchscreen machine once, and that’s what I found then: with 1MB the kernel took most of it, not sure if there was even enough left for busybox; with 2MB, something would be possible, but it didn’t have that much.

> the kernel further is possible, but it depends on whether the upstream would 
> accept such changes -- for example, disabling TCP and leaving only UDP 
> enabled. The kernel network maintainers currently have the position that they 
> don't want this and you should just switch to a microcontroller RTOS at that 
> point.
> 
> For Qt, we have to make sure it runs comfortably at 128 MB and we should 
> strive to make it possible for 32 MB of RAM.

In the Qt 2 timeframe that would’ve been plenty.  I wonder how far we will really get with configure options to leave stuff out.


From Morten.Sorvig at qt.io  Wed Aug 30 11:28:47 2017
From: Morten.Sorvig at qt.io (=?utf-8?B?TW9ydGVuIFPDuHJ2aWc=?=)
Date: Wed, 30 Aug 2017 09:28:47 +0000
Subject: [Development] [fix]: Assistant (and others) burning CPU because
 of #f27d1ccbb24ec2fd4098f2976503478831006cc8 ?
In-Reply-To: <2209541.uETthxIbLi@maurice>
References: <1600335.9fNCGNT7fm@portia.local> <2016136.MCHlo2iGPk@bola>
	<9009568.Ri8CIgFy91@tjmaciei-mobl1> <2209541.uETthxIbLi@maurice>
Message-ID: <9DC95D1F-F278-48DA-943E-130028618B48@qt.io>


> On 30 Aug 2017, at 09:30, Olivier Goffart <olivier at woboq.com> wrote:
> 
> Am Dienstag, 29. August 2017, 17:30:56 CEST schrieb Thiago Macieira:
>> On Tuesday, 29 August 2017 01:10:53 PDT René J.V. Bertin wrote:
>>> Which we just rediscovered :) Funny though, apparently 1 misdirected
>>> startTimer() call can turn any application in a CPU hog that burns cycles
>>> without ever doing anything. Wouldn't it be safer for
>>> QObject::timerEvent()
>>> to kill any timer that triggers it, possibly even do an abort if it can do
>>> some kind of runtime debug mode detection? At least then it's set to a 0
>>> (zero) interval?
>> 
>> Sure. Please tell that to Eirik and Håvard back in the early 90s when
>> they're designing Qt.
>> 	http://doc.qt.io/archives/2.3/qobject.html#4c6b67
>> 	(Qt 1 docs not online)
>> 
>> Unfortunately, we can't change anymore.
> 
> We can change the documentation and recommend against using killTimer and 
> startTimer. QBasicTimer should be used instead. This would have probably 
> avoided the problem in this case (as one would have called stop instead of 
> m_updateTimer = 0). And in general is easier to use for 0 overhead.

There is also the option of creating new API that better covers the use case of
running a pice of code once when control returns to the event loop. In use this
could look something like this:

QCocoaMenu::scheduleUpdate()
{
    if (m_updateScheduled)
       return;
    m_updateScheduled = true;

    this->QObject::schedule([&m_updateScheduled, m_nativeMenu](){
	m_updateScheduled = false;
        [m_nativeMenu update];   
    });
}

or even:

QCocoaMenu::scheduleUpdate()
{
    this->QObject::scheduleOnce(&m_updateScheduled, [m_nativeMenu](){
        [m_nativeMenu update];   
    });
}

Morten






From giuseppe.dangelo at kdab.com  Wed Aug 30 11:31:43 2017
From: giuseppe.dangelo at kdab.com (Giuseppe D'Angelo)
Date: Wed, 30 Aug 2017 11:31:43 +0200
Subject: [Development] [fix]: Assistant (and others) burning CPU because
 of #f27d1ccbb24ec2fd4098f2976503478831006cc8 ?
In-Reply-To: <9DC95D1F-F278-48DA-943E-130028618B48@qt.io>
References: <1600335.9fNCGNT7fm@portia.local> <2016136.MCHlo2iGPk@bola>
	<9009568.Ri8CIgFy91@tjmaciei-mobl1> <2209541.uETthxIbLi@maurice>
	<9DC95D1F-F278-48DA-943E-130028618B48@qt.io>
Message-ID: <bbc729c0-e68a-1e3f-a1d9-66e35d41c1d4@kdab.com>

Il 30/08/2017 11:28, Morten Sørvig ha scritto:
> There is also the option of creating new API that better covers the use case of
> running a pice of code once when control returns to the event loop. In use this
> could look something like this:
> 
> QCocoaMenu::scheduleUpdate()
> {
>      if (m_updateScheduled)
>         return;
>      m_updateScheduled = true;
> 
>      this->QObject::schedule([&m_updateScheduled, m_nativeMenu](){
> 	m_updateScheduled = false;
>          [m_nativeMenu update];
>      });
> }

Today, that QObject::schedule is achieved by (ab)using 
QTimer::singleShot(0, func). I'd encourage a better named API.

My 2 c,
-- 
Giuseppe D'Angelo | giuseppe.dangelo at kdab.com | Senior Software Engineer
KDAB (UK) Ltd., a KDAB Group company | Tel: UK +44-1625-809908
KDAB - 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: <http://lists.qt-project.org/pipermail/development/attachments/20170830/b1fcdfd5/attachment.bin>

From jeanmichael.celerier at gmail.com  Wed Aug 30 11:34:58 2017
From: jeanmichael.celerier at gmail.com (=?UTF-8?Q?Jean=2DMicha=C3=ABl_Celerier?=)
Date: Wed, 30 Aug 2017 11:34:58 +0200
Subject: [Development] [fix]: Assistant (and others) burning CPU because
 of #f27d1ccbb24ec2fd4098f2976503478831006cc8 ?
In-Reply-To: <bbc729c0-e68a-1e3f-a1d9-66e35d41c1d4@kdab.com>
References: <1600335.9fNCGNT7fm@portia.local> <2016136.MCHlo2iGPk@bola>
	<9009568.Ri8CIgFy91@tjmaciei-mobl1> <2209541.uETthxIbLi@maurice>
	<9DC95D1F-F278-48DA-943E-130028618B48@qt.io>
	<bbc729c0-e68a-1e3f-a1d9-66e35d41c1d4@kdab.com>
Message-ID: <CAE1uMrWxG8BkJcnFhsOxroePkL323OJZztFb+=zCe6VjbRCk7A@mail.gmail.com>

> Today, that QObject::schedule is achieved by (ab)using
QTimer::singleShot(0, func).

There have been interesting discussions on StackOverflow about this :

https://stackoverflow.com/questions/21646467/how-to-execute-a-functor-or-a-lambda-in-a-given-thread-in-qt-gcd-style
https://stackoverflow.com/questions/24142450/qtimersingleshot-and-qmetamethodinvoke

Best
Jean-Michaël



-------
Jean-Michaël Celerier
http://www.jcelerier.name

On Wed, Aug 30, 2017 at 11:31 AM, Giuseppe D'Angelo <
giuseppe.dangelo at kdab.com> wrote:

> Il 30/08/2017 11:28, Morten Sørvig ha scritto:
>
>> There is also the option of creating new API that better covers the use
>> case of
>> running a pice of code once when control returns to the event loop. In
>> use this
>> could look something like this:
>>
>> QCocoaMenu::scheduleUpdate()
>> {
>>      if (m_updateScheduled)
>>         return;
>>      m_updateScheduled = true;
>>
>>      this->QObject::schedule([&m_updateScheduled, m_nativeMenu](){
>>         m_updateScheduled = false;
>>          [m_nativeMenu update];
>>      });
>> }
>>
>
> Today, that QObject::schedule is achieved by (ab)using
> QTimer::singleShot(0, func). I'd encourage a better named API.
>
> My 2 c,
> --
> Giuseppe D'Angelo | giuseppe.dangelo at kdab.com | Senior Software Engineer
> KDAB (UK) Ltd., a KDAB Group company | Tel: UK +44-1625-809908
> KDAB - Qt, C++ and OpenGL Experts
>
>
> _______________________________________________
> Development mailing list
> Development at qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20170830/5854844b/attachment.html>

From jani.heikkinen at qt.io  Wed Aug 30 14:21:24 2017
From: jani.heikkinen at qt.io (Jani Heikkinen)
Date: Wed, 30 Aug 2017 12:21:24 +0000
Subject: [Development] Qt 5.9.2 snapshot available
Message-ID: <HE1PR02MB31329BE3FFE340F8570949EE9D9C0@HE1PR02MB3132.eurprd02.prod.outlook.com>

Hi,

We have new Qt 5.9.2 snapshot available via online installer. Instructions how to get it here: https://wiki.qt.io/How_to_get_snapshot_via_online_installer

Snapshot is based on https://codereview.qt-project.org/#/c/203493/

Packages are smoke tested and seems to be OK so please take a tour. Please report your effort via https://wiki.qt.io/Qt59_release_testing

br,
Jani Heikkinen
Release Manager



From jhihn at gmx.com  Wed Aug 30 16:32:42 2017
From: jhihn at gmx.com (Jason H)
Date: Wed, 30 Aug 2017 16:32:42 +0200
Subject: [Development] Qt and IoT infographic
In-Reply-To: <3123873.vLZO8E3TcY@tjmaciei-mobl1>
References: <1692398.lzVxuX8aJu@tjmaciei-mobl1>
	<5154256.3fEKKNXxgl@tjmaciei-mobl1>
	<CAE1uMrWJTsMvMM9=BJtOZ+Yh=6ntKBrU3_2aak+=946ovUs-kw@mail.gmail.com>
	<3123873.vLZO8E3TcY@tjmaciei-mobl1>
Message-ID: <trinity-c95f4ec5-0748-46af-a909-23b5a0ed65f8-1504103562298@3c-app-mailcom-bs16>



> Sent: Tuesday, August 29, 2017 at 5:07 PM
> From: "Thiago Macieira" <thiago.macieira at intel.com>
> To: development at qt-project.org
> Subject: Re: [Development] Qt and IoT infographic
...
> > Besides, this comes a bit as disdainful. I work in music research and
> > *everything* embedded uses Arduinos, Pi, Beaglebones or similar. If you
> > have seen interactive artistic installations in museums, outdoor
> > expositions, or contemporary concerts, there is a huge chance there's a Pi
> > or an Arduino running somewhere. Sure, there aren't "products" that end up
> > produced thousand times and sold on the counter or at Moser, but they are
> > shows, expositions, etc. which generate revenue all the same, for the
> > artists, museums, etc. and need programmers to get the stuff running and
> > banging sound.
> 
> I was talking about production runs, where you make thousands to millions of 
> exact copies. I guess I wasn't very clear about that.
> 
> For one-offs or maybe tens of copies, sure, there's a lot of Arduinos. And a 
> lot of Raspberry Pis too.
> 
> For production runs, that number goes very quickly to zero.

I guess this comes down to whom you are marketing. I can understand Intel and TrollTech (whatever you call current incarnation) wanting those high volume customers. But I think the innovation space is not those high volume customers. It's kickstarters, hobbyists, etc. The knowledge required to go from a Qt level knowledge to a dedicated MCU is as big a gulf - as big a difference as in the hardware specs. It's far easier to pick up Qt and spend a few more $ on your board than to learn about interrupts and all that stuff. The market play here is to use the OSS license, get them to develop their stack on Qt and have them pay for a license later. You'll get far more things for your showcase.

I don't know much about 3D but thanks to QtQuick and Qt3D, I can use 3D in my software. I'd like a similar experience for IoT people. I don't know much about video over USB but I don't need to, QML's Camera works with it. 

I was recently working on an embedded project where we had a couple options. One was essentially a Pi Zero, with reduced memory and storage, providing a REST interface to the data. Quantities in 10k increments, about 10k per year. Because that was judged to be too much work to get running, we ended up not using Qt on the device, but Qt to get the video frames on a connected computer.

These situations may be anecdotal, but I think they'll be more common and I'd like Qt to be ideally positioned for the next million innovators.


From thiago.macieira at intel.com  Wed Aug 30 17:35:10 2017
From: thiago.macieira at intel.com (Thiago Macieira)
Date: Wed, 30 Aug 2017 08:35:10 -0700
Subject: [Development] [fix]: Assistant (and others) burning CPU because
 of #f27d1ccbb24ec2fd4098f2976503478831006cc8 ?
In-Reply-To: <2209541.uETthxIbLi@maurice>
References: <1600335.9fNCGNT7fm@portia.local>
	<9009568.Ri8CIgFy91@tjmaciei-mobl1> <2209541.uETthxIbLi@maurice>
Message-ID: <3560152.9LNRMYP71E@tjmaciei-mobl1>

On Wednesday, 30 August 2017 00:30:05 PDT Olivier Goffart wrote:
> We can change the documentation and recommend against using killTimer and
> startTimer. QBasicTimer should be used instead. This would have probably
> avoided the problem in this case (as one would have called stop instead of
> m_updateTimer = 0). And in general is easier to use for 0 overhead.

Actually, there is an overhead, albeit very small one: the timer ID is stored.

Your class may not need the timer ID. It can stop the timer by using 
QTimerEvent::timerId() when the timer fires.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center



From thiago.macieira at intel.com  Wed Aug 30 17:47:50 2017
From: thiago.macieira at intel.com (Thiago Macieira)
Date: Wed, 30 Aug 2017 08:47:50 -0700
Subject: [Development] Qt and IoT infographic
In-Reply-To: <trinity-c95f4ec5-0748-46af-a909-23b5a0ed65f8-1504103562298@3c-app-mailcom-bs16>
References: <1692398.lzVxuX8aJu@tjmaciei-mobl1>
	<3123873.vLZO8E3TcY@tjmaciei-mobl1>
	<trinity-c95f4ec5-0748-46af-a909-23b5a0ed65f8-1504103562298@3c-app-mailcom-bs16>
Message-ID: <5856903.sssktiQqu5@tjmaciei-mobl1>

On Wednesday, 30 August 2017 07:32:42 PDT Jason H wrote:
> > For one-offs or maybe tens of copies, sure, there's a lot of Arduinos. And
> > a lot of Raspberry Pis too.
> > 
> > For production runs, that number goes very quickly to zero.
> 
> I guess this comes down to whom you are marketing. I can understand Intel
> and TrollTech (whatever you call current incarnation) wanting those high
> volume customers. But I think the innovation space is not those high volume
> customers. It's kickstarters, hobbyists, etc. 

Note I did not talk about innovation. I talked about the actual products.

Regardless of who innovates and what platforms they innovate on, they don't 
use Arduinos and Raspbery Pis for the products once they move on from 
prototypes. Specifically on the case of Arduino, since the Arduino API is not 
available on the next device, there's almost always a full rewrite of the 
software when this happens.

For bigger devices, we should hope that, like Eddy said, that the application 
written with Qt can just be run on the production-quality hardware almost 
unchanged.

> The knowledge required to go
> from a Qt level knowledge to a dedicated MCU is as big a gulf - as big a
> difference as in the hardware specs. It's far easier to pick up Qt and
> spend a few more $ on your board than to learn about interrupts and all
> that stuff. The market play here is to use the OSS license, get them to
> develop their stack on Qt and have them pay for a license later. You'll get
> far more things for your showcase.

That's a good point. This is a contrast a colleague of mine explained as a 
simple matter of what costs more: a day or a byte. That is to say, when time 
to market is more important than the device's BOM cost being a few dollars 
more, you'll do exactly that and you'll use bigger but easier frameworks that 
allow for rapid prototyping. Qt's competitor here is, as others have noted, 
Node.js.

When the dollars matter more and you do need to constrain your BOM to a 
certain price range, then you'll spend as much time as needed to shrink your 
software and optimise it to fit. I don't think Qt fits this market right now -- 
except as the alternative to something much bigger, like replacing an HTML5 
engine.

> I don't know much about 3D but thanks to QtQuick and Qt3D, I can use 3D in
> my software. I'd like a similar experience for IoT people. I don't know
> much about video over USB but I don't need to, QML's Camera works with it.

Now let's do video over IP so we can get that video from a networked camera, 
and add support for OpenCV so we can actually process that image.

> I was recently working on an embedded project where we had a couple options.
> One was essentially a Pi Zero, with reduced memory and storage, providing a
> REST interface to the data. Quantities in 10k increments, about 10k per
> year. Because that was judged to be too much work to get running, we ended
> up not using Qt on the device, but Qt to get the video frames on a
> connected computer.

Exactly the type of scenario I mentioned above and I expect to happen more and 
more often.

> These situations may be anecdotal, but I think they'll be more common and
> I'd like Qt to be ideally positioned for the next million innovators.

No, you're probably onto something.

Qt will not run on the MCUs and the final endpoint devices on your network 
(often a mesh network). But Qt will communicate with them and will do 
processing on the data received from them.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center



From rjvbertin at gmail.com  Wed Aug 30 18:32:10 2017
From: rjvbertin at gmail.com (=?ISO-8859-1?Q?Ren=E9_J=2EV=2E?= Bertin)
Date: Wed, 30 Aug 2017 18:32:10 +0200
Subject: [Development] NSMenu validation,
 QCocoaMenu and button (context etc) menus
In-Reply-To: <256B709E-1A47-47C1-92A5-DCF598705496@qt.io>
References: <1600335.9fNCGNT7fm@portia.local>
	<1538122.08VYYKp83P@tjmaciei-mobl1>
	<256B709E-1A47-47C1-92A5-DCF598705496@qt.io>
Message-ID: <5449928.dpHgSHzFra@portia.local>

Hi,

I ran into and reported a CPU burning issue a couple of days back, which was quickly resolved. It intrigued me why an application that doesn't use native Mac menus at all would be calling [NSMenu update] at all. 

I now know that the menu which triggered the scheduled NSMenu update is one that is attached to a button but that is also installed as the Dock menu. I guess that explains why its QMenu items have corresponding QCocoaMenu items.

If [NSMenu update] is expensive, is it certain that it's only being called when required, i.e. only for menus attached to the native menubar or possibly the application's dock tile? 

R.

On Tuesday August 29 2017 02:02:59 Gabriel de Dietrich wrote:
> FYI: QCocoaMenu: Stop update timer (Merged)<https://codereview.qt-project.org/203791>
> 
> Best regards,
> 
> Dr. Gabriel de Dietrich
> Senior Software Developer
> The Qt Company
> 
> On Aug 29, 2017, at 9:00 AM, Thiago Macieira <thiago.macieira at intel.com<mailto:thiago.macieira at intel.com>> wrote:
> 
> On Monday, 28 August 2017 17:06:18 PDT René J.V. Bertin wrote:
>        killTimer(m_updateTimer);
> 
> before setting m_updateTimer=0? Whether or not it's appropriate, this does
> solve the CPU burning for me.
> 
> Yeah, if you don't kill the timer, it will keep firing.
> 
> --
> Thiago Macieira - thiago.macieira (AT) intel.com<http://intel.com>
>  Software Architect - Intel Open Source Technology Center
> 
> _______________________________________________
> Development mailing list
> Development at qt-project.org<mailto:Development at qt-project.org>
> http://lists.qt-project.org/mailman/listinfo/development
> 



From thiago.macieira at intel.com  Wed Aug 30 21:45:44 2017
From: thiago.macieira at intel.com (Thiago Macieira)
Date: Wed, 30 Aug 2017 12:45:44 -0700
Subject: [Development] Backporting the Keccak change
Message-ID: <14896643.VvgrSxGg5G@tjmaciei-mobl1>

When writing the 5.6.3 changelog, I'm currently leaving it with:

******************************************************************************
*                     Important Behavior Changes                             *
******************************************************************************

 - QCryptographicHash:
   * [QTBUG-59770] QCryptographicHash now properly calculates SHA3 message
     digests. Before, when asked to calculate a SHA3 digest, it calculated
     a Keccak digest instead.

I think this is bad for the 5.6.3 release. After 5.9.0 was released, we had a 
couple of people asking for the ability to calculate Keccak instead of SHA3 
because they needed to compare against stored hashes that had been 
(incorrectly) calculated using Keccak.

So I think we need to take action here. But what?

 a) revert the 5.6 backport of 88a8feeacb9bdaff9ee06164424e407eb904cd10 so 
that 5.6.x will forever calculate Keccak, not SHA3;

 b) additionally backport 12c5264d9add1826d543c36d893db77262195fc6 to both 5.6 
and 5.9, with the proper binary compatibility notices, so that people who need 
to can adapt their code to calculate Keccak. It won't be pretty, but it will 
work.

I'm actually leaning towards (a) for 5.6 and (b) for 5.9.
-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center



From rjvbertin at gmail.com  Wed Aug 30 23:17:05 2017
From: rjvbertin at gmail.com (=?UTF-8?B?UmVuw6kgSi4gVi4=?= Bertin)
Date: Wed, 30 Aug 2017 23:17:05 +0200
Subject: [Development] [fix]: Assistant (and others) burning CPU because
 of #f27d1ccbb24ec2fd4098f2976503478831006cc8 ?
References: <1600335.9fNCGNT7fm@portia.local>
	<256B709E-1A47-47C1-92A5-DCF598705496@qt.io>
	<2016136.MCHlo2iGPk@bola> <9009568.Ri8CIgFy91@tjmaciei-mobl1>
Message-ID: <26466282.mM2nPz0K5z@portia.local>

Thiago Macieira wrote:

Oops, missed this one.

> Unfortunately, we can't change anymore.

Can someone explain what could possibly be broken by changing this? Can the 
current base-level QObject::timerEvent() be used for anything constructive other 
than heating the office or preventing a CPU core from going to sleep?
I only made my suggestion because it seemed rather evident that anyone using the 
QObject timer would override the timerEvent() method.

That said, it does seem a bit overkill to give each and every instance 
inheriting QObject timer features. Most will presumably never use that in a 
typical application, would they?

>> It took me an unreasonable amount of time trying to figure out the reason
>> for the burning, the fact that QCocoaMenu::timerEvent() could be being
>> called as fast as possible and for nothing occurred to me only after trying
>> all other possibilities. And I knew only the timer change could be the
>> culprit; I can only imagine how much more time I'd have spent if this bug
>> had been latent for a few months.
> 
> i'm glad you found it.
> 
> How did you?

How did I discover the issue? I have a top-of-the-2011-line laptop i7 in a 13" 
MBP, and no airco. One tends to notice when it gets busy and remains busy when 
you're not expecting it, and you know something's wrong when a quick look in 
`top` shows nearly 100% CPU for an application that appears to be doing nothing 
(KDevelop in this case, and fortunately I discovered afterwards that Assistant 
worked as a demonstrator too).

Found the bug/fix? The usual way, reverting all changes and restoring them in 
order of least likely culprit. Then by generating trace output, evidently I 
thought last of putting it *before* the timer ID check, and then I had to 
consult the docs to confirm that one indeed needs to kill the timer when done. 
I'd never have guessed that a noop event handler callback could have pump this 
many resources. 

> Actually, there is an overhead, albeit very small one: the timer ID is stored.

Indeed, I wondered about that, and then let it pass because the compiler will 
probably optimise it away.

R.



From thiago.macieira at intel.com  Thu Aug 31 00:13:43 2017
From: thiago.macieira at intel.com (Thiago Macieira)
Date: Wed, 30 Aug 2017 15:13:43 -0700
Subject: [Development] [fix]: Assistant (and others) burning CPU because
 of #f27d1ccbb24ec2fd4098f2976503478831006cc8 ?
In-Reply-To: <26466282.mM2nPz0K5z@portia.local>
References: <1600335.9fNCGNT7fm@portia.local>
	<9009568.Ri8CIgFy91@tjmaciei-mobl1>
	<26466282.mM2nPz0K5z@portia.local>
Message-ID: <3310125.43yb58AKty@tjmaciei-mobl1>

On Wednesday, 30 August 2017 14:17:05 PDT René J. V. Bertin wrote:
> Thiago Macieira wrote:
> 
> Oops, missed this one.
> 
> > Unfortunately, we can't change anymore.
> 
> Can someone explain what could possibly be broken by changing this? Can the
> current base-level QObject::timerEvent() be used for anything constructive
> other than heating the office or preventing a CPU core from going to sleep?
> I only made my suggestion because it seemed rather evident that anyone
> using the QObject timer would override the timerEvent() method.

It makes QTimer possible.

void QTimer::start()
{
    if (id != INV_TIMER)                        // stop running timer
        stop();
    nulltimer = (!inter && single);
    id = QObject::startTimer(inter, Qt::TimerType(type));
}

That sounds quite important to me :-)

QBasicTimer also used it until f821d6352e384a737c82a0db903104ec4f8611bd, when 
Brad wrote "QBasicTimer becomes even more low-level. It cannot use 
QObject::startTimer() anymore, since we do not have a way to call 
QObject::killTimer() from QBasicTimer::stop()."

On a serious note, there's a lot of code that uses startTimer() to get timers 
more efficiently than QTimer or even QBasicTimer. We can't remove this function, 
because it would break the existing code. And we can't make it a single shot 
because it would be even worse: it would silently would equally break existing 
code that expects the timer to repeat itself. This code is probably buried 
deep into codebases several years old and not that trivial to find.

And I don't want to add a flag to say it's a single shot to the event 
dispatcher, because it would add overhead for all existing timers. Not to 
mention it's not doable until Qt 6 when we can add or modify virtual methods 
to QAbstractEventDispatcher.

> That said, it does seem a bit overkill to give each and every instance
> inheriting QObject timer features. Most will presumably never use that in a
> typical application, would they?

Most won't. How do you choose which ones should get the feature? If you're 
arguing for a white list, please compile such al ist, including all uses in 
KDE code, all applications, etc.

And how would we even achieve this? The only way I can think of is to make 
those functions private (a Qt 6 change) and add the whitelisted classes as 
friends.

> Found the bug/fix? The usual way, reverting all changes and restoring them
> in order of least likely culprit. Then by generating trace output,
> evidently I thought last of putting it *before* the timer ID check, and
> then I had to consult the docs to confirm that one indeed needs to kill the
> timer when done. I'd never have guessed that a noop event handler callback
> could have pump this many resources.

Ok, so you found by git bisect (or similar) action. I was hoping you had some 
interesting way of debugging that the problem is timers constantly firing. I 
woder if GammaRay can give you a list of timers active in a thread and which 
objects it's connected to. Volker?

> > Actually, there is an overhead, albeit very small one: the timer ID is
> > stored.
> Indeed, I wondered about that, and then let it pass because the compiler
> will probably optimise it away.

it won't, because the QBasicTimer object needs to be stored somewhere. If 
you're replacing an int m_timerId with QBasicTimer, there's no overhead. But 
if you don't store the timer ID, there's an overhead.

You can't not store the QBasicTimer (pardon the double negative). On its 
destruction, it will stop the timer. So if you used it in a regular function 
scope, the tiemr would never fire.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center



From rjvbertin at gmail.com  Thu Aug 31 02:17:32 2017
From: rjvbertin at gmail.com (=?UTF-8?B?UmVuw6kgSi4gVi4=?= Bertin)
Date: Thu, 31 Aug 2017 02:17:32 +0200
Subject: [Development] [fix]: Assistant (and others) burning CPU because
 of #f27d1ccbb24ec2fd4098f2976503478831006cc8 ?
References: <1600335.9fNCGNT7fm@portia.local>
	<9009568.Ri8CIgFy91@tjmaciei-mobl1>
	<26466282.mM2nPz0K5z@portia.local>
	<3310125.43yb58AKty@tjmaciei-mobl1>
Message-ID: <2110720.0gcV5EGXb5@portia.local>

Thiago Macieira wrote:


> It makes QTimer possible.
..
> That sounds quite important to me :-)

I guess so :) I still don't get what purpose calling QObject::timerEvent() has 
if the method itself does nothing. Gives me something to ponder.


> function, because it would break the existing code. And we can't make it a
> single shot because it would be even worse: it would silently would equally
> break existing code that expects the timer to repeat itself. This code is

You're making me doubt. If some class inheriting QObject provides its own 
QFoo:timerEvent() as I understand it should, QObject::timerEvent() isn't called, 
right? Is there code that makes that call explicitly?

> Most won't. How do you choose which ones should get the feature? If you're
> arguing for a white list, please compile such al ist, including all uses in
> KDE code, all applications, etc.

No, I'm not. I think I misread some replies as a suggestion the timer feature 
could maybe be removed. 

> And how would we even achieve this? The only way I can think of is to make
> those functions private (a Qt 6 change) and add the whitelisted classes as
> friends.

What's to stop you (in some future Qt major version) from moving the timer 
features to a dedicated QObjectTimer class, forcing code that relies on the 
feature to inherit that class in addition to QObject?

> Ok, so you found by git bisect (or similar) action. I was hoping you had some
> interesting way of debugging that the problem is timers constantly firing. I

Sadly, no. A boring way:

QCocoaMenu::timerEvent(...)
{
    qInfo() << $somethingSnarky;


I did try monitoring the process with Instruments but that failed to attach.


>> Indeed, I wondered about that, and then let it pass because the compiler
>> will probably optimise it away.
> 
> it won't, because the QBasicTimer object needs to be stored somewhere. If
> you're replacing an int m_timerId with QBasicTimer, there's no overhead. But
> if you don't store the timer ID, there's an overhead.
> 
> You can't not store the QBasicTimer (pardon the double negative). On its
> destruction, it will stop the timer. So if you used it in a regular function
> scope, the tiemr would never fire.

Erm, I was clearly distracted earlier (note to self: discussing Qt concepts 
doesn't mix with Dolly Parton 8-) ).
I thought I'd seen that QCocoaMenu::timerEvent() did something like

 int timerId = e->timerId();
 if (timerId == m_updateTimer) { //etc }

and that the temp. variable was the cause of the overhead you mentioned.

Sorry for the noise.

R.



From thiago.macieira at intel.com  Thu Aug 31 02:51:32 2017
From: thiago.macieira at intel.com (Thiago Macieira)
Date: Wed, 30 Aug 2017 17:51:32 -0700
Subject: [Development] [fix]: Assistant (and others) burning CPU because
 of #f27d1ccbb24ec2fd4098f2976503478831006cc8 ?
In-Reply-To: <2110720.0gcV5EGXb5@portia.local>
References: <1600335.9fNCGNT7fm@portia.local>
	<3310125.43yb58AKty@tjmaciei-mobl1>
	<2110720.0gcV5EGXb5@portia.local>
Message-ID: <15672475.ZeCjxWMBSd@tjmaciei-mobl1>

On Wednesday, 30 August 2017 17:17:32 PDT René J. V. Bertin wrote:
> Thiago Macieira wrote:
> > It makes QTimer possible.
> > That sounds quite important to me :-)
> 
> I guess so :) I still don't get what purpose calling QObject::timerEvent()
> has if the method itself does nothing. Gives me something to ponder.

Again, that's what makes QTimer possible.

void QTimer::timerEvent(QTimerEvent *e)
{
    if (e->timerId() == id) {
        if (single)
            stop();
        emit timeout(QPrivateSignal());
    }
}


> > function, because it would break the existing code. And we can't make it a
> > single shot because it would be even worse: it would silently would
> > equally
> > break existing code that expects the timer to repeat itself. This code is
> 
> You're making me doubt. If some class inheriting QObject provides its own
> QFoo:timerEvent() as I understand it should, QObject::timerEvent() isn't
> called, right? Is there code that makes that call explicitly?

This is the same as any event override in Qt, which is basically the same as 
any virtual function override in C++. The overriding function gets to decide 
whether it needs to call the base implementation for something.

QObject::timerEvent does nothing, but other QObject::xxxEvent functions might, 
ditto for QWidget::xxxEvent().

> > And how would we even achieve this? The only way I can think of is to make
> > those functions private (a Qt 6 change) and add the whitelisted classes as
> > friends.
> 
> What's to stop you (in some future Qt major version) from moving the timer
> features to a dedicated QObjectTimer class, forcing code that relies on the
> feature to inherit that class in addition to QObject?

Source compatibility. Which is why it's unlikely we'll do it.

That said, it's not a horrible idea to move this out of QObject. We don't have 
an equivalent watchSocket() function that registers socket notifiers -- we make 
people use QSocketNotifier instead.

> > Ok, so you found by git bisect (or similar) action. I was hoping you had
> > some interesting way of debugging that the problem is timers constantly
> > firing. I
> Sadly, no. A boring way:
> 
> QCocoaMenu::timerEvent(...)
> {
>     qInfo() << $somethingSnarky;
> 
> 
> I did try monitoring the process with Instruments but that failed to attach.

But how did you find out it was a timer? And that it was a timer in QCocoaMenu?

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center



From jani.heikkinen at qt.io  Thu Aug 31 08:06:02 2017
From: jani.heikkinen at qt.io (Jani Heikkinen)
Date: Thu, 31 Aug 2017 06:06:02 +0000
Subject: [Development] Maintainers,
 your actions needed: Change files for Qt 5.6.3
In-Reply-To: <HE1PR02MB31324BEC0AB264FD7106FDFA9D9F0@HE1PR02MB3132.eurprd02.prod.outlook.com>
References: <HE1PR02MB313245A61F337ABC985752A09D9F0@HE1PR02MB3132.eurprd02.prod.outlook.com>
	<c875994d-a31e-7eac-7e14-f6ae47de66bd@iseg-hv.de>,
	<HE1PR02MB31324BEC0AB264FD7106FDFA9D9F0@HE1PR02MB3132.eurprd02.prod.outlook.com>
Message-ID: <HE1PR02MB3132BE8478EE6C413FC850FF9D9D0@HE1PR02MB3132.eurprd02.prod.outlook.com>

Hi all,

Still quite many Qt 5.6.3 change files still without any action or missing '+2'... (see https://codereview.qt-project.org/#/q/message:%22Add+change+file+for%22,n,z )

Maintainers, please finalize these during today; we need to get these in to be able to proceed with Qt 5.6.3 release

br,
Jani
________________________________________
From: Development <development-bounces+jani.heikkinen=qt.io at qt-project.org> on behalf of Jani Heikkinen <jani.heikkinen at qt.io>
Sent: Tuesday, August 29, 2017 1:04 PM
To: André Hartmann; development at qt-project.org
Subject: Re: [Development] Maintainers, your actions needed: Change files for Qt 5.6.3

> -----Original Message-----
> From: André Hartmann [mailto:andre.hartmann at iseg-hv.de]
> Sent: tiistai 29. elokuuta 2017 9.25
> To: Jani Heikkinen <jani.heikkinen at qt.io>; development at qt-project.org
> Subject: Re: [Development] Maintainers, your actions needed: Change files
> for Qt 5.6.3
>
> Hi Jani,
>
> I have some comments to the change file process:
>
> 1. The commit message is "Add change file for Qt 5.6.3" but it should be
>     "Add changes file for Qt 5.6.3" (plural)

True, let's be more exact at next time

>2. In the last releases, this initial version was WIP, so the maintainer
>     needed to adjust the message so it could be merged. I think this is
>     useful.

There were also opposite comments earlier about this ;) But both is OK for us; I don't see that big difference there...


> 3. How about projects with no changes between 5.6.2 and 5.6.3
>     (like qtserialbus)? Usually there is also a changes file with a line
>     "No relevant changes in this release", but right now there is no file
>     a all.
Yes, this is a mistake. We try to do one for all but qtserialbus was ignored because of some reason. It is now done.

>
> I know it is some effort for the release team to create these templates, but
> with good templates you get consistent final files for the whole project.

True, and I think we need to improve this somehow in the future. I think we should discuss this in contributor summit

- Jani
>
> Best regards,
> André
>
> Am 29.08.2017 um 06:53 schrieb Jani Heikkinen:
> > Hi all,
> >
> > We have now created initial change files for Qt 5.6.3. Please do
> > needed modifications immediately and get '+2' as soon as possible. We
> > need to get these in to be able to proceed with Qt 5.6.3 release. You
> > can find all open change files for Qt 5.6.3 here:
> > https://codereview.qt-
> project.org/#/q/branch:5.9+status:open+message:%
> > 22Add+change+file%22,n,z
> >
> > After approval those change files will be direct pushed in '5.9',
> > cherry picked in '5.6.3' and finally direct pushed there, see
> > http://lists.qt-project.org/pipermail/development/2017-August/030722.h
> > tml
> >
> > br,
> > Jani Heikkinen
> > Release Manager
> >
> >
> > _______________________________________________
> > Development mailing list
> > Development at qt-project.org
> > http://lists.qt-project.org/mailman/listinfo/development
> >
> >
>
>
> --
> Best regards / Mit freundlichen Grüßen
> André Hartmann, Dipl.-Ing. (FH)
> Software Project Manager
>
> iseg Spezialelektronik GmbH         |  phone: ++49 (0)351 26996-43
> Bautzner Landstr. 23                |  fax:   ++49 (0)351 26996-21
> D-01454 Radeberg / Rossendorf       |  web:   www.iseg-hv.com
>
> Geschäftsführer / Managing director: Dr. F. Gleisberg, Dr. J. Pöthig
> Amtsgericht / Lower district court: Dresden HRB 16250 Ust.-Id.-Nr. / VAT-ID:
> DE812508942
>
> 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 delete this e-mail.
> Any unauthorized copying, disclosure or distribution of the material in this e-
> mail is strictly forbidden.
_______________________________________________
Development mailing list
Development at qt-project.org
http://lists.qt-project.org/mailman/listinfo/development


From lars.knoll at qt.io  Thu Aug 31 08:12:40 2017
From: lars.knoll at qt.io (Lars Knoll)
Date: Thu, 31 Aug 2017 06:12:40 +0000
Subject: [Development] Backporting the Keccak change
In-Reply-To: <14896643.VvgrSxGg5G@tjmaciei-mobl1>
References: <14896643.VvgrSxGg5G@tjmaciei-mobl1>
Message-ID: <972851D2-7F52-4CF0-916C-CB63C7749E2E@qt.io>


> On 30 Aug 2017, at 21:45, Thiago Macieira <thiago.macieira at intel.com> wrote:
> 
> When writing the 5.6.3 changelog, I'm currently leaving it with:
> 
> ******************************************************************************
> *                     Important Behavior Changes                             *
> ******************************************************************************
> 
> - QCryptographicHash:
>   * [QTBUG-59770] QCryptographicHash now properly calculates SHA3 message
>     digests. Before, when asked to calculate a SHA3 digest, it calculated
>     a Keccak digest instead.
> 
> I think this is bad for the 5.6.3 release. After 5.9.0 was released, we had a 
> couple of people asking for the ability to calculate Keccak instead of SHA3 
> because they needed to compare against stored hashes that had been 
> (incorrectly) calculated using Keccak.
> 
> So I think we need to take action here. But what?
> 
> a) revert the 5.6 backport of 88a8feeacb9bdaff9ee06164424e407eb904cd10 so 
> that 5.6.x will forever calculate Keccak, not SHA3;
> 
> b) additionally backport 12c5264d9add1826d543c36d893db77262195fc6 to both 5.6 
> and 5.9, with the proper binary compatibility notices, so that people who need 
> to can adapt their code to calculate Keccak. It won't be pretty, but it will 
> work.
> 
> I'm actually leaning towards (a) for 5.6 and (b) for 5.9.

Fully agree. That's IMO the best solution.

Cheers,
Lars



From thiago.macieira at intel.com  Thu Aug 31 08:57:07 2017
From: thiago.macieira at intel.com (Thiago Macieira)
Date: Wed, 30 Aug 2017 23:57:07 -0700
Subject: [Development] Backporting the Keccak change
In-Reply-To: <972851D2-7F52-4CF0-916C-CB63C7749E2E@qt.io>
References: <14896643.VvgrSxGg5G@tjmaciei-mobl1>
	<972851D2-7F52-4CF0-916C-CB63C7749E2E@qt.io>
Message-ID: <2676035.hm0f2dkHE0@tjmaciei-mobl1>

On Wednesday, 30 August 2017 23:12:40 PDT Lars Knoll wrote:
> > a) revert the 5.6 backport of 88a8feeacb9bdaff9ee06164424e407eb904cd10 so
> > that 5.6.x will forever calculate Keccak, not SHA3;
> > 
> > b) additionally backport 12c5264d9add1826d543c36d893db77262195fc6 to both
> > 5.6 and 5.9, with the proper binary compatibility notices, so that people
> > who need to can adapt their code to calculate Keccak. It won't be pretty,
> > but it will work.
> > 
> > I'm actually leaning towards  for 5.6 and (b) for 5.9.
> 
> Fully agree. That's IMO the best solution.

5.6 reversal: https://codereview.qt-project.org/204143. Needs to be +2'ed and 
included in the 5.6.3 release.

5.9 backport: https://codereview.qt-project.org/204144

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center



From volker.krause at kdab.com  Thu Aug 31 10:28:19 2017
From: volker.krause at kdab.com (Volker Krause)
Date: Thu, 31 Aug 2017 10:28:19 +0200
Subject: [Development] [fix]: Assistant (and others) burning CPU because
 of #f27d1ccbb24ec2fd4098f2976503478831006cc8 ?
In-Reply-To: <3310125.43yb58AKty@tjmaciei-mobl1>
References: <1600335.9fNCGNT7fm@portia.local>
	<26466282.mM2nPz0K5z@portia.local>
	<3310125.43yb58AKty@tjmaciei-mobl1>
Message-ID: <3083305.vWQImSSsdo@vkpc19>

On Thursday, 31 August 2017 00:13:43 CEST Thiago Macieira wrote:
> On Wednesday, 30 August 2017 14:17:05 PDT René J. V. Bertin wrote:
> > Thiago Macieira wrote:
> > 
> > Oops, missed this one.
> > 
> > > Unfortunately, we can't change anymore.
> > 
> > Can someone explain what could possibly be broken by changing this? Can
> > the
> > current base-level QObject::timerEvent() be used for anything constructive
> > other than heating the office or preventing a CPU core from going to
> > sleep?
> > I only made my suggestion because it seemed rather evident that anyone
> > using the QObject timer would override the timerEvent() method.
> 
> It makes QTimer possible.
> 
> void QTimer::start()
> {
>     if (id != INV_TIMER)                        // stop running timer
>         stop();
>     nulltimer = (!inter && single);
>     id = QObject::startTimer(inter, Qt::TimerType(type));
> }
> 
> That sounds quite important to me :-)
> 
> QBasicTimer also used it until f821d6352e384a737c82a0db903104ec4f8611bd,
> when Brad wrote "QBasicTimer becomes even more low-level. It cannot use
> QObject::startTimer() anymore, since we do not have a way to call
> QObject::killTimer() from QBasicTimer::stop()."
> 
> On a serious note, there's a lot of code that uses startTimer() to get
> timers more efficiently than QTimer or even QBasicTimer. We can't remove
> this function, because it would break the existing code. And we can't make
> it a single shot because it would be even worse: it would silently would
> equally break existing code that expects the timer to repeat itself. This
> code is probably buried deep into codebases several years old and not that
> trivial to find.
> 
> And I don't want to add a flag to say it's a single shot to the event
> dispatcher, because it would add overhead for all existing timers. Not to
> mention it's not doable until Qt 6 when we can add or modify virtual methods
> to QAbstractEventDispatcher.
> 
> > That said, it does seem a bit overkill to give each and every instance
> > inheriting QObject timer features. Most will presumably never use that in
> > a
> > typical application, would they?
> 
> Most won't. How do you choose which ones should get the feature? If you're
> arguing for a white list, please compile such al ist, including all uses in
> KDE code, all applications, etc.
> 
> And how would we even achieve this? The only way I can think of is to make
> those functions private (a Qt 6 change) and add the whitelisted classes as
> friends.
> 
> > Found the bug/fix? The usual way, reverting all changes and restoring them
> > in order of least likely culprit. Then by generating trace output,
> > evidently I thought last of putting it *before* the timer ID check, and
> > then I had to consult the docs to confirm that one indeed needs to kill
> > the
> > timer when done. I'd never have guessed that a noop event handler callback
> > could have pump this many resources.
> 
> Ok, so you found by git bisect (or similar) action. I was hoping you had
> some interesting way of debugging that the problem is timers constantly
> firing. I woder if GammaRay can give you a list of timers active in a
> thread and which objects it's connected to. Volker?

There's the timer inspector in GammaRay, which indeed should help in this 
scenario. It's not the most polished tool, but it can list all QTimer and QML 
Timer instances, as well as all QObjects receiving timer events, and the 
corresponding timer frequencies.

For timer objects it allows you to switch to the corresponding view in the 
object browser (via context menu), where you see the outbound connections 
(this seems broken for timer event receivers atm). We don't have a filter per 
thread yet though.

Regards,
Volker
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4664 bytes
Desc: not available
URL: <http://lists.qt-project.org/pipermail/development/attachments/20170831/902ad27d/attachment.bin>

From rjvbertin at gmail.com  Thu Aug 31 10:35:08 2017
From: rjvbertin at gmail.com (=?UTF-8?B?UmVuw6kgSi4gVi4=?= Bertin)
Date: Thu, 31 Aug 2017 10:35:08 +0200
Subject: [Development] [fix]: Assistant (and others) burning CPU because
 of #f27d1ccbb24ec2fd4098f2976503478831006cc8 ?
References: <1600335.9fNCGNT7fm@portia.local>
	<3310125.43yb58AKty@tjmaciei-mobl1>
	<2110720.0gcV5EGXb5@portia.local>
	<15672475.ZeCjxWMBSd@tjmaciei-mobl1>
Message-ID: <2627922.CcfbcHxbdV@patux.local>

Thiago Macieira wrote:

>> I guess so :) I still don't get what purpose calling QObject::timerEvent()
>> has if the method itself does nothing. Gives me something to ponder.
> 
> Again, that's what makes QTimer possible.
> 
> void QTimer::timerEvent(QTimerEvent *e)
> {
>     if (e->timerId() == id) {
>         if (single)
>             stop();
>         emit timeout(QPrivateSignal());
>     }
> }

That's QTimer's override of QObject::timerEvent(), from kernel/qtimer.cpp . What 
I thought of was a simple security for classes that inherit QObject but don't 
override timerEvent(), something like this:

void QObject::timerEvent(QTimerEvent *e)
{
    if (m_timerInterval == 0 && e->timerId() == m_timerId) {
        killTimer(m_timerId);
    }
}

I see now that's not as trivial as I though since a single QObject can have any 
number of associated timers (at some level I knew that of course). 

> This is the same as any event override in Qt, which is basically the same as
> any virtual function override in C++. The overriding function gets to decide
> whether it needs to call the base implementation for something.
> 
> QObject::timerEvent does nothing, but other QObject::xxxEvent functions might,
> ditto for QWidget::xxxEvent().

Exactly. 

> Source compatibility. Which is why it's unlikely we'll do it.

Qt6 isn't going to break anything that builds against a sufficiently recent Qt5 
version?

>> class QFoo : public QObject, public QObjectTimer

> That said, it's not a horrible idea to move this out of QObject.

There are of course those who are horrified by the concept of multiple 
inheritance but it looks a bit late to start worrying about that :)

>> I did try monitoring the process with Instruments but that failed to attach.
> 
> But how did you find out it was a timer? And that it was a timer in
> QCocoaMenu?

Well, that's because I knew I had changed nothing else used by the offending 
application. Remember, I just merged upstream changes to the Cocoa QPA into my 
own standalone copy so this time that little project of mine really served a 
foolproofing purpose. It was trivial to put back the previous version of the 
plugin, start the application and confirm that it didn't show the issue. Then I 
just had to bisect. To be honest, looking at the commit log I had already 
deduced that it could in fact only be this change (I've written my own timers in 
the past). I'd have saved myself a lot of time if I hadn't decided to be clever 
but instead put qInfo probes at each and every turn of the new code.

Come to think of it, it's actually logical that a timer with interval=0 can take 
up all available resources ... when the event loop is idle. Gives a new 
interpretation to the term busy-waiting. I wonder if it could be put to good use 
in applications that must always react in "realtime" to user input, no matter 
how much change the application has had to be swapped out, demoted etc.

(All this reminded me of a fantasy novel I read long ago, involving a kind of 
flywheel capable of eating up all magical manna in the area by just spinning ever 
faster. Can't remember the title, pity.)

R.



From rjvbertin at gmail.com  Thu Aug 31 10:43:08 2017
From: rjvbertin at gmail.com (=?ISO-8859-1?Q?Ren=E9_J=2EV=2E?= Bertin)
Date: Thu, 31 Aug 2017 10:43:08 +0200
Subject: [Development] NSMenu validation,
 QCocoaMenu and button (context etc) menus
Message-ID: <2901599.GCSkX7fTQK@bola>

Hi,

Re: change which caused the CPU burning issue I discovered a couple of days back ("[fix]: Assistant (and others) burning CPU because of #f27d1ccbb24ec2fd4098f2976503478831006cc8 ?"). It intrigued me why an application that doesn't use native Mac menus would be calling [NSMenu update] at all. 

I now know that the menu which triggered the scheduled NSMenu update is one that is attached to a button but that is also installed as the Dock menu. I guess that explains why its QMenu items have corresponding QCocoaMenu items.

If [NSMenu update] is expensive enough that it was put on a timer, is it certain that it's only being called when required, i.e. only for menus attached to the native menubar or possibly the application's dock tile? I haven't seen it being called in other cases like context menus and menus that are part of a non-native menubar, do those even (need to) get a QCocoaMenu instance associated with them?

R.

On Tuesday August 29 2017 02:02:59 Gabriel de Dietrich wrote:
> FYI: QCocoaMenu: Stop update timer (Merged)<https://codereview.qt-project.org/203791>
> 
> Best regards,
> 
> Dr. Gabriel de Dietrich
> Senior Software Developer
> The Qt Company
> 
> On Aug 29, 2017, at 9:00 AM, Thiago Macieira <thiago.macieira at intel.com<mailto:thiago.macieira at intel.com>> wrote:
> 
> On Monday, 28 August 2017 17:06:18 PDT René J.V. Bertin wrote:
>        killTimer(m_updateTimer);
> 
> before setting m_updateTimer=0? Whether or not it's appropriate, this does
> solve the CPU burning for me.
> 
> Yeah, if you don't kill the timer, it will keep firing.
> 
> --
> Thiago Macieira - thiago.macieira (AT) intel.com<http://intel.com>
>  Software Architect - Intel Open Source Technology Center
> 
> _______________________________________________
> Development mailing list
> Development at qt-project.org<mailto:Development at qt-project.org>
> http://lists.qt-project.org/mailman/listinfo/development
> 


From lars.knoll at qt.io  Thu Aug 31 11:00:06 2017
From: lars.knoll at qt.io (Lars Knoll)
Date: Thu, 31 Aug 2017 09:00:06 +0000
Subject: [Development] Backporting the Keccak change
In-Reply-To: <2676035.hm0f2dkHE0@tjmaciei-mobl1>
References: <14896643.VvgrSxGg5G@tjmaciei-mobl1>
	<972851D2-7F52-4CF0-916C-CB63C7749E2E@qt.io>
	<2676035.hm0f2dkHE0@tjmaciei-mobl1>
Message-ID: <4431755C-138B-46C6-B1E6-000D8DCB7E28@qt.io>


On 31 Aug 2017, at 08:57, Thiago Macieira <thiago.macieira at intel.com<mailto:thiago.macieira at intel.com>> wrote:

On Wednesday, 30 August 2017 23:12:40 PDT Lars Knoll wrote:
a) revert the 5.6 backport of 88a8feeacb9bdaff9ee06164424e407eb904cd10 so
that 5.6.x will forever calculate Keccak, not SHA3;

b) additionally backport 12c5264d9add1826d543c36d893db77262195fc6 to both
5.6 and 5.9, with the proper binary compatibility notices, so that people
who need to can adapt their code to calculate Keccak. It won't be pretty,
but it will work.

I'm actually leaning towards  for 5.6 and (b) for 5.9.

Fully agree. That's IMO the best solution.

5.6 reversal: https://codereview.qt-project.org/204143. Needs to be +2'ed and
included in the 5.6.3 release.

5.9 backport: https://codereview.qt-project.org/204144

Thanks. Reviewed and approved both.

Lars

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20170831/e2ac8a5b/attachment.html>

From sergio.martins at kdab.com  Thu Aug 31 11:08:49 2017
From: sergio.martins at kdab.com (Sergio Martins)
Date: Thu, 31 Aug 2017 10:08:49 +0100
Subject: [Development] 
 =?utf-8?q?=5Bfix=5D=3A_Assistant_=28and_others=29_?=
 =?utf-8?q?burning_CPU_because_of_=23f27d1ccbb24ec2fd4098f2976503478831006?=
 =?utf-8?q?cc8_=3F?=
In-Reply-To: <3310125.43yb58AKty@tjmaciei-mobl1>
References: <1600335.9fNCGNT7fm@portia.local>
	<9009568.Ri8CIgFy91@tjmaciei-mobl1> <26466282.mM2nPz0K5z@portia.local>
	<3310125.43yb58AKty@tjmaciei-mobl1>
Message-ID: <1669438a513740eb2a38e57e2146903b@kdab.com>

On 2017-08-30 23:13, Thiago Macieira wrote:
> Ok, so you found by git bisect (or similar) action. I was hoping you 
> had some
> interesting way of debugging that the problem is timers constantly 
> firing. I
> woder if GammaRay can give you a list of timers active in a thread and 
> which
> objects it's connected to. Volker?

Interesting way such as LTTNG/ETW :) ? 
https://codereview.qt-project.org/#/c/185287/

The best of this is that you can co-relate the timer emissions with CPU 
and IO usage and visualize in a nice GUI.


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 edward.welbourne at qt.io  Thu Aug 31 11:27:30 2017
From: edward.welbourne at qt.io (Edward Welbourne)
Date: Thu, 31 Aug 2017 09:27:30 +0000
Subject: [Development] [fix]: Assistant (and others) burning CPU because
 of #f27d1ccbb24ec2fd4098f2976503478831006cc8 ?
In-Reply-To: <2627922.CcfbcHxbdV@patux.local>
References: <1600335.9fNCGNT7fm@portia.local>
	<3310125.43yb58AKty@tjmaciei-mobl1>	<2110720.0gcV5EGXb5@portia.local>
	<15672475.ZeCjxWMBSd@tjmaciei-mobl1>,<2627922.CcfbcHxbdV@patux.local>
Message-ID: <AM4PR02MB3249CDEE003D1C02B0AAEE8D879D0@AM4PR02MB3249.eurprd02.prod.outlook.com>

Thiago Macieira wrote:
>> Source compatibility. Which is why it's unlikely we'll do it.

René J. V. Bertin 31 August 2017 10:35
> Qt6 isn't going to break anything that builds against a sufficiently
> recent Qt5 version?

I doubt that; but the fact that we may break SC at Qt6 doesn't
necessarily mean we take in every SC-breaking change that's proposed.
Even when we do allow ourselves to break SC, we review each change that
breaks it to decide whether it's really worth the pain it'll cause for
the folk who'll need to change their source code in response to it.
After all, the more we break SC, the more existing codebases delay
upgrading.  Which is why it's unlikely ('though not forbidden),

	Eddy.


From rjvbertin at gmail.com  Thu Aug 31 15:47:58 2017
From: rjvbertin at gmail.com (=?UTF-8?B?UmVuw6kgSi4gVi4=?= Bertin)
Date: Thu, 31 Aug 2017 15:47:58 +0200
Subject: [Development] [fix]: Assistant (and others) burning CPU because
 of #f27d1ccbb24ec2fd4098f2976503478831006cc8 ?
References: <1600335.9fNCGNT7fm@portia.local>
	<9009568.Ri8CIgFy91@tjmaciei-mobl1>
	<26466282.mM2nPz0K5z@portia.local>
	<3310125.43yb58AKty@tjmaciei-mobl1>
	<1669438a513740eb2a38e57e2146903b@kdab.com>
Message-ID: <9036514.L4IvNaPzoi@portia.local>

Sergio Martins wrote:

> Interesting way such as LTTNG/ETW :) ?

Spoiler alert: not on Mac ...

R.



From annulen at yandex.ru  Thu Aug 31 15:50:19 2017
From: annulen at yandex.ru (Konstantin Tokarev)
Date: Thu, 31 Aug 2017 16:50:19 +0300
Subject: [Development] [fix]: Assistant (and others) burning CPU because
 of #f27d1ccbb24ec2fd4098f2976503478831006cc8 ?
In-Reply-To: <9036514.L4IvNaPzoi@portia.local>
References: <1600335.9fNCGNT7fm@portia.local>
	<9009568.Ri8CIgFy91@tjmaciei-mobl1>
	<26466282.mM2nPz0K5z@portia.local>
	<3310125.43yb58AKty@tjmaciei-mobl1>
	<1669438a513740eb2a38e57e2146903b@kdab.com>
	<9036514.L4IvNaPzoi@portia.local>
Message-ID: <210671504187419@web28g.yandex.ru>



31.08.2017, 16:48, "René J. V. Bertin" <rjvbertin at gmail.com>:
> Sergio Martins wrote:
>
>>  Interesting way such as LTTNG/ETW :) ?
>
> Spoiler alert: not on Mac ...

Mac has DTrace

>
> R.
>
> _______________________________________________
> Development mailing list
> Development at qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development

-- 
Regards,
Konstantin


From edward.welbourne at qt.io  Thu Aug 31 16:24:45 2017
From: edward.welbourne at qt.io (Edward Welbourne)
Date: Thu, 31 Aug 2017 14:24:45 +0000
Subject: [Development] [fix]: Assistant (and others) burning CPU because
 of #f27d1ccbb24ec2fd4098f2976503478831006cc8 ?
In-Reply-To: <210671504187419@web28g.yandex.ru>
References: <1600335.9fNCGNT7fm@portia.local>
	<9009568.Ri8CIgFy91@tjmaciei-mobl1>	<26466282.mM2nPz0K5z@portia.local>
	<3310125.43yb58AKty@tjmaciei-mobl1>
	<1669438a513740eb2a38e57e2146903b@kdab.com>
	<9036514.L4IvNaPzoi@portia.local>,<210671504187419@web28g.yandex.ru>
Message-ID: <AM4PR02MB32491040C75BAFCF46AE7143879D0@AM4PR02MB3249.eurprd02.prod.outlook.com>

>>>  Interesting way such as LTTNG/ETW :) ?

>> Spoiler alert: not on Mac ...

Konstantin Tokarev (31 August 2017 15:50)
> Mac has DTrace

Do we have anyone eager to follow up on the LLTNG/ETW work
(see earlier mail in this thread for link), adding DTrace for Mac ?

	Eddy.


From thiago.macieira at intel.com  Thu Aug 31 16:58:37 2017
From: thiago.macieira at intel.com (Thiago Macieira)
Date: Thu, 31 Aug 2017 07:58:37 -0700
Subject: [Development] [fix]: Assistant (and others) burning CPU because
 of #f27d1ccbb24ec2fd4098f2976503478831006cc8 ?
In-Reply-To: <2627922.CcfbcHxbdV@patux.local>
References: <1600335.9fNCGNT7fm@portia.local>
	<15672475.ZeCjxWMBSd@tjmaciei-mobl1>
	<2627922.CcfbcHxbdV@patux.local>
Message-ID: <23507335.c3Mmt2U9Wl@tjmaciei-mobl1>

On Thursday, 31 August 2017 01:35:08 PDT René J. V. Bertin wrote:
> > Source compatibility. Which is why it's unlikely we'll do it.
> 
> Qt6 isn't going to break anything that builds against a sufficiently recent
> Qt5 version?

See the other email where I said that this changing this is likely to break 
code that is sufficiently old and hard to fix (usually because of its age).

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center



From rjvbertin at gmail.com  Thu Aug 31 17:01:11 2017
From: rjvbertin at gmail.com (=?UTF-8?B?UmVuw6kgSi4gVi4=?= Bertin)
Date: Thu, 31 Aug 2017 17:01:11 +0200
Subject: [Development] [fix]: Assistant (and others) burning CPU because
 of #f27d1ccbb24ec2fd4098f2976503478831006cc8 ?
References: <1600335.9fNCGNT7fm@portia.local>
	<9009568.Ri8CIgFy91@tjmaciei-mobl1>
	<26466282.mM2nPz0K5z@portia.local>
	<3310125.43yb58AKty@tjmaciei-mobl1>
	<1669438a513740eb2a38e57e2146903b@kdab.com>
	<9036514.L4IvNaPzoi@portia.local>
	<210671504187419@web28g.yandex.ru>
	<AM4PR02MB32491040C75BAFCF46AE7143879D0@AM4PR02MB3249.eurprd02.prod.outlook.com>
Message-ID: <13394445.Mmbe05D18A@portia.local>

Edward Welbourne wrote:

>>>>  Interesting way such as LTTNG/ETW :) ?
> 
>>> Spoiler alert: not on Mac ...
> 
> Konstantin Tokarev (31 August 2017 15:50)
>> Mac has DTrace
> 
> Do we have anyone eager to follow up on the LLTNG/ETW work
> (see earlier mail in this thread for link), adding DTrace for Mac ?

I don't use that often, in part because dtrace must be run as root. However, I 
think that the instruments from Instruments.app use that facility in a way that 
allows the instrumented application to be run as a regular user. If true than 
writing such an instrument (module?) would probably be the way to go.

Needless to say such a module would need to be signed and possibly have special 
permissions that Apple might not want to sell. (Although one can build lldb and 
use a self-signed certificate to sign and get a functional debug server.)

R.