Re: [Development] Nominating Mårten Nordheim and Timur Pocheptsov as new co-maintainers of Qt WebSocket

[Jesus Fernandez]

+1

El mar, 29 nov 2022 a las 14:56, Volker Hilsheimer via Development (<
development@qt-project.org>) escribió:

> Hi,
>
>
> Kurt Pattyn is currently listed as the Maintainer fo Qt WebSocket.
> However, he has not responded to emails I sent him over the last few
> months. In the middle of October I informed him that I will remove him as
> maintainer and nominate someone else unless I get a response. I cc’ed
> Mårten Nordheim in that email. Since I have not received any answer to that
> email either, I am now going to remove Kurt from the list of maintainers.
>
> And I’d like to nominate Mårten Nordheim and Timur Pocheptsov as
> co-maintainers. I’ve confirmed with them, and they would be ok with
> extending their existing co-maintainership of Qt Network to that module as
> well.
>
>
> Volker
>
> ___
> Development mailing list
> Development@qt-project.org
> https://lists.qt-project.org/listinfo/development
>
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Nominating Dimitrios "Jimis" Apostolou as Approver

[Jesus Fernandez]

+1 from me

El mié, 19 ene 2022 a las 13:00, Volker Hilsheimer ()
escribió:

> Hi,
>
> I’d like to nominate Dimitrios Apostolou, aka Jimis, as approver in the Qt
> Project.
>
> Jimis has been working as a Software Engineer in the Qt Company since 2019
> and has made a number of contributions [0] and reviews [1]. Most of his
> work happens in the build and test machinery and the infrastructure around
> it, which doesn’t leave a lot of traces in gerrit. I appreciate Jimis as a
> passionate, knowledgable, and open minded software developer and systems
> engineer, and I trust that he’ll use the approver status responsibly.
>
> Disclaimer: Jimis reports to me in The Qt Company.
>
>
> Volker
>
>
> [0] - https://codereview.qt-project.org/q/owner:jimis%2540qt.io
> [1] - https://codereview.qt-project.org/q/reviewedby:jimis%2540qt.io
>
> ___
> Development mailing list
> Development@qt-project.org
> https://lists.qt-project.org/listinfo/development
>
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Nominating Aleix Pol Gonzalez for approver status

[Jesus Fernandez]

+1

El jue, 18 feb 2021 a las 7:32, Eskil Abrahamsen Blomfeldt (<
eskil.abrahamsen-blomfe...@qt.io>) escribió:

> Hi all!
>
>
>
> I would like to nominate Aleix Pol Gonzalez as an approver for the Qt
> Project.
>
>
>
> Aleix has been a contributor to KDE and Qt for many years, touching on
> many different areas of Qt, and has lately been actively involved in Qt
> Wayland to help improve its position on the Linux desktop:
> https://codereview.qt-project.org/q/owner:aleixpol%2540kde.org
>
> Eskil Abrahamsen Blomfeldt
> Senior Manager, Graphics
>
> The Qt Company
> Sandakerveien 116
> 0484 Oslo, Norway
> eskil.abrahamsen-blomfe...@qt.io
> http://qt.io
>
> ___
> Development mailing list
> Development@qt-project.org
> https://lists.qt-project.org/listinfo/development
>
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Co-maintainer of QtNetwork

[Jesus Fernandez]

+1

El jue., 20 feb. 2020 a las 8:18, Alex Blasche ()
escribió:

> +1
>
> --
> Alex
>
> 
> From: Development  on behalf of Timur
> Pocheptsov 
> Sent: Thursday, 20 February 2020 06:48
> To: qt-dev
> Subject: [Development] Co-maintainer of QtNetwork
>
> Hi all,
>
> I want to propose a colleague of mine, Mårten Nordheim, as a co-maintainer
> of QtNetwork module with him
> becoming the maintainer of  „High-Level network access (HTTP)"* (which
> essentially means QNetworkAccessManager
> and related classes/code, sub-module 'access' etc.)  component and me
> continuing as the maintainer of  "Low-level
> access (Sockets, SSL, Hostname resolution, Bearer mgmt, etc)"**. Since the
> first day he joined the Qt Core
> and Network team several years ago, Mårten is making a significant
> contribution to the QtNetwork module, which
> includes numerous improvements and fixes in QNetworkAccessManager and also
> new developments (among other things
> he is the author of SChannel TLS backend on Windows). He has a good, solid
> knowledge of QtNetwork code/components
> and making him the maintainer "de jure" will help us (the Qt Core and
> Network team) to optimise and streamline the
> future developments in QtNetwork module.
>
> Best regards,
>Timur.
>
> * and ** - these are names taken from our wiki page on the Qt maintainers.
> ___
> Development mailing list
> Development@qt-project.org
> https://lists.qt-project.org/listinfo/development
>
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] qtwebglplugin fails to build in Coin on Windows (5.13.2 branch)

[Jesus Fernandez]

I don't have a Windows machine to test, but after checking the code, I see
no difference in the font database private API on Windows. The files were
not renamed, and the private module wasn't changed.

