[Development] Request to move qt-labs/qhttpserver out of qt-labs

2020-02-02 Thread Mikhail Svetkin
Hello, I would like to make request to move qthttpserver from qt-labs namespace to a new namespace qt-addons or qt-extensions. The main reason is that it is not a research project anymore. I believe that the module is ready to become a self contained library as part of Qt Project and a good

Re: [Development] Changes to Qt offering

2020-02-02 Thread Bogdan Vatra via Development
În ziua de duminică, 2 februarie 2020, la 13:14:13 EET, Ville Voutilainen a scris: > On Wed, 29 Jan 2020 at 18:11, Volker Hilsheimer wrote: > > I wonder where all this love for the Qt installer comes from. I personally > > consider “sudo apt-get install -y qtcreator” or “brew install

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

2020-02-02 Thread Jani Heikkinen
I did sent that query already last Wed, see https://lists.qt-project.org/pipermail/development/2020-January/038454.html Eddy was only one who replied & listed few changes which were still missing. Last one of those went in during weekend so all should be Ok and that's why I announce the freeze

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

2020-02-02 Thread Thiago Macieira
On Sunday, 2 February 2020 21:35:38 PST Jani Heikkinen wrote: > Qt 5.15 Feature Freeze is in effect now. So no new features in '5.15' > anymore. Please update Qt 5.15 new features page > (https://wiki.qt.io/New_Features_in_Qt_5.15) now; it seems to be quite > empty still... > > Target is to

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

2020-02-02 Thread Jani Heikkinen
Hi all, Qt 5.15 Feature Freeze is in effect now. So no new features in '5.15' anymore. Please update Qt 5.15 new features page (https://wiki.qt.io/New_Features_in_Qt_5.15) now; it seems to be quite empty still... Target is to publish Qt 5.15 Alpha as soon as possible; Let's see if we can get

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

2020-02-02 Thread Giuseppe D'Angelo via Development
On 02/02/2020 22:45, André Pönitz wrote: This is a logical fallacy; "I don't need it, noone else does". But this is the argument the de-Qt-ers use when it comes to Qt convenience they don't need. Which Qt convenience in particular? I seem to be advocating against duplication "for the sake of

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

2020-02-02 Thread Daniel Teske
Am 02.02.2020 um 18:17 schrieb Иван Комиссаров: Can we please return to the discussion about QObject parent/child with smart pointers rather than discussing Qt/stl naming? No one answered my question about QObject::deleteLater: And what about the QObject::deleteLater() method? Any ideas how

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

2020-02-02 Thread André Pönitz
On Sun, Feb 02, 2020 at 07:55:09PM +0100, Giuseppe D'Angelo via Development wrote: > On 02/02/2020 17:38, Alberto Mardegan wrote: > > On 01/02/20 15:32, Giuseppe D'Angelo via Development wrote: > > > Il 01/02/20 12:37, Alberto Mardegan ha scritto: > > > > Do we need to have such a counterpart? In

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

2020-02-02 Thread Giuseppe D'Angelo via Development
On 02/02/2020 21:26, Alberto Mardegan wrote: This is a logical fallacy; "I don't need it, noone else does". Yes, but it's a logical fallacy you yourself made up Excuse me? In my work experience, when I'm not allowed to use Qt and am restricted to the STL, all the times I had to use

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

2020-02-02 Thread Alberto Mardegan
On 02/02/20 21:55, Giuseppe D'Angelo via Development wrote: > On 02/02/2020 17:38, Alberto Mardegan wrote: >> Believe it or not :-) I find std::shared_ptr easier to use when passing >> pointers to and from functions. And I never needed to put them into an >> array. > > This is a logical fallacy;

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

2020-02-02 Thread Ville Voutilainen
On Sun, 2 Feb 2020 at 19:19, Иван Комиссаров wrote: > > Can we please return to the discussion about QObject parent/child with smart > pointers rather than discussing Qt/stl naming? > > No one answered my question about QObject::deleteLater: > > > And what about the QObject::deleteLater()

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

2020-02-02 Thread Giuseppe D'Angelo via Development
On 02/02/2020 17:34, Alberto Mardegan wrote: On 01/02/20 15:02, Giuseppe D'Angelo via Development wrote: Il 01/02/20 12:44, Alberto Mardegan ha scritto: On 01/02/20 02:46, Giuseppe D'Angelo via Development wrote: About QUniquePointer: what's the point of reinventing std::unique_ptr under a

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

2020-02-02 Thread Giuseppe D'Angelo via Development
On 02/02/2020 17:38, Alberto Mardegan wrote: On 01/02/20 15:32, Giuseppe D'Angelo via Development wrote: Il 01/02/20 12:37, Alberto Mardegan ha scritto: Do we need to have such a counterpart? In my work experience, when I'm not allowed to use Qt and am restricted to the STL, all the times I

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

2020-02-02 Thread Giuseppe D'Angelo via Development
On 02/02/2020 18:17, Иван Комиссаров wrote: No one answered my question about QObject::deleteLater: And what about the QObject::deleteLater() method? Any ideas how this should look like with smart pointers? You can specify custom deleters for smart pointers. For QScopedPointer there's

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

2020-02-02 Thread Иван Комиссаров
Can we please return to the discussion about QObject parent/child with smart pointers rather than discussing Qt/stl naming? No one answered my question about QObject::deleteLater: > And what about the QObject::deleteLater() method? Any ideas how this should > look like with smart pointers?

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

2020-02-02 Thread Ville Voutilainen
On Sun, 2 Feb 2020 at 18:40, Alberto Mardegan wrote: > The STL could still add a method made up of two words in the future, and > it's unlikely that they'll use camelCase (or that they'd accept a > camelCase variant). Unlikely to the point that it's safe to bet against it.

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

2020-02-02 Thread Alberto Mardegan
On 01/02/20 15:32, Giuseppe D'Angelo via Development wrote: > Il 01/02/20 12:37, Alberto Mardegan ha scritto: >> Do we need to have such a counterpart? In my work experience, when I'm >> not allowed to use Qt and am restricted to the STL, all the times I had >> to use std::unique_ptr was to get

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

2020-02-02 Thread Alberto Mardegan
On 01/02/20 15:02, Giuseppe D'Angelo via Development wrote: > Il 01/02/20 12:44, Alberto Mardegan ha scritto: >> On 01/02/20 02:46, Giuseppe D'Angelo via Development wrote: >>> About QUniquePointer: what's the point of reinventing std::unique_ptr >>> under a different name? >> >> A Qt-ish API! >

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

2020-02-02 Thread Ville Voutilainen
On Sun, 2 Feb 2020 at 01:14, Giuseppe D'Angelo via Development wrote: > With this I can totally agree. As I said countless times, the only way > to influence such naming decisions is working _with_ upstream (by the > way, the meetings are pretty much public) and bringing your arguments on >

Re: [Development] Changes to Qt offering

2020-02-02 Thread Ville Voutilainen
On Wed, 29 Jan 2020 at 18:11, Volker Hilsheimer wrote: > I wonder where all this love for the Qt installer comes from. I personally > consider “sudo apt-get install -y qtcreator” or “brew install qt-creator” or > “choco install qtcreator" to be vastly superior to using the installer UI, > and

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

2020-02-02 Thread Daniel Teske
Pros I can see: 1) Qt style STL has different naming convention that looks alien to Qt API. It leads to inconsistency. The "Qt projects not using the standard library" era is over and the sooner that is understood the better. That inconsistency is just something to get used too Qt does

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

2020-02-02 Thread Christian Ehrlicher
Am 02.02.2020 um 01:00 schrieb Иван Комиссаров: I would also like to add the argument about templates. Qt API is still incompatible with STL in some places, so one cannot write a template function that simply calls STL variant. For example: QString foo; if (std::empty(foo)) // oops, fails to