Re: [Development] Deprecation/removal model going into Qt 6

2019-06-03 Thread Thiago Macieira
On Sunday, 2 June 2019 16:39:24 PDT Kevin Kofler wrote: > PS: Imagine the outcry and havoc if Intel decided to tell you, e.g.: "Sorry, > x87 floating-point is obsolete and hard for us to maintain, we will drop it > from our next generation of CPUs and force everybody to port their software > to

Re: [Development] Qt 5 types under consideration for deprecation / removal in Qt 6

2019-06-03 Thread Thiago Macieira
On Sunday, 2 June 2019 22:31:47 PDT Olivier Goffart wrote: > I also managed to get that done with a <10 lines of "plain cmake": > > https://github.com/woboq/moc-ng/blob/7cfa2b65efaf836054977e5974f8f9c23b0cb05 > 7/src/CMakeLists.txt#L46-L54 Yup, I figured with CMake it would be possible. But I'm

Re: [Development] Deprecation/removal model going into Qt 6

2019-06-03 Thread Thiago Macieira
On Sunday, 2 June 2019 16:46:00 PDT Manuel Bergler wrote: > Well, something has to give. Either > a) Qt can never remove superseded APIs and classes (which is what > you suggested previously) and will eventually collapse under its own > weight, or > b) Distributors have to deal with the fact

Re: [Development] Deprecation/removal model going into Qt 6

2019-06-03 Thread Lars Knoll
> On 3 Jun 2019, at 08:00, Thiago Macieira wrote: > > On Sunday, 2 June 2019 16:46:00 PDT Manuel Bergler wrote: >> Well, something has to give. Either >> a) Qt can never remove superseded APIs and classes (which is what >> you suggested previously) and will eventually collapse under its own >>

Re: [Development] Deprecation/removal model going into Qt 6

2019-06-03 Thread Uwe Rathmann
On 6/3/19 10:50 AM, Giuseppe D'Angelo via Development wrote: How is this even an argument? Qt will need to evolve and acquire features to remain competitive. The probably most important module - Qt/Widgets - sits on a graphic stack, that had been identified as not being competitive many

Re: [Development] Deprecation/removal model going into Qt 6

2019-06-03 Thread Lars Knoll
Going back to the beginning of the thread. > On 31 May 2019, at 14:50, Giuseppe D'Angelo via Development > wrote: > > Hi, > > It seems to me that many emails in the earlier deprecation thread were from > users concerned by the problem of removal of functionality. This is not an > old story.

Re: [Development] Deprecation/removal model going into Qt 6

2019-06-03 Thread Christian Kandeler
On Sat, 1 Jun 2019 14:36:12 +0200 André Pönitz wrote: > On Fri, May 31, 2019 at 01:24:13PM +, Volker Hilsheimer wrote: > > The overall goal here is to make sure that we don’t have to carry > > poorly designed architecture or APIs around with us throughout the Qt > > 6 series, and as long as

Re: [Development] Qt 5 types under consideration for deprecation / removal in Qt 6

2019-06-03 Thread Volker Hilsheimer
> On 1 Jun 2019, at 21:20, Bernhard Lindner wrote: > > Am Mittwoch, den 29.05.2019, 23:34 +0200 schrieb Mutz, Marc via Development: > >>> So, yes, this is borne out of frustration with the lack of maintenance >>> of QtCore plumbing. I don't see that changing and I acknowledge and >>>

Re: [Development] Deprecation/removal model going into Qt 6

2019-06-03 Thread Kevin Kofler
Giuseppe D'Angelo via Development wrote: > Il 03/06/19 00:08, Kevin Kofler ha scritto: >> What you call "obsolete functionality" is functionality that existing >> code relies on and rightfully expects to remain there. > > Rightfully? By what right exactly? APIs in libraries are meant to be

Re: [Development] Qt 5 types under consideration for deprecation / removal in Qt 6

2019-06-03 Thread Jedrzej Nowacki
On Saturday, June 1, 2019 5:36:35 AM CEST Thiago Macieira wrote: > On Friday, 31 May 2019 10:13:52 PDT Thiago Macieira wrote: > > rcc should be un-bootstrapped. The only use inside QtCore is for the MIME > > type database. We don't need a resource, though it compresses really well > > (roughly