El jue., 24 oct. 2019 a las 2:22, Konstantin Tokarev ()
escribió:

> Following error had reproduced several times for me:
>
> qwebglintegration_p.h:43:10: fatal error:
> QtFontDatabaseSupport/private/qwindowsfontdatabase_p.h: No such file or
> directory
>
> Both MinGW and MSVC seem to be affected.
> Example build logs:
>
>
> https://testresults.qt.io/logs/qt/qtwebglplugin/87539f0467ac06174008e7eacaf2ba824b68351e/WindowsWindows_7x86WindowsWindows_7x86Mingw73qtci-windows-7-x86-3-b142bdDisableTests/58cdeff5cfc2360d3d8f7d496a8c2f08d3c92441/build_1571837037/log.txt.gz
>
>
> https://testresults.qt.io/logs/qt/qtwebglplugin/87539f0467ac06174008e7eacaf2ba824b68351e/WindowsWindows_10x86_64WindowsWindows_10x86_64MSVC2015qtci-windows-10-x86_64-14-61643fDisableTests/e8e1bb3c60e19e1ce500d948d1bcf0d385710421/build_1571867849/log.txt.gz
>
> --
> Regards,
> Konstantin
>
> ___
> Development mailing list
> Development@qt-project.org
> https://lists.qt-project.org/listinfo/development
>
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Proposal: Using Gerrit for new approver proposals?

[Jesus Fernandez]

+1.

We could have a document (maybe the README) with the list of current 
approvers/maintainers and submit a change request adding a new approver.

And, after testing the new Gerrit, I would love to use Gerrit more for decision 
making. The conversation workflow in Gerrit improved a lot in the new version. 
In the other hand, emails are far from optimal to discuss stuff.



Best regards,

Jesús


From: Development  on behalf of Florian 
Bruhin 
Sent: 20 May 2019 10:50
To: development@qt-project.org
Subject: [Development] Proposal: Using Gerrit for new approver proposals?

Hi,

As someone who's following this list but not working at the Qt Company, I find
the stream of "+1" emails when there's a new proposal for approval rights for
someone a bit noisy :)

What about using Gerrit to do so? I'm not sure how the repository would look
(probably just text files with the proposal text)? Then people could +1 that
change instead.

Just my $0.02 - it's not like I'd unsubscribe over this :)

Florian

--
https://www.qutebrowser.org | m...@the-compiler.org (Mail/XMPP)
   GPG: 916E B0C8 FD55 A072 | https://the-compiler.org/pubkey.asc
 I love long mails! | https://email.is-not-s.ms/
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Nominating Ryan Chu for Approvership

[Jesus Fernandez]

+1!




Best regards,

Jesús


From: Development  on behalf of Edward 
Welbourne 
Sent: 16 May 2019 10:58
To: Paul Wicking; development@qt-project.org
Subject: Re: [Development] Nominating Ryan Chu for Approvership

Another +1.

Disclaimer: I was his mentor and office-mate for his first year and a bit.

Eddy.


From: Development  on behalf of Paul 
Wicking 
Sent: 15 May 2019 13:11
To: development@qt-project.org
Subject: [Development] Nominating Ryan Chu for Approvership

I'd like to nominate Ryan Chu for approvership. He's been an active
contributor since January 2018, working mostly on the Docker-based test
server and network-related code. He is also an active reviewer, and his
manner of communication upholds the values as set forth by the Qt Code
of Conduct.

I know Ryan as a humble and honest person. I trust he will treat this
role with the utmost respect and care, as is required.


If you're curious, here's a list of his changes:

https://codereview.qt-project.org/#/q/owner:%22Ryan+Chu%22,n,z

and a list of changes he's on as a reviewer:

https://codereview.qt-project.org/#/q/reviewer:%22Ryan+Chu%22,n,z


Disclaimer: he sits 4 offices down the hall from me, and we're both on
the Core & Network team.


--
Paul Wicking
Documentation Engineer

The Qt Company
Sandakerveien 116
0484, Oslo, Norway
paul.wick...@qt.io
+47 90 500 666
http://qt.io
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Nominating Mikhail Svetkin for Approver status

[Jesus Fernandez]

+1!




Best regards,

Jesús


From: Development  on behalf of Martin 
Smith 
Sent: 17 May 2019 07:05
To: Lorn Potter; development@qt-project.org
Subject: Re: [Development] Nominating Mikhail Svetkin for Approver status

+1 from martin


From: Development  on behalf of Lorn Potter 

Sent: Friday, May 17, 2019 1:45 AM
To: development@qt-project.org
Subject: Re: [Development] Nominating Mikhail Svetkin for Approver status

+1

On 17/5/19 12:45 AM, Volker Hilsheimer wrote:
> I’d like to nominate Mikhail Svetkin for Approver status.

--
Lorn Potter
Freelance Qt Developer. Maintainer QtSensors, Qt WebAssembly

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

Re: [Development] CMake branch

[Jesus Fernandez]

> Could you explain the stated disadvantage further then?

It's just about more integrations due to the cmake related patches.



Best regards,

Jesús


From: Development  on behalf of Kari 
Oikarinen 
Sent: 21 March 2019 13:23
To: Mikhail Svetkin; development@qt-project.org
Subject: Re: [Development] CMake branch

Could you explain the stated disadvantage further then?

--
Kari

On 21.3.2019 14.21, Mikhail Svetkin wrote:
> It will not block CI.
>
>
>
>
> Best regards,
> Mikhail
> 
> *From:* Kari Oikarinen
> *Sent:* Thursday, March 21, 2019 1:13 PM
> *To:* Mikhail Svetkin; development@qt-project.org
> *Subject:* Re: [Development] CMake branch
>
>
> On 21.3.2019 14.00, Mikhail Svetkin wrote:
>> *
>>
>> *
>>
>> Hi everyone!
>>
>>
>> We’ve had an internal discussion about wip/cmake branch.
>>
>>
>> We thought maybe it is a good idea to merge wip/cmake into dev branch.
>>
>>
>> The advantages are:
>>
>>   - It allows our contributors to play with CMake in dev branch
>>
>>   - Speed-up the build of QtBase
>>
>>   - Easy to find a lot of bugs in CMake port
>>
>>   - CI could have a nightly build with CMake and generate a report
>>
>>   - We can synchronize CMakeFiles and *.pro files
>>
>>
>> The disadvantages are:
>>
>>   - Any changes should be passed by CI
>>
>>
>> Do you have any objections?
>>
>> **
>>
>
> Would this have blocking CI or not? The stated disadvantage (which surely
> shouldn't be entirely negative) implies that it would be. But the build being
> nightly hints that it would not be.
>
> A blocking build would mean that all changes need to leave the CMake build
> working. So everyone would need to take care of both build systems. A more
> defined transition point and only one official build system at a time would be
> nicer. Or at least trying to minimize the time of having two.
>
> Unless of course we'd already be ready to drop building Qt with qmake, but I
> guess that's not where we are yet. Is that expected to happen during 5.x 
> series
> at all or only with Qt 6?
>
> --
> Kari

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

Re: [Development] CMake branch

[Jesus Fernandez]

It should not be blocking for Qt 5.

We can generate a non-blocking integration report.


Best regards,

Jesús


From: Development  on behalf of Kari 
Oikarinen 
Sent: 21 March 2019 13:13
To: Mikhail Svetkin; development@qt-project.org
Subject: Re: [Development] CMake branch



On 21.3.2019 14.00, Mikhail Svetkin wrote:
> *
>
> *
>
> Hi everyone!
>
>
> We’ve had an internal discussion about wip/cmake branch.
>
>
> We thought maybe it is a good idea to merge wip/cmake into dev branch.
>
>
> The advantages are:
>
>   - It allows our contributors to play with CMake in dev branch
>
>   - Speed-up the build of QtBase
>
>   - Easy to find a lot of bugs in CMake port
>
>   - CI could have a nightly build with CMake and generate a report
>
>   - We can synchronize CMakeFiles and *.pro files
>
>
> The disadvantages are:
>
>   - Any changes should be passed by CI
>
>
> Do you have any objections?
>
> **
>

Would this have blocking CI or not? The stated disadvantage (which surely
shouldn't be entirely negative) implies that it would be. But the build being
nightly hints that it would not be.

A blocking build would mean that all changes need to leave the CMake build
working. So everyone would need to take care of both build systems. A more
defined transition point and only one official build system at a time would be
nicer. Or at least trying to minimize the time of having two.

Unless of course we'd already be ready to drop building Qt with qmake, but I
guess that's not where we are yet. Is that expected to happen during 5.x series
at all or only with Qt 6?

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

Re: [Development] Go's "defer" statement for C++/Qt

[Jesus Fernandez]

std::async(std::launch::deferred, ...);

?



Best regards,
Jesús


 Original message 
From: Tor Arne Vestbø 
Date: 07/03/2019 18:11 (GMT+01:00)
To: Volker Hilsheimer 
Cc: Qt development mailing list 
Subject: Re: [Development] Go's "defer" statement for C++/Qt

https://doc.qt.io/qt-5/qscopeguard.html 

Tor Arne

> On 7 Mar 2019, at 18:01, Volker Hilsheimer  wrote:
>
> Ahoy,
>
> In what little development I’ve done in golang, I appreciated the “defer” 
> statement as a means to write cleaner code. Basically, defer schedules a 
> statement for execution when the stack unwinds.
>
> https://tour.golang.org/flowcontrol/12
>
> We have several specialized helper classes in Qt for similar purposes, f.ex 
> QMutexLocker and friends, or the internal QBoolBlocker [1]. Seeing the 
> various specialized classes we have, I thought that something generic in Qt 
> could be useful to have (although our specialised classes provide some 
> additional convenience and/or logic).
>
> So, I pushed a few lines code to
>
> https://git.qt.io/vohilshe/qt_defer
>
> Would like to hear what you think.
>
> Perhaps someone can find ways to make this more elegant without introducing 
> tons of preprocessor/macro shenanigans, or perhaps even without depending on 
> C++17's implicit template argument deduction (without enabling C++17 in the 
> config this doesn't build for me, even though I don’t use auto in the 
> template paramter list).
>
>
> Cheers,
> Volker
>
>
> [1] which was requested to be made public in 
> https://bugreports.qt.io/browse/QTBUG-38575
>
>
> ___
> Development mailing list
> Development@qt-project.org
> https://lists.qt-project.org/listinfo/development

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

Re: [Development] Intention of dropping UWP 2015 x86 builds in favour of MinGW 32-bit packages

[Jesus Fernandez]

Hi!

The original mail said nothing about 5.12.2. And I would remove support for 
both compilers in 5.13. Any 32 bits is an outdated platform.



Best regards,

Jesús


From: Jani Heikkinen
Sent: 06 February 2019 12:54
To: Jesus Fernandez; Maurice Kalinowski; Simon Hausmann
Cc: development@qt-project.org
Subject: Re: [Development] Intention of dropping UWP 2015 x86 builds in favour 
of MinGW 32-bit packages

Hi!

>>And I think we started providing binaries for a platform in 5.12.0 we cannot 
>>stop providing them in 5.12.x.
I disagree. I agree we shouldn't do this kind of decisions without good reasons 
but I don't see anything why we couldn't do this kind of changes if there is 
good reasons. This is different issue than dropping support which we can't do 
in patch level releases...

 If we want to start delivering mingw32bit (which were dropped but it seems to 
be widely needed) then we need to drop something. It was proposed that UWP x86 
msvc 2015 prebuild binaries are replaced with mingw32 ones. PM sent proposal to 
the ML and no-one disagreed. Then we did the decision to do the switch... One 
needing UWP x86 for MSVC2015 can still compile those by himself.

br,
Jani
____
From: Jesus Fernandez
Sent: Wednesday, February 6, 2019 1:06 PM
To: Jani Heikkinen; Maurice Kalinowski; Simon Hausmann
Cc: development@qt-project.org
Subject: Re: [Development] Intention of dropping UWP 2015 x86 builds in favour 
of MinGW 32-bit packages

> I think what Jesus refers to is patch level releases.

Yes, I was referring to patch releases.

And I think we started providing binaries for a platform in 5.12.0 we cannot 
stop providing them in 5.12.x.


Best regards,

Jesús


From: Jani Heikkinen
Sent: 06 February 2019 11:02
To: Maurice Kalinowski; Simon Hausmann; Jesus Fernandez
Cc: development@qt-project.org
Subject: Re: [Development] Intention of dropping UWP 2015 x86 builds in favour 
of MinGW 32-bit packages

Hi,

As Simon already wrote this is affecting only prebuilt binary packages we 
deliver and nothing else. It is true that we usually haven't touched (at least 
removed) those in patch level releases but I don't see any big issue with doing 
this now; UWP x86 msvc 2015 isn't that widely used and feedback from dropping 
mingw 32 bit is coming just from 5.12 series...