Re: [Development] Deprecation/removal model going into Qt 6

2019-06-03 Thread Giuseppe D'Angelo via Development
Il 03/06/19 00:08, Kevin Kofler ha scritto: Ballast (obsolete functionality, for various degree of "obsolete") has to be dropped from time to time, causing API breaks. The question in this thread is how to manage those API breaks to be as painless as possible. What you call "obsolete

Re: [Development] Qt 5 types under consideration for deprecation / removal in Qt 6

2019-06-03 Thread Lars Knoll
Also here going back to the start of the thread (as I was offline for some days for a long weekend): > On 29 May 2019, at 12:53, Mutz, Marc via Development > wrote: > > Hi, > > Here's a list of stuff I consider has served it's purpose and is no longer > needed, with respective replacements:

[Development] Qt Design Studio 1.2 final is released

2019-06-03 Thread Thomas Hartmann
Hi, Qt Design Studio 1.2 final is released today, see https://blog.qt.io/blog/2019/06/03/qt-design-studio-1-2-released/ Big thanks to everyone involved! Best Regards, Thomas Hartmann ___ Development mailing list Development@qt-project.org

Re: [Development] Deprecation/removal model going into Qt 6

2019-06-03 Thread Giuseppe D'Angelo via Development
Il 03/06/19 13:34, Kevin Kofler ha scritto: Giuseppe D'Angelo via Development wrote: Il 03/06/19 00:08, Kevin Kofler ha scritto: What you call "obsolete functionality" is functionality that existing code relies on and rightfully expects to remain there. Rightfully? By what right exactly?

Re: [Development] Deprecation/removal model going into Qt 6

2019-06-03 Thread Volker Hilsheimer
> On 3 Jun 2019, at 13:34, Kevin Kofler wrote: >>> I'd rather get fewer (or even no) new features than losing existing ones. >> >> How is this even an argument? Qt will need to evolve and acquire >> features to remain competitive. Again, development bandwidth is finite: >> either the overall

Re: [Development] Deprecation/removal model going into Qt 6

2019-06-03 Thread Vitaly Fanaskov
> APIs in libraries are meant to be used. I consider it an entirely reasonable > expectation by developers using the APIs that they will not be removed under > them because the library developers consider them "obsolete". Imagine the > chaos if Intel or AMD decided to remove some random "obsolete"

Re: [Development] Deprecation/removal model going into Qt 6

2019-06-03 Thread Uwe Rathmann
On 6/3/19 1:34 PM, Kevin Kofler wrote: So I disagree with the assertion that Qt needs more features to remain competitive. Come on - a toolkit ( Qt/Widgets ) for writing user interfaces, that does not make use of the graphics hardware, is begging for being replaced. Quick Controls 1 was

Re: [Development] Qt 5 types under consideration for deprecation / removal in Qt 6

2019-06-03 Thread Bernhard Lindner
> > > > So, yes, this is borne out of frustration with the lack of maintenance > > > > of QtCore plumbing. I don't see that changing and I acknowledge and > > > > understand that the focus of development has shifted towards QML. > > > Suppose you implement all planned actions for Qt6 (see your

[Development] Qt 6 story

2019-06-03 Thread Bernhard Lindner
> Actually each major release should have a story, that has to do with > some sort of innovation that might require to remove old stuff. Very good statement. The current implicit stories seems to be: "Throw out some parts we can't afford" and "Replace the builds system". Which are both not a

Re: [Development] Qt 6 story

2019-06-03 Thread Uwe Rathmann
On 6/3/19 2:35 PM, Bernhard Lindner wrote: What would be your story proposal? "Make Widgets great again"? That would be one I would like to see. But the story I'm actively working on is about a different Qt/Quick framework. I hope, that we are allowed to give a presentation of what this is

Re: [Development] Configure command lines of official Qt releases

2019-06-03 Thread Richard Weickelt
> I think this was asked on the interest list back in January [1]. I did search on the Qt mailing lists, but even when I type exactly the subject of the thread you referred to, google doesn't find it. I would expect "Official builds configuration options site:lists.qt-project.org" to bring this

Re: [Development] Qt 5 types under consideration for deprecation / removal in Qt 6