br,
Jani

From: Development  on behalf of Maurice 
Kalinowski 
Sent: Wednesday, February 6, 2019 11:32 AM
To: Simon Hausmann; Jesus Fernandez
Cc: development@qt-project.org
Subject: Re: [Development] Intention of dropping UWP 2015 x86 builds in favour 
of MinGW 32-bit packages

I think what Jesus refers to is patch level releases.
We’ve been changing binary packages for platforms within minor releases so far, 
but not for patch level ones.

Maurice


From: Development  On Behalf Of Simon 
Hausmann
Sent: Wednesday, February 6, 2019 9:19 AM
To: Jesus Fernandez 
Cc: development@qt-project.org
Subject: Re: [Development] Intention of dropping UWP 2015 x86 builds in favour 
of MinGW 32-bit packages

Afaik this merely affects the binaries provided in the installer. It does not 
result in any changes in the git repos.
Simon

On 5. Feb 2019, at 16:03, Jesus Fernandez 
mailto:jesus.fernan...@qt.io>> wrote:
Can we remove a platform in a minor version?



Best regards,
Jesús


 Original message 
From: Harald Kjølberg mailto:harald.kjolb...@qt.io>>
Date: 05/02/2019 15:56 (GMT+01:00)
To: development@qt-project.org<mailto:development@qt-project.org>
Subject: Re: [Development] Intention of dropping UWP 2015 x86 builds in favour 
of MinGW 32-bit packages


Hi,

As no objections have been received, the proposed change will be implemented, 
effective from Qt 5.12.2.


Cheers,
Harald

From: Development 
mailto:development-boun...@qt-project.org>> 
on behalf of Harald Kjølberg 
mailto:harald.kjolb...@qt.io>>
Date: Tuesday, 22 January 2019 at 14:36
To: "development@qt-project.org<mailto:development@qt-project.org>" 
mailto:development@qt-project.org>>
Subject: [Development] Intention of dropping UWP 2015 x86 builds in favour of 
MinGW 32-bit packages


Hi,

In order to improve transparency and visibility (after getting some 
constructive and well deserved criticism):

We have received a proposal of dropping UWP 2015 x86 builds in favour of MinGW 
32-bit packages. We looked at this today and agreed that this can be done, and 
it should be our intention to do so. We will make the final decision February 
5th, and it will remain as described unless we get a lot of feedback saying 
that we should do otherwise.

For further details: https://bugreports.qt.io/browse/QTBUG-73019



Regards,
Harald Kjølberg

___
Development mailing list
Development@qt-project.org<mailto:Develop

Re: [Development] Intention of dropping UWP 2015 x86 builds in favour of MinGW 32-bit packages

[Jesus Fernandez]

> I think what Jesus refers to is patch level releases.

Yes, I was referring to patch releases.

And I think we started providing binaries for a platform in 5.12.0 we cannot 
stop providing them in 5.12.x.


Best regards,

Jesús


From: Jani Heikkinen
Sent: 06 February 2019 11:02
To: Maurice Kalinowski; Simon Hausmann; Jesus Fernandez
Cc: development@qt-project.org
Subject: Re: [Development] Intention of dropping UWP 2015 x86 builds in favour 
of MinGW 32-bit packages

Hi,

As Simon already wrote this is affecting only prebuilt binary packages we 
deliver and nothing else. It is true that we usually haven't touched (at least 
removed) those in patch level releases but I don't see any big issue with doing 
this now; UWP x86 msvc 2015 isn't that widely used and feedback from dropping 
mingw 32 bit is coming just from 5.12 series...

br,
Jani

From: Development  on behalf of Maurice 
Kalinowski 
Sent: Wednesday, February 6, 2019 11:32 AM
To: Simon Hausmann; Jesus Fernandez
Cc: development@qt-project.org
Subject: Re: [Development] Intention of dropping UWP 2015 x86 builds in favour 
of MinGW 32-bit packages

I think what Jesus refers to is patch level releases.
We’ve been changing binary packages for platforms within minor releases so far, 
but not for patch level ones.

Maurice


From: Development  On Behalf Of Simon 
Hausmann
Sent: Wednesday, February 6, 2019 9:19 AM
To: Jesus Fernandez 
Cc: development@qt-project.org
Subject: Re: [Development] Intention of dropping UWP 2015 x86 builds in favour 
of MinGW 32-bit packages

Afaik this merely affects the binaries provided in the installer. It does not 
result in any changes in the git repos.
Simon

On 5. Feb 2019, at 16:03, Jesus Fernandez 
mailto:jesus.fernan...@qt.io>> wrote:
Can we remove a platform in a minor version?



Best regards,
Jesús


 Original message 
From: Harald Kjølberg mailto:harald.kjolb...@qt.io>>
Date: 05/02/2019 15:56 (GMT+01:00)
To: development@qt-project.org<mailto:development@qt-project.org>
Subject: Re: [Development] Intention of dropping UWP 2015 x86 builds in favour 
of MinGW 32-bit packages


Hi,

As no objections have been received, the proposed change will be implemented, 
effective from Qt 5.12.2.


Cheers,
Harald

From: Development 
mailto:development-boun...@qt-project.org>> 
on behalf of Harald Kjølberg 
mailto:harald.kjolb...@qt.io>>
Date: Tuesday, 22 January 2019 at 14:36
To: "development@qt-project.org<mailto:development@qt-project.org>" 
mailto:development@qt-project.org>>
Subject: [Development] Intention of dropping UWP 2015 x86 builds in favour of 
MinGW 32-bit packages


Hi,

In order to improve transparency and visibility (after getting some 
constructive and well deserved criticism):

We have received a proposal of dropping UWP 2015 x86 builds in favour of MinGW 
32-bit packages. We looked at this today and agreed that this can be done, and 
it should be our intention to do so. We will make the final decision February 
5th, and it will remain as described unless we get a lot of feedback saying 
that we should do otherwise.

For further details: https://bugreports.qt.io/browse/QTBUG-73019



Regards,
Harald Kjølberg

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

Re: [Development] Intention of dropping UWP 2015 x86 builds in favour of MinGW 32-bit packages

[Jesus Fernandez]

Can we remove a platform in a minor version?



Best regards,
Jesús


 Original message 
From: Harald Kjølberg 
Date: 05/02/2019 15:56 (GMT+01:00)
To: development@qt-project.org
Subject: Re: [Development] Intention of dropping UWP 2015 x86 builds in favour 
of MinGW 32-bit packages


Hi,

As no objections have been received, the proposed change will be implemented, 
effective from Qt 5.12.2.


Cheers,
Harald

From: Development  on behalf of Harald 
Kjølberg 
Date: Tuesday, 22 January 2019 at 14:36
To: "development@qt-project.org" 
Subject: [Development] Intention of dropping UWP 2015 x86 builds in favour of 
MinGW 32-bit packages


Hi,

In order to improve transparency and visibility (after getting some 
constructive and well deserved criticism):

We have received a proposal of dropping UWP 2015 x86 builds in favour of MinGW 
32-bit packages. We looked at this today and agreed that this can be done, and 
it should be our intention to do so. We will make the final decision February 
5th, and it will remain as described unless we get a lot of feedback saying 
that we should do otherwise.