2019-06-03 Thread Thiago Macieira
On Monday, 3 June 2019 02:26:05 PDT Lars Knoll wrote: > > == Java-style iteration > > (https://codereview.qt-project.org/c/qt/qtbase/+/262344) == > > It's very easy to write quadratic loops with it.remove(), and a review of > > Qt code has shown that some users still use container.remove(),

Re: [Development] Qt 5 types under consideration for deprecation / removal in Qt 6

2019-06-03 Thread Thiago Macieira
On Monday, 3 June 2019 10:31:14 PDT Thiago Macieira wrote: > A semantic replacement could be used to refactor the code from load() → > load(std::memory_order_relaxed) and loadAcquire() → load(). Another idea is to introduce loadRelaxed() and storeRelaxed() in Qt 5.13, right now, so we can mark

Re: [Development] Configure command lines of official Qt releases

2019-06-03 Thread Elvis Stansvik
Hi Richard, I think this was asked on the interest list back in January [1]. The answer is here: https://code.qt.io/cgit/qtsdk/qtsdk.git/tree/packaging-tools/bld_config I seem to remember some recent Qt developer thread about making these more accessible, but can't find it now. HTH, Elvis

Re: [Development] Configure command lines of official Qt releases

2019-06-03 Thread Elvis Stansvik
Den mån 3 juni 2019 kl 20:29 skrev Richard Weickelt : > > > > I think this was asked on the interest list back in January [1]. > > I did search on the Qt mailing lists, but even when I type exactly the > subject of the thread you referred to, google doesn't find it. I would > expect "Official

Re: [Development] Deprecation/removal model going into Qt 6

2019-06-03 Thread Thiago Macieira
On Monday, 3 June 2019 04:34:27 PDT Kevin Kofler wrote: > Imagine the > chaos if Intel or AMD decided to remove some random "obsolete" x86 > instructions from their CPUs! x86 has kept backwards compatibility with > every single instruction for more than 30 years. And yet, we can look at this

Re: [Development] Deprecation/removal model going into Qt 6

2019-06-03 Thread Thiago Macieira
On Monday, 3 June 2019 01:50:26 PDT Giuseppe D'Angelo via Development wrote: > At some QtCS Thiago was talking about 23-24 QChars, i.e. 48 bytes, plus > a couple of pointers or so, to bring it to 64 bytes (~ a cacheline). The minimum size for a QString is 3 pointers, which would be 12 bytes on

Re: [Development] Qt 5 types under consideration for deprecation / removal in Qt 6

2019-06-03 Thread Konstantin Tokarev
03.06.2019, 09:06, "Thiago Macieira" : > On Sunday, 2 June 2019 22:31:47 PDT Olivier Goffart wrote: >>  I also managed to get that done with a <10 lines of "plain cmake": >> >>  https://github.com/woboq/moc-ng/blob/7cfa2b65efaf836054977e5974f8f9c23b0cb05 >>  7/src/CMakeLists.txt#L46-L54 > > Yup,

Re: [Development] Deprecation/removal model going into Qt 6

2019-06-03 Thread Thiago Macieira
On Monday, 3 June 2019 06:26:36 PDT Giuseppe D'Angelo via Development wrote: > > QList::prepend has O(1) amortized and O(n) worst case time complexity. > > QVector::prepend has O(mn) (always!) time complexity. > > > > If you are dealing with a large class or struct, e.g. 800 bytes, then the > >

Re: [Development] Qt 5 types under consideration for deprecation / removal in Qt 6

2019-06-03 Thread Thiago Macieira
On Monday, 3 June 2019 10:43:44 PDT Konstantin Tokarev wrote: > 03.06.2019, 09:06, "Thiago Macieira" : > > On Sunday, 2 June 2019 22:31:47 PDT Olivier Goffart wrote: > >> I also managed to get that done with a <10 lines of "plain cmake": > >> > >>

Re: [Development] Configure command lines of official Qt releases

2019-06-03 Thread Elvis Stansvik
Den mån 3 juni 2019 kl 20:04 skrev Elvis Stansvik : > > Hi Richard, > > I think this was asked on the interest list back in January [1]. > > The answer is here: > > https://code.qt.io/cgit/qtsdk/qtsdk.git/tree/packaging-tools/bld_config > > I seem to remember some recent Qt developer thread about

[Development] Configure command lines of official Qt releases

2019-06-03 Thread Richard Weickelt
Hi, where can I find the configure command lines that have been used for Qt binary releases provided at https://download.qt.io/official_releases/qt/ ? Is there also more information available about the environment they have been built on? I am particularly interested in the Linux release.

Re: [Development] Deprecation/removal model going into Qt 6

2019-06-03 Thread Giuseppe D'Angelo via Development
Il 03/06/19 23:04, Kevin Kofler ha scritto: Giuseppe D'Angelo via Development wrote: Also, please name me 3 GUI frameworks that have not broken APIs for 30 years. Also also, please name me 3 libraries that have not broken APIs for the 30 years. There is at least one (almost): Win32 has now

Re: [Development] Qt 5 types under consideration for deprecation / removal in Qt 6

2019-06-03 Thread Danila Malyutin
Have you tried running the script with "powershell –ExecutionPolicy Bypass" ? IRC, this should work for regular non-admin users to. If that does work, I think you can just pipe the script to "powershell -". вт, 4 июн. 2019 г. в 01:54, Thiago Macieira : > On Saturday, 1 June 2019 08:14:13 PDT

Re: [Development] Qt 5 types under consideration for deprecation / removal in Qt 6

2019-06-03 Thread Thiago Macieira
On Saturday, 1 June 2019 08:14:13 PDT Jean-Michaël Celerier wrote: > xxd.ps1: > param([String]$path) > > $bytes = [System.IO.File]::ReadAllBytes($path); > $size = $bytes.length; > > $bytes = (($bytes | %{ "0x" + $_ ; }) | Out-String); > $content = $bytes -replace "`r",", " -replace "`n",""

Re: [Development] Deprecation/removal model going into Qt 6

2019-06-03 Thread Kevin Kofler
Giuseppe D'Angelo via Development wrote: > Also, please name me 3 GUI frameworks that have not broken APIs for 30 > years. > > Also also, please name me 3 libraries that have not broken APIs for the > 30 years. There is at least one (almost): Win32 has now existed for 26 years without an ABI

Re: [Development] Qt 5 types under consideration for deprecation / removal in Qt 6

2019-06-03 Thread Thiago Macieira
On Monday, 3 June 2019 17:50:58 PDT Danila Malyutin wrote: > Have you tried running the script with "powershell –ExecutionPolicy Bypass" > ? IRC, this should work for regular non-admin users to. If that does work, > I think you can just pipe the script to "powershell -". That works, thanks. This

Re: [Development] Qt 5 types under consideration for deprecation / removal in Qt 6

2019-06-03 Thread Konstantin Tokarev
03.06.2019, 21:01, "Thiago Macieira" : > On Monday, 3 June 2019 10:43:44 PDT Konstantin Tokarev wrote: >>  03.06.2019, 09:06, "Thiago Macieira" : >>  > On Sunday, 2 June 2019 22:31:47 PDT Olivier Goffart wrote: >>  >> I also managed to get that done with a <10 lines of "plain cmake": >>  >> >>  

Re: [Development] Qt 5 types under consideration for deprecation / removal in Qt 6

2019-06-03 Thread Thiago Macieira
On Monday, 3 June 2019 18:46:31 PDT Konstantin Tokarev wrote: > This can be done with qmake if we implement ord I want to do a bit more in the shell script. All steps optional: First, I want to pass the XML source through xml sel -D -B -t -c / That will minify the source. That reduces

Re: [Development] Qt 5 types under consideration for deprecation / removal in Qt 6

2019-06-03 Thread Konstantin Tokarev
04.06.2019, 04:41, "Thiago Macieira" : > On Monday, 3 June 2019 18:04:49 PDT Thiago Macieira wrote: >>  This script takes a hideously enormous amount of time to run. I hope it's >>  because that's just a really long line. Found this script that seems to >>  break every 16 bytes: >>  

Re: [Development] Qt 5 types under consideration for deprecation / removal in Qt 6

2019-06-03 Thread Thiago Macieira
On Monday, 3 June 2019 18:04:49 PDT Thiago Macieira wrote: > This script takes a hideously enormous amount of time to run. I hope it's > because that's just a really long line. Found this script that seems to > break every 16 bytes: > https://github.com/sperner/PowerShell/blob/master/HexDump.ps1