For further details: https://bugreports.qt.io/browse/QTBUG-73019



Regards,
Harald Kjølberg

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

[Development] Google Summer of Code 2019

[Jesus Fernandez]

Hi all,

Some of us have been discussing on IRC whether to apply again to the Google 
Summer of Code 2019, as The Qt Project.
The deadline for organizations to send applications is February 6th.
The current idea is that, unless there are strong objections against applying, 
we will try to submit an application on behalf of The Qt Project.

So, if you agree and have ideas please use the following wiki page to propose 
your project and/or assign yourself as a possible mentor in other interesting 
projects:
https://wiki.qt.io/index.php?title=Google_Summer_of_Code/2019/Project_Ideas
A lesson learned from last year's participation is that the candidate's skills 
are essential, so the goal will be to prioritize top candidates.

Please join also #qt-gsoc on Freenode to discuss the participation of The Qt 
Project to the Google Summer of Code 2019.
Once the application will be submitted and accepted, we would use the #qt-gsoc 
IRC channel for questions about procedure and projects.
Qt-related questions should still go to #qt-labs on IRC/freenode.
This mailing list is also a good place to propose or discuss GSoC projects.

I have also created a tentative landing page: 
https://wiki.qt.io/Google_Summer_of_Code/2019


Best regards,

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

Re: [Development] Qt 5.12 new features

[Jesus Fernandez]

Fixed!

WebGL plugin has no relevant changes for 5.12. Some stability & performance 
tweaks that are available also in 5.11.1.


Thank you!


Best regards,

Jesús



From: Development  on 
behalf of Jason H 
Sent: Thursday, August 16, 2018 16:02
Cc: development@qt-project.org
Subject: Re: [Development] Qt 5.12 new features

5.11 included WebGL TP2. Is there any change? Why is it staying TP2, or should 
it be TP3?

5.12 looks like it'll be a pretty great update!

I'm not sure what's on the agenda for 5.13... but as I mentioned on interest, 
one pain point I continually have is the amount of custom platform integrations 
for mobile. This is one area where Xamrain excels, as they have a simple 
property on an object you can set to control things like the status bar 
visibility, the screen brightness, etc. The downside is the Xamarin stuff is 
all platform-specific so using a iOS property on Android won't work. This is 
one area where Qt can leapfrog the other platforms including React Native by 
being cross platform. Anything that doesn't require me to write Obj-C is a very 
good thing!  I figure this would need to be a few Qt Quick/QObject Singletons. 
Notifications should be supported too, and this could also be used for desktop 
platform notifications as well. The notifications support would only need to 
cover being messaged my the platform, and not any display - this would get me 
out of having to deal with Obj-C almost completely. (My beef wi
 th ObjC is other than being not good at it, is whatever I'm writing isn't 
cross-platform. Java I am more comfortable with, so I complain less, but I 
still cringe on the non-portability!)

Looking forward to 5.12!

> Sent: Wednesday, August 15, 2018 at 12:50 AM
> From: "Jani Heikkinen" 
> To: "development@qt-project.org" 
> Subject: [Development] Qt 5.12 new features
>
> Hi,
>
> Qt 5.12 Feature Freeze will be in effect Mon 20th August and we should have 
> already now pretty good understanding what is new in Qt 5.12. So please 
> update 5.12 new features page here: https://wiki.qt.io/New_Features_in_Qt_5.12
>
> br,
> Jani
>
>
>
>
>
> ___
> Development mailing list
> Development@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development
>
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Nominating Mårten Nordheim as an approver

[Jesus Fernandez]

+1!




Best regards,

Jesús



From: Development  on 
behalf of Edward Welbourne 
Sent: Wednesday, April 25, 2018 13:40
To: development@qt-project.org
Subject: [Development] Nominating Mårten Nordheim as an approver

Hi all,

I'd like to nominate Mårten Nordheim for Approver.

We've had him here at TQtC, in the Core & Network team, for a bit over a
year; he's been reviewing steadily and finding mistakes I miss.  As well
as diverse work in qtbase, he's also dabbled in the qtnetworkauth and
qtwebsockets modules.  Here's his list of changes in gerrit:

https://codereview.qt-project.org/#/q/owner:"M%25C3%25A5rten+Nordheim",n,z
Gerrit Code 
Review
codereview.qt-project.org
Loading Gerrit Code Review... ... Qt Home; Qt Documentation; Qt-Project; Planet 
Qt; Qt Repository Browser




and the (somewhat busier) list of what he's reviewed:

https://codereview.qt-project.org/#/q/reviewer:"M%25C3%25A5rten+Nordheim",n,z

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

[Development] Setters: Clarifying the ownership

[Jesus Fernandez]

Hi all!

I always found something annoying in the Qt API. The problem comes with the 
setters of our properties. When I want to pass an object to a property I never 
know if I need to take care of the object or relay on parenting system to avoid 
memory leaks.
To know if the object is going to be reparented, I open the assistant and look 
for the setter to try to find the famous "takes ownership of" in the function 
description.

Mårten Nordheim and I were talking about possible solutions to this problem. 
Typical things came to the discussion:
- adding a macro like Q_TAKES_OWNERSHIP to the function that expands to nothing
- wrapping the parameters with a template class (gsl::owner)
- ...

After some discussion he came with the idea of add a different "verb" to the 
setter, replace "set" with "give". So when we are giving the ownership of an 
object to instead of setSomething(); we will write 
giveSomething(); I really like this solution, it will improve a lot the 
readability of the client (and internal) code.

For example: QCoreApplication::setEventDispatcher will be 
QCoreApplication::giveEventDispatcher.

Of course at the beginning this will be a new function and the old set* 
functions will be kept, but marked as deprecated.


--
Best regards,
Jesús
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Review for new widget module [your advices are needed]

[Jesus Fernandez]

Hello Iman,

I tried to give a try to this thing. I think you forgot to add a couple of 
files:
* style/palettes.h
* style/styleoption.h
--
Best regards,
Jesús


On 2017-10-14 09:33:52+02:00 iman ahmadvand wrote:

Hi everyone.
Before I send some code base on codereview and decide whether my implementation 
meets the requirements,  I  just want to know your thoughts about design 
decision for the new module I’m trying to add to Qt Play ground.
So as you probably guessed my plan is to developing a new widget module (which 
I’m going to name it MaterialWidgets) for Qt, a modern collection of widgets 
that should have the same look and feel on all platforms. All the GUI 
parameters and styles are taken from material style guide 
line(https://material.io/guidelines). You can think of MaterialWidgets as the 
MaterialStyle in QML design but in pure C++.
Here is a few things to clarify:
1.Why someone need to use material styled widgets in Qt?
There are a bunch of app out there that need this to be available on widgets so 
they can easily take the benefit of newly added widget set.
2.Why a new widget set? why just no to use already built-in styles?
Material widgets are going to be a special set of controls which has animations 
by default, and GUI parameters are differs from built-in QtWidgets. for an 
example material style has a component called ContinuousSlider which has two 
sub component Thumb and Track and two state On(value == 0) and Off(value != 0) 
and a color palette for each state, so doing this with styles can't be done 
unless we change the enumerators and maybe more!
3.Are every thing from scratch ?
No. not at all.
I just make some changes in inherited classes from built-in QtWidgets (basics 
AND abstracts), so the logics behind those widgets should be the same.
A note for animation implementation  in MaterialWidgets:
A class called Animation is responsible for animating those widgets, the simple 
idea behind that is to have a target object (which mostly is a widget) 
associated with animation objet and after every refresh in animation 
(updateCurrentValue) we should make an update of type StyleAnimationUpdate in 
target widget so it makes the code base more cleaner.
Here you can see just a review version of module (just ContinuousSlider is 
included): ​
[https://ssl.gstatic.com/docs/doclist/images/icon_10_generic_list.png] 
qtmaterialwidgets.zip
​
I'm ready to hear your advices and thoughts.
Regards
Iman.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] QtCloudMessaging repository request to Qt

[Jesus Fernandez]

With QtNetworkAuth + QNetworkAccessManager the Firebase C++ API is not needed. 
So it will remove this dependency and support more platforms than the platforms 
supported by the Firebase libs.

Thank you for the explanation :)

--
Best regards,
Jesús


On 2017-06-21 13:19:24+02:00 Ari Salmi wrote:

Hi Jesús,
Thanks for question and reaction!
Qt Cloud Messaging API itself is not dependent on QtNetworkAuth, but it can be 
backend-solution dependent.
e.g:
Google firebase backend solution for Android and iOS are using firebase's c++ 
binaries (which app developer should give env, path when compiling) and real 
communication goes through those elements.
Also in addition developer can create the cloud messaging server elements also 
with this same API, so I've included REST API interfaces (QtNetwork) to 
firebase and to  Kaltiot.com backends. Those needs (after Qt5.6) libssl and 
libcrypto libraries included in to the applications (included in the example).
Thanks,
Ari

br, Ari
Ari Salmi
SnowGrains<http://www.snowgrains.com>

2017-06-21 14:07 GMT+03:00 Jesus Fernandez 
<jesus.fernan...@qt.io<mailto:jesus.fernan...@qt.io>>:
Hi Ari,

Is your project dependent on QtNetworkAuth for dealing with Google API?

Best regards,
Jesús
--
Best regards,
Jesús


On 2017-06-21 12:59:05+02:00 Ari Salmi wrote:

Hi there,

I am developing a Qt API to wrap cloud push services to mobile apps and 
embedded devices.
This includes examples for using Google Firebase 
(firebase.google.com<http://firebase.google.com>) for mobile app development 
and similar a solution for embedded space as well (which has increasing demand).

For contribution to Qt the new repository is needed.

Name of the project:
Qt Cloud Messaging

Responsible person:
Ari Salmi / SnowGrains
gerrit username: snowgrains
gerrit email: snowgra...@snowgrains.com<mailto:snowgra...@snowgrains.com>

desired repository name:
qtcloudmessaging
Some background:
The closest match is the Qt Mobility's QMessaging service, which more or less 
concentrated to SMS, mms and email services inside a (nokia) phones taking care 
of the contacts etc. Unfortunately that API is not expandable to other 
platforms and cannot be used. One aim on this is to create Qt API that wraps 
(and developers can do more wrappers with same API) e.g. Google firebase, or 
onesignal type of push messaging services - for mobile and desktop apps.

More important aim is to provide similar messaging to/from iot and other 
embedded devices, like cars. This is the place where we are lacking the 
offering from the Qt point of view. One embedded backend solution that has 
scale able offering is Kaltiot.com. I've included it as one backend for 
embedded story.
Thank you and best regards,
Ari
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] QtCloudMessaging repository request to Qt

[Jesus Fernandez]

Hi Ari,

Is your project dependent on QtNetworkAuth for dealing with Google API?

Best regards,
Jesús
--
Best regards,
Jesús


On 2017-06-21 12:59:05+02:00 Ari Salmi wrote:

Hi there,

I am developing a Qt API to wrap cloud push services to mobile apps and 
embedded devices.
This includes examples for using Google Firebase 
(firebase.google.com) for mobile app development 
and similar a solution for embedded space as well (which has increasing demand).

For contribution to Qt the new repository is needed.

Name of the project:
Qt Cloud Messaging

Responsible person:
Ari Salmi / SnowGrains
gerrit username: snowgrains
gerrit email: snowgra...@snowgrains.com

desired repository name:
qtcloudmessaging
Some background:
The closest match is the Qt Mobility's QMessaging service, which more or less 
concentrated to SMS, mms and email services inside a (nokia) phones taking care 
of the contacts etc. Unfortunately that API is not expandable to other 
platforms and cannot be used. One aim on this is to create Qt API that wraps 
(and developers can do more wrappers with same API) e.g. Google firebase, or 
onesignal type of push messaging services - for mobile and desktop apps.

More important aim is to provide similar messaging to/from iot and other 
embedded devices, like cars. This is the place where we are lacking the 
offering from the Qt point of view. One embedded backend solution that has 
scale able offering is Kaltiot.com. I've included it as one backend for 
embedded story.
Thank you and best regards,
Ari
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

[Development] New repository for WebGL Streaming QPA plugin

[Jesus Fernandez]

Hi all!

I have been working on a QPA plugin to send the GLES2.0 calls from a host 
computer over the network to a WebGL capable browser. Now it's approaching a 
state in which it could be usable. For this, we'll need a new public repository.

Having a public and controlled repository could help the project to grow up 
significantly.

The name could be Qt WebGL Streaming (qt/qtwebglstreaming).
The current location of the project is 
https://git.qt.io/playground/qtwebglplugin

-- 

Best regards,
Jesus
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Request moving project to playground area

[Jesus Fernandez]

On Saturday, February 04, 2017 07:05:41 AM Hamed Masafi wrote:
> Why not using Q_PROPERTY instead of NUT_DECLARE_FIELD?
> 
> A property im table is more thsn a just Qt property, that macro create
> property and static field for query writing and class info about property
> to add to database.

To achieve this I think it's possible to use the property system + a custom 
subclass of QObject. If you want to expose this objects to QML you will need to 
declare a Q_PROPERTY, so It's not convenient.

> 
> And what's the reason to have a constructor as Q_INVOKABLE?
> 
> Andre right about that,

If you register the class as "MetaType" you will be able to create instances of 
the class using QMetaType::create().

> 
> Actually, there are more ORM solutions for Qt, e.g. QxOrm and QDjango
> 
> Yes, there are, either other languages/frameworks like .net and java has.
> But I really live Qt so I think it can be a good idea if prepare free one
> of them to integrate into Qt.
> 
> I think Nut is easy to use and feature rich (in alpha state for now) that
> support much database manager.
> 
> Some of them are complicated and some others are so simple to real using.
> We can provide a full feature module with LGPL to community use.
> 
> Excuses for my bad English, but I want give that tool to Qt community that
> very helped me. I want suggest two of my libraries to playground area.
> 
> After all of this, can I know your idea about an orm in playground area?

-- 

Best regards,
Jesus
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Request moving project to playground area

[Jesus Fernandez]

On Thursday, February 02, 2017 07:38:00 PM Hamed Masafi wrote:
> Declaring persistant objects in ORM is straightforward:
> 
> class Comment : public Table
> {
> Q_OBJECT
> 
> NUT_PRIMARY_AUTO_INCREMENT(id)
> NUT_DECLARE_FIELD(int, id, id, setId)
> NUT_DECLARE_FIELD(QString, message, message, setMessage)
> NUT_DECLARE_FIELD(QDateTime, saveDate, saveDate, setSaveDate)
> NUT_DECLARE_FIELD(qreal, point, point, setPoint)
> 
> NUT_FOREGION_KEY(Post, int, post, post, setPost)
> 
> public:
> Q_INVOKABLE explicit Comment(QObject *tableSet = 0);
> };

Why not using Q_PROPERTY instead of NUT_DECLARE_FIELD?

And what's the reason to have a constructor as Q_INVOKABLE?

-- 

Best regards,
Jesus
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development