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 the uncompressed size by about 10%.

Second, I'm also thinking of compressing with gzip or zstd. The problem with 
that is that the tool may be present in the system but not the headers, which 
would cause decompression to fail. So I'm not sure this is a good idea.

Of course, on Windows/MSVC you'd get neither minification nor compression.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel System Software Products



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


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":
>>  >>
>>  >> https://github.com/woboq/moc-ng/blob/7cfa2b65efaf836054977e5974f8f9c23b0
>>  >> cb05 7/src/CMakeLists.txt#L46-L54
>>  >
>>  > Yup, I figured with CMake it would be possible. But I'm trying to get this
>>  > in Qt 5 first.
>>
>>  Does qmake miss anything used in this fragment? It supports reading files,
>>  regex replacements, and writing files.
>
> Reading *arbitrary* files and processing binary data.
>
> It can only read qmake files. 

No, it can read arbitrary files with cat() function.

> And it lacks the transform functions to produce
> an hex dump.
>
> --
> Thiago Macieira - thiago.macieira (AT) intel.com
>   Software Architect - Intel System Software Products
>
> ___
> Development mailing list
> Development@qt-project.org
> https://lists.qt-project.org/listinfo/development

-- 
Regards,
Konstantin

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


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:
>>  https://github.com/sperner/PowerShell/blob/master/HexDump.ps1
>
> BTW, equivalent Perl script that is a single line and runs in 0.357 seconds:
>
> map { printf "0x%x, ", ord $_ } split //, <>
>
> perl -ne 'map { printf "0x%x, ", ord $_ } split //, <>' < src/corelib/
> mimetypes/mime/packages/freedesktop.org.xml | wc
>   0 1140712 6823656
>
> [xxd runs in 0.23 seconds]

This can be done with qmake if we implement ord

-- 
Regards,
Konstantin

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


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

BTW, equivalent Perl script that is a single line and runs in 0.357 seconds:

map { printf "0x%x, ", ord $_ } split //, <>

perl -ne 'map { printf "0x%x, ", ord $_ } split //, <>' < src/corelib/
mimetypes/mime/packages/freedesktop.org.xml | wc
  0 1140712 6823656

[xxd runs in 0.23 seconds]
-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel System Software Products



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


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

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel System Software Products



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


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 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","" -replace ".{2}$";
> > $res = "unsigned char foobar[] = { " + $content + " }; + `r`nunsigned int
> > foobar_len = " + $size + ";`r`n";
> > echo $res
> >
> > Feel free to use as you see fit
> > Best,
>
> Thanks. Unfortunately, it didn't go very far:
>
> File C:\Qt\qt5\qtbase\src\corelib\mimetypes\mime\encode.ps1 cannot be
> loaded
> because running scripts is disabled on this system. For more information,
> see
> about_Execution_Policies at
> https:/go.microsoft.com/fwlink/?LinkID=135170.
> + CategoryInfo  : SecurityError: (:) [],
> ParentContainsErrorRecordException
> + FullyQualifiedErrorId : UnauthorizedAccess
>
> I know how to turn that off, but I needed Admin privileges to do that. I
> don't
> think it's going to be acceptable for a Qt build.
>
> It's much easier to require people to install Perl.
> --
> Thiago Macieira - thiago.macieira (AT) intel.com
>   Software Architect - Intel System Software Products
>
>
>
> ___
> 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] 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","" -replace ".{2}$";
> $res = "unsigned char foobar[] = { " + $content + " }; + `r`nunsigned int
> foobar_len = " + $size + ";`r`n";
> echo $res
> 
> Feel free to use as you see fit
> Best,

Thanks. Unfortunately, it didn't go very far:

File C:\Qt\qt5\qtbase\src\corelib\mimetypes\mime\encode.ps1 cannot be loaded 
because running scripts is disabled on this system. For more information, see 
about_Execution_Policies at
https:/go.microsoft.com/fwlink/?LinkID=135170.
+ CategoryInfo  : SecurityError: (:) [], 
ParentContainsErrorRecordException
+ FullyQualifiedErrorId : UnauthorizedAccess

I know how to turn that off, but I needed Admin privileges to do that. I don't 
think it's going to be acceptable for a Qt build.

It's much easier to require people to install Perl.
-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel System Software Products



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


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 existed for 26 years without
an ABI break.

That said, it is painful to use (directly), proprietary, and not portable.
But we have to admit that they did really well at maintaining compatibility.


Some API has been dropped by Win32 (first that comes in mind is NDDE). 
Still waiting for the other examples. (Anyhow, last time I checked, the 
development power behind Qt is a tiny fraction of the one available to 
Microsoft. I brought up the development bandwidth problem already.)




Also also also, at least in the x86-64 world, major "API breaks" at the
assembly level have already somehow occurred. And that's an architecture
that has been around for less than 20 years.


Have they really? Software built for the first x86_64 CPUs still runs
unchanged, doesn't it?


If you want your software to have security issues, yes. Otherwise you'll 
need to change your assembly. That's an API break in my book.




Qt has also become larger and larger over time (despite the removal of
APIs considered obsolete).


The removal of APIs in Qt 5 lifetime has been mostly "limited" to
dropping entire obsolete modules. No cleanup has been done to deprecated
API inside a module.


I was comparing the size of Qt 3 and Qt 5. There have been 2 such cleanups
between them: Qt 4.0 and Qt 5.0. Still, Qt 4 was much larger than Qt 3, and
Qt 5 is much larger than Qt 4 was.


Qt 6 wants to do that, and the point of this thread is how to minimize the
pain.


And my point is that the only way to minimize the pain is to just not do
that to begin with.

There needs to be a point where a library just stops doing new incompatible
major releases. See how glibc has now been at glibc 2 (libc.so.6) for 22
years.



... Glibc has done countless API breaks:


https://raw.githubusercontent.com/bminor/glibc/master/NEWS






The intended _scriptable_ solution is

1) copy and paste Q_FOREACH from qglobal.h into a central header of your
project
2) rename all occurrences it to MY_FOREACH
3) done


That (telling the users to just copy&paste the code from the library)
defeats the whole point of a software library.


Because Q_FOREACH does not belong to Qt. How about this: put it in a 
separate library, publish it to github, and port projects to use _that_ 
instead? It's still 100% scriptable.





This is just *false*. You're (deliberately?) ignoring the cost of memory
allocations and deallocations, hiding them in big-O constants, something
I already warned you about. I won't then waste time debunking this.


If you have a list of 100 800-byte objects and you want to insert an
element in the middle of the list, with a reasonable malloc implementation,
the ONE allocation together with the 4 MB memmove for QList::insert will be
negligible compared to the 400 MB (!) memmove for QVector::insert.


Third straw man in three emails. Inserting in the middle of a sequential 
container with a million elements is NOT a common use case. While at it, 
why don't you also measure the cost of iterating over the elements, as 
already suggested in an earlier email?




Of course, that doesn't imply that it is not possible to do better, in
theory. But is this optimization [SSO] worth the trouble of breaking the
ABI?


Yes.


And that's what I doubt, and you have not stated any arguments for your
claim.


So you want me to dump here all the existing literature available around 
the benefits of SSO, for the sake of... what exactly? SSO is not an API 
break and therefore discussion about it does NOT belong to this thread.



Quite bored now,
--
Giuseppe D'Angelo | giuseppe.dang...@kdab.com | Senior Software Engineer
KDAB (France) S.A.S., a KDAB Group company
Tel. France +33 (0)4 90 84 08 53, http://www.kdab.com
KDAB - The Qt, C++ and OpenGL Experts



smime.p7s
Description: Firma crittografica S/MIME
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development


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

That said, it is painful to use (directly), proprietary, and not portable. 
But we have to admit that they did really well at maintaining compatibility.

> Also also also, at least in the x86-64 world, major "API breaks" at the
> assembly level have already somehow occurred. And that's an architecture
> that has been around for less than 20 years.

Have they really? Software built for the first x86_64 CPUs still runs 
unchanged, doesn't it?

>> Qt has also become larger and larger over time (despite the removal of
>> APIs considered obsolete).
> 
> The removal of APIs in Qt 5 lifetime has been mostly "limited" to
> dropping entire obsolete modules. No cleanup has been done to deprecated
> API inside a module.

I was comparing the size of Qt 3 and Qt 5. There have been 2 such cleanups 
between them: Qt 4.0 and Qt 5.0. Still, Qt 4 was much larger than Qt 3, and 
Qt 5 is much larger than Qt 4 was.

> Qt 6 wants to do that, and the point of this thread is how to minimize the
> pain.

And my point is that the only way to minimize the pain is to just not do 
that to begin with.

There needs to be a point where a library just stops doing new incompatible 
major releases. See how glibc has now been at glibc 2 (libc.so.6) for 22 
years.

> The intended _scriptable_ solution is
> 
> 1) copy and paste Q_FOREACH from qglobal.h into a central header of your
> project
> 2) rename all occurrences it to MY_FOREACH
> 3) done

That (telling the users to just copy&paste the code from the library) 
defeats the whole point of a software library.

> This is just *false*. You're (deliberately?) ignoring the cost of memory
> allocations and deallocations, hiding them in big-O constants, something
> I already warned you about. I won't then waste time debunking this.

If you have a list of 100 800-byte objects and you want to insert an 
element in the middle of the list, with a reasonable malloc implementation, 
the ONE allocation together with the 4 MB memmove for QList::insert will be 
negligible compared to the 400 MB (!) memmove for QVector::insert.

>> Of course, that doesn't imply that it is not possible to do better, in
>> theory. But is this optimization [SSO] worth the trouble of breaking the
>> ABI?
> 
> Yes.

And that's what I doubt, and you have not stated any arguments for your 
claim.

> CoW and SSO are orthogonal optimizations. folly's fbstring has *both*.

They are not entirely orthogonal because CoW only works on strings too large 
for SSO. SSO strings are always deep-copied by design.

Kevin Kofler

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


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 builds configuration options site:lists.qt-project.org" to
> bring this post up:
> https://lists.qt-project.org/pipermail/interest/2019-January/032221.html but
> it seems like google hasn't even indexed it.

Strange! Perhaps something for the Qt web server administrators to
look at, I would also expect it to be indexed by now.

Elvis

> > The answer is here:
> >
> > https://code.qt.io/cgit/qtsdk/qtsdk.git/tree/packaging-tools/bld_config
>
> Great. Thanks.
>
> Richard
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development


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 post up:
https://lists.qt-project.org/pipermail/interest/2019-January/032221.html but
it seems like google hasn't even indexed it.
> The answer is here:
> 
> https://code.qt.io/cgit/qtsdk/qtsdk.git/tree/packaging-tools/bld_config

Great. Thanks.

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


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 making these
> more accessible, but can't find it now.

Found it, but I remembered somewhat wrong. I was thinking of this note
by Volker in the recent "A monologue about platforms in the Qt world"
thread [1]:

"Why don’t we make the exact way of turning a clean Linux
distro-install into a "Qt reference configuration" available to
everyone else? The way build machines are provisioned in Coin is
rather opaque, even with some of the respective provisioning scripts
available in the qt5.git repo [1]. Having to document on a
(notoriously outdated) wiki how to set up things to build Qt from
source, when we have that knowledge literally codified somewhere for
Coin, doesn’t seem effective."

So that was more about making the provisioning process for a
"reference" build machine more transparent.

Elvis

[1] https://lists.qt-project.org/pipermail/development/2019-May/035773.html

>
> HTH,
> Elvis
>
> [1] https://lists.qt-project.org/pipermail/interest/2019-January/032221.html
>
> Den mån 3 juni 2019 kl 18:56 skrev 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.
> >
> > Thanks
> > ___
> > 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] 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

[1] https://lists.qt-project.org/pipermail/interest/2019-January/032221.html

Den mån 3 juni 2019 kl 18:56 skrev 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.
>
> Thanks
> ___
> 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] 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":
> >> 
> >>  https://github.com/woboq/moc-ng/blob/7cfa2b65efaf836054977e5974f8f9c23b0
> >> cb05 7/src/CMakeLists.txt#L46-L54
> > 
> > Yup, I figured with CMake it would be possible. But I'm trying to get this
> > in Qt 5 first.
> 
> Does qmake miss anything used in this fragment? It supports reading files,
> regex replacements, and writing files.

Reading *arbitrary* files and processing binary data.

It can only read qmake files. And it lacks the transform functions to produce 
an hex dump.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel System Software Products



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


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 load() and store() conditionally deprecated 
(#ifdef). That way, we can begin converting from load() to loadRelaxed() along 
the way.

When 6.0 comes, we can perform the change from loadRelaxed() to 
load(std::memory_order_relaxed) with a simple search-and-replace.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel System Software Products



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


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, I figured with CMake it would be possible. But I'm trying to get this in
> Qt 5 first.

Does qmake miss anything used in this fragment? It supports reading files, 
regex replacements,
and writing files.

-- 
Regards,
Konstantin

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


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(), which is
> > just as unsafe as with STL iterators. I also noted between 100b/loop and
> > 5KiB for four loops of text size savings.
> 
> I’m a bit torn here. On code review I gave a +1 on deprecating them, but I
> see that this could lead to a lot of porting effort on user code that makes
> extensive use of them. And the problem is that the porting can be
> non-trivial in cases where the list gets modified while iterating. So I
> think we should most likely keep them for Qt 6.

Those are entirely-inline classes, so they don't take space in the library. 
They've also been completely unchanged for years, so the maintenance cost is 
minimal.

I agree with deprecating but keeping in 6.x.

> > == QRegExp ==
> > 
> > Is QRegularExpression good enough these days? :)
> > 
> 
> I’m in favour of deprecating and moving it into a Qt5Support library. As
> pointed out, qmake will need it.

Possibly a library specifically for QRegExp, like we did for QHttp in 5.0.

> > === QAtomic -> std::atomic ===
> > 
> > It already is just a thin wrapper around std::atomic, so there's not much
> > point keeping it.
> 
> Except that a simple search and replace will change semantics of load(). And
> I think that’s not quite acceptable, given that atomics are in quite a few
> cases used for performance sensitive code paths.

A semantic replacement could be used to refactor the code from load() → 
load(std::memory_order_relaxed) and loadAcquire() → load().

I wouldn't suggest adding a wrapper that does the mapping. Because we already 
have one: that wrapper *IS* QAtomicInteger, which already wraps a std::atomic. 
So either we perform a global, semantic search-and-replace, or we just do 
nothing.

> > === QMutex / QReadWriteLock -> std::*mutex* ===
> > 
> > It has too many responsibilities. Where the std knows many different mutex
> > classes, Qt folds everything into just two.
 
> > We probably need to keep QRWL around a while longer, since C++ added
> > shared_mutex only in C++17.
> 
> The only problem I see with QMutex is that it implements both a recursive
> and non recursive mutex in one class. I would consider splitting that up.

Already prepared for that. I haven't performed the change, but it's easy to 
do.

I recommend adding QRecursiveMutex right now in Qt 5, with the only difference 
from QMutex being that it changes the default constructor. That way, code can 
begin porting, as we deprecate the non-default constructor.

QRecursiveMutex will derive from QMutex. I hope that's not a problem. Whether 
QMutex::lock() can be poor-mans-virtual and perform a recursive lock is up for 
discussion.

As a benefit, neither QMutex nor QRecursiveMutex will allocate memory on 
Linux.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel System Software Products



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


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

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


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
> > QVector operations are 100 times slower than the QList ones!
> 
> This is just *false*. You're (deliberately?) ignoring the cost of memory
> allocations and deallocations, hiding them in big-O constants, something
> I already warned you about. I won't then waste time debunking this.

Don't forget that QVector is a direct memory access, which is easily predicted 
by the CPU, so it can read ahead. If you're iterating (accessing!) the 
elements in QList, you're accessing memory that may not be read-ahead, because 
it's indirect. It will depend on how the elements were added and the strategy 
of the memory allocator.

Also, please consider the memory considerations. If you have 100 elements of 
800 bytes, a QVector will allocate 100*800 + 24 bytes (plus 16 of overhead 
inside malloc, total 80032 bytes used), whereas QList will allocate 100 * (800 
+ 8 + malloc overhead) + malloc overhead, for a total of 82416 bytes, or 3% 
more.

Now if your object is 80 bytes instead of 800, the memory usage increase is 
29%.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel System Software Products



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


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 exactly as an example: if you set the CPU to long 
mode (a.k.a., 64-bit mode), then a LOT of previously obsolete instructions are 
dropped, especially those that were 1-byte opcodes.

This is akin to what we're looking for here: if you opt in to greater and 
newer things, we can drop obsolete things you've had years (or decades, in the 
case of CPU) to port away from.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel System Software Products



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


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 32-
bit. Given we need at least one byte to indicate that it's SSO o not, that 
would leave an SSO QString limited to 5 chars, which is not very useful.

On 64-bit, it would increase to 11 characters. That is better, but given 
previous histograms of the size of strings in a real-world application 
(QtCreator), it's leaving a lot on the table. I think the numbers showed that 
the most common size was 16, but I don't remember if that was bytes or 
characters. Either way, the drop to the right of the peak wasn't very sharp.

The sweet spot is likely to be between 32 and 48 bytes (15 to 23 characters).

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel System Software Products



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


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 quality decreases or some things have to get dropped.
> 
> Qt has long reached a point where it can be considered complete. Its main 
> selling point is portability to many different platforms rather than some 
> specific feature. Additional features don't necessarily need to be in the 
> main Qt library, but can be in community-developed addons such as KDE 
> Frameworks or such as the many third-party Qt-based Free Software libraries 
> out there. (They can also be in Qt-Company-developed Qt Solutions if there 
> is manpower left for that.)
> 
> Qt has also become larger and larger over time (despite the removal of APIs 
> considered obsolete). Just compare the size of the Qt 3 tarball with the 
> size of the Qt 5 monolithic tarball. This is not the result of keeping old 
> APIs around, but of feature creep.
> 
> So I disagree with the assertion that Qt needs more features to remain 
> competitive.



I suppose the same can be said for Linux distros :)

But even if we say that Qt is feature complete: the platforms and technologies 
we sit on top of will continue to develop and change. For example, OpenGL will 
sooner or later disappear from macOS. NTFS has had symlinks and junctions, 
which Qt knows precious little about. HTTP/2 is a thing.

Some of the changes necessary to stay relevant on these platforms we can make 
without breaking APIs; some of them we can’t. For example, QFileInfo::isSymLink 
is a poor API given the file types on NTFS (shortcut files, ie. .lnk; 
junctions, which are like hard-links for directories; symlinks; files; 
directories). Of course, we can keep it around forever while introducing a more 
nuanced API, but the code that implements the old API is a mess to maintain as 
well, and will likely interfere with a clean and maintainable implementation of 
a better API.

In addition, sometimes we don’t get it right the first time. In fact, any 
strategy that is based on the assumption that “we get it perfectly right the 
first time so that we never have to change it” is bound to fail. I crafted the 
first version of QAccessible, and I wonder how many of you can be bothered with 
implementing your accessbility interfaces when you implement your custom 
widgets or QML controls. That ultimately affects real people, and if we have to 
break API or ABI to make it more likely that all UI elements are accessible, 
then let’s please do that.

It’s always a trade-off, and each case needs to be discussed. Nobody is 
recommending that we are mindlessly removing or changing things just because we 
can. But going the other extreme and saying "nothing must ever change because 
people will have to change their software” is not better.

Volker



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


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?


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" x86
instructions from their CPUs! x86 has kept backwards compatibility with
every single instruction for more than 30 years. This is the standard
software libraries should be held to, too.


Nice try: https://rationalwiki.org/wiki/Straw_man#Forms

Specifically: moving the focus from a GUI framework's API to a 
foundational computer architecture design (which must provide much 
stronger guarantees).



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.


Also also also, at least in the x86-64 world, major "API breaks" at the 
assembly level have already somehow occurred. And that's an architecture 
that has been around for less than 20 years.





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 quality decreases or some things have to get dropped.


Qt has long reached a point where it can be considered complete. Its main
selling point is portability to many different platforms rather than some
specific feature. Additional features don't necessarily need to be in the
main Qt library, but can be in community-developed addons such as KDE
Frameworks or such as the many third-party Qt-based Free Software libraries
out there. (They can also be in Qt-Company-developed Qt Solutions if there
is manpower left for that.)

Qt has also become larger and larger over time (despite the removal of APIs
considered obsolete). 


The removal of APIs in Qt 5 lifetime has been mostly "limited" to 
dropping entire obsolete modules. No cleanup has been done to deprecated 
API inside a module. Qt 6 wants to do that, and the point of this thread 
is how to minimize the pain.





Just compare the size of the Qt 3 tarball with the
size of the Qt 5 monolithic tarball. This is not the result of keeping old
APIs around, but of feature creep.


"Creep" is questionable; and anyhow off-topic.



So I disagree with the assertion that Qt needs more features to remain
competitive.


And I disagree with this. And even assuming to stop adding new feature,s 
the _current_ feature set may need refactoring and redesigns, which may 
mean API breaks.





See also Boudewijn Rempt's blog post on the subject:
https://valdyas.org/fading/hacking/happy-porting/


I agree with the principle (API breaks are painful), but I strongly
disagree with the idea that no API breaks can ever possibly happen. And
the specific example is a terrible one to make a point as the resulting
API break is trivial to work around (I defined such breakages
"scriptable").


The Q_FOREACH to ranged for change is not as easy to port to as people
think, because there are at least 2 pitfalls when porting to ranged for:
1. you have to add qAsConst or equivalent or you will be deep-copying your
implicitly-shared CoW container,
2. code that was changing the container during the iteration, which worked
just fine with Q_FOREACH (because the iteration would still be over the
original unchanged container), will now crash without warning. Even
qAsConst will not help you get a warning or error for it, because it only
constifies the reference for the ranged for itself and not for the code
within it.

This is effectively deprecating a safe construct for an unsafe one.


This is not the intended port, because it's not scriptable. Moving to a 
range-based for is the long-term solution, but that requires checking 
all usages.


The intended _scriptable_ solution is

1) copy and paste Q_FOREACH from qglobal.h into a central header of your 
project

2) rename all occurrences it to MY_FOREACH
3) done

What's the difference, then? For your code, minimal (just use another 
macro). But for Qt, that it stops supporting Q_FOREACH, teaching its 
usage, and advocating for it.





An array of pointers is the most efficient data structure in practice
(operations are at most O(n)), dropping it in favor of an O(mn) data
structure (where m = sizeof(T)) such as QVector is a pessimization. And
QList also has the prepend optimization that makes most prepends even
O(1) rather than O(n). I don't see why almost everybody hates it.


As written, the above makes no sense, as it looks like you're comparing
apples and oranges: 

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 supposed to be at the Qt World Summit.


Unfortunately the Qt project seems to be clueless about how to deal with 
projects being developed outside. I tried to get an answer to the simple 
question how my work could be related to the Qt project. But even after 
a face to face meeting with Lars I never got any type of response. 
Neither positive nor negative - only silence.


Uwe




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


[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
https://lists.qt-project.org/listinfo/development


[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 very attractive from the 
application
developers point of view. Did I miss something?

What would be your story proposal? "Make Widgets great again"?

"Modernize the language to C++17" would be a possible story as well (especially 
teaching
moc to handle templates).

Any proposals for a Qt 6 story?

I hope my suspicion is wrong that Qt has spent so much on a few cash cows that 
it is no
longer capable of any other major advances (but must even go backwards, see XML 
thread).

-- 
Best Regards,
Bernhard Lindner

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


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 original 
> > > e-mail). Are
> > > the
> > > remaining components (those that are neither deprecated nor removed) of 
> > > Qt6 well
> > > maintained and are there enough staff available not only to maintain them
> > > indefinitely
> > > but to actively develop them further?
> > 
> > No answer to my question above?
> 
> Who do you expect an answer to this question from?
> 
> The Qt Company? The Qt community? Marc? Thiago?

Whoever believes being able to make a realistic assessment. 

If there is no such person/group in this list, which can do an estimate how 
much of Qt is
affordable, an important aspect of the Qt 6 discussion can not actually be 
discussed. How
can Marc think about removing (or significantly changing) Qt due to ressource 
limits or
new strategic goals if the limits or goals are unknown?

Actions out of frustration are never a good idea. And pushing into a 
(technical) direction
that does not solve the underlying (strategical) problem is futile. 

-- 
Best Regards,
Bernhard Lindner

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


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 once supposed to be such a replacement, but it 
failed to a degree, that it became a candidate for removal for Qt6. A 
technology that needs more than 30 QObjects to create a button simply 
has no rights to survive only because of compatibility considerations.


Uwe

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


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" x86
> instructions from their CPUs! x86 has kept backwards compatibility with
> every single instruction for more than 30 years. This is the standard
> software libraries should be held to, too.
This is common practice to mark API deprecated in one major release and 
remove them in the next one. It helps not clutter an interface and keep 
it fresh and updated. Yes, it might break some code, but people will be 
receiving compiler warnings that some functionality has been marked as 
not recommended for using, and will have a plenty of time to replace it 
with recommended solution.

Regarding CPU, this is another level. I don't think that this comparison 
is suitable.

I don't want Qt to be in C++ situation: some usable subset and a pile 
of... old things, left for backward compatibility. Fine, it's already 
in, but there are no reasons to make it worse. As the framework 
maintainers we have to be more reasonable, I would say.

> Qt has long reached a point where it can be considered complete. Its main
> selling point is portability to many different platforms rather than some
> specific feature. Additional features don't necessarily need to be in the
> main Qt library, but can be in community-developed addons such as KDE
> Frameworks or such as the many third-party Qt-based Free Software libraries
> out there. (They can also be in Qt-Company-developed Qt Solutions if there
> is manpower left for that.)
>
> Qt has also become larger and larger over time (despite the removal of APIs
> considered obsolete). Just compare the size of the Qt 3 tarball with the
> size of the Qt 5 monolithic tarball. This is not the result of keeping old
> APIs around, but of feature creep.
>
> So I disagree with the assertion that Qt needs more features to remain
> competitive.
Qt is modular and is going to be more modular. Are there any problems 
with not using/building/supplying some modules?

Introducing (and maintaining after) new features is cool. Old and unused 
should be eliminated without mercy :)

On 6/3/19 1:34 PM, Kevin Kofler wrote:
> 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 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" x86
> instructions from their CPUs! x86 has kept backwards compatibility with
> every single instruction for more than 30 years. This is the standard
> software libraries should be held to, too.
>
>>> 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 quality decreases or some things have to get dropped.
> Qt has long reached a point where it can be considered complete. Its main
> selling point is portability to many different platforms rather than some
> specific feature. Additional features don't necessarily need to be in the
> main Qt library, but can be in community-developed addons such as KDE
> Frameworks or such as the many third-party Qt-based Free Software libraries
> out there. (They can also be in Qt-Company-developed Qt Solutions if there
> is manpower left for that.)
>
> Qt has also become larger and larger over time (despite the removal of APIs
> considered obsolete). Just compare the size of the Qt 3 tarball with the
> size of the Qt 5 monolithic tarball. This is not the result of keeping old
> APIs around, but of feature creep.
>
> So I disagree with the assertion that Qt needs more features to remain
> competitive.
>
>>> See also Boudewijn Rempt's blog post on the subject:
>>> https://valdyas.org/fading/hacking/happy-porting/
>> I agree with the principle (API breaks are painful), but I strongly
>> disagree with the idea that no API breaks can ever possibly happen. And
>> the specific example is a terrible one to make a point as the resulting
>> API break is trivial to work around (I defined such breakages
>> "scriptable").
> The Q_FOREACH to ranged for change is not as easy to port to as people
> think, because there are at least 2 pitfalls when porting to ranged for:
> 1. you have to add qAsConst or equivalent or you will be deep-copying your
> implicitly-shared CoW container,
> 2. code that was changing the container during the iteration, 

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 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" x86 
instructions from their CPUs! x86 has kept backwards compatibility with 
every single instruction for more than 30 years. This is the standard 
software libraries should be held to, too.

>> 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 quality decreases or some things have to get dropped.

Qt has long reached a point where it can be considered complete. Its main 
selling point is portability to many different platforms rather than some 
specific feature. Additional features don't necessarily need to be in the 
main Qt library, but can be in community-developed addons such as KDE 
Frameworks or such as the many third-party Qt-based Free Software libraries 
out there. (They can also be in Qt-Company-developed Qt Solutions if there 
is manpower left for that.)

Qt has also become larger and larger over time (despite the removal of APIs 
considered obsolete). Just compare the size of the Qt 3 tarball with the 
size of the Qt 5 monolithic tarball. This is not the result of keeping old 
APIs around, but of feature creep.

So I disagree with the assertion that Qt needs more features to remain 
competitive.

>> See also Boudewijn Rempt's blog post on the subject:
>> https://valdyas.org/fading/hacking/happy-porting/
> 
> I agree with the principle (API breaks are painful), but I strongly
> disagree with the idea that no API breaks can ever possibly happen. And
> the specific example is a terrible one to make a point as the resulting
> API break is trivial to work around (I defined such breakages
> "scriptable").

The Q_FOREACH to ranged for change is not as easy to port to as people 
think, because there are at least 2 pitfalls when porting to ranged for:
1. you have to add qAsConst or equivalent or you will be deep-copying your
   implicitly-shared CoW container,
2. code that was changing the container during the iteration, which worked
   just fine with Q_FOREACH (because the iteration would still be over the
   original unchanged container), will now crash without warning. Even
   qAsConst will not help you get a warning or error for it, because it only
   constifies the reference for the ranged for itself and not for the code
   within it.

This is effectively deprecating a safe construct for an unsafe one.

>> An array of pointers is the most efficient data structure in practice
>> (operations are at most O(n)), dropping it in favor of an O(mn) data
>> structure (where m = sizeof(T)) such as QVector is a pessimization. And
>> QList also has the prepend optimization that makes most prepends even
>> O(1) rather than O(n). I don't see why almost everybody hates it.
> 
> As written, the above makes no sense, as it looks like you're comparing
> apples and oranges: time complexities against space complexities.

I'm speaking exclusively of time complexities. The space only matters when 
it goes into the formula for the time, which is the case for QVector.

QList::insert and QList::removeAt have O(n) time complexity.
QVector::insert and QVector::removeAt have O(mn) time complexity.

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 
QVector operations are 100 times slower than the QList ones!

> The fact is: once one removes the big-O factors and deals with actual
> numbers and real world hardware, QVector becomes much better than QList
> as a _general purpose_ sequential container. Emphasis on the general
> purpose, please.

For me, the best general purpose container is the one that makes it hardest 
to run into big performance bottlenecks. The point being that it should be 
GENERAL purpose, i.e., work efficiently for as many use cases as possible, 
even if it requires compromises for some common ones. So an O(n) container 
is better than an O(mn) one, even if it is often marginally slower. And a 
container with prepend optimization is better than one without it.

I used array-of-pointer data structures almost exclusively even in plain C 
code and before Qt even introduced QList as it stands now. I find QList's 
API that hides the pointer dereferences, the allocations to hold the value 
copies, etc. (i.e., all the tedious parts of 

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 
>>> understand that the focus of development has shifted towards QML.
> 
>> Suppose you implement all planned actions for Qt6 (see your original 
>> e-mail). Are the
>> remaining components (those that are neither deprecated nor removed) of Qt6 
>> well
>> maintained and are there enough staff available not only to maintain them 
>> indefinitely
>> but to actively develop them further?
> 
> No answer to my question above?

Who do you expect an answer to this question from?

The Qt Company? The Qt community? Marc? Thiago?


Volker

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


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 we care about binary and source compatibility
> > within a major series, doing what we can for Qt 6.0 (and doing it
> > right) is the only option we have.
> 
> The problem is that we as a whole do not agree what "poorly designed
> architecture or APIs" means in detail anymore, sometimes even on a very
> fundamental level.
> 
> E.g. the previous consent on Qt providing consistency and convenience
> is challenged regularly by some.

I don't think there is an actual controversy there; the term "some" already 
seems to be an overstatement.


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


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 years ago. 
The only reason why the module ( = Qt on the desktop ) remains 
competitive is the lack of competition - including Qt/Quick modules.


My expectation for a major release like Qt6 would be to see Qt/Widgets 
being migrated to the newer graphic stack - even if this would result in 
substantial API incompatibilities.


Actually each major release should have a story, that has to do with 
some sort of innovation that might require to remove old stuff. But Qt6 
does not seem to have something like this and why is it necessary then 
f.e to remove deprecated/failed modules like QC1 ?


Uwe

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


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:
> 
> = Priority 1 =
> 
> == QSharedDataPointer / QExplicitlySharedDataPointer ==
> 
> These are basically Qt-internals, and should never have been public in the 
> first place. It's _because_ they are public that we have two of them, and 
> soon a third one (properly non-public): 
> https://codereview.qt-project.org/c/qt/qtbase/+/115213 That commit's message 
> also explains what's wrong with the QSDP and QESDP.
> 
I see no reason at all for removing those, quite to the contrary. They are very 
helpful for building refcounted classes (explicitly or implicitly shared).

> 
> == Q_FOREACH -> ranged for loops 
> (https://codereview.qt-project.org/c/qt/qtbase/+/147363) ==
> 
> Q_FOREACH is less readable (because it allows mutating the container under 
> iteration), and produces _a lot_ of code. It also is intrinsically tied to 
> just a few Qt containers (excluding QVLA). Ranged for loops work on anything, 
> incl. a C array. Also, as a macro, it will continue to cause problems down 
> the road (e.g. with modules). Being a macro also means that it cannot deal 
> with value_types that contain a comma.
> 
> === related: Q_FOREVER -> for(;;) ===
> 
> Suggested by Lars in ibid. Basically because it's a macro.

Right, I suggested this, mainly because I don’t think Q_FOREVER is nicer than 
for(;;) or while(true). But I don’t mind the macro and if it’s widely used we 
could simply keep it (it doesn’t cost us anything to have it).
> 
> 
> == 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(), which is just as 
> unsafe as with STL iterators. I also noted between 100b/loop and 5KiB for 
> four loops of text size savings.

I’m a bit torn here. On code review I gave a +1 on deprecating them, but I see 
that this could lead to a lot of porting effort on user code that makes 
extensive use of them. And the problem is that the porting can be non-trivial 
in cases where the list gets modified while iterating. So I think we should 
most likely keep them for Qt 6.
> 
> 
> == QScopedPointer -> std::unique_ptr ==
> 
> Suggested by Thiago on https://codereview.qt-project.org/c/qt/qtbase/+/261553
> 
> I agree. We now have std::unique_ptr, and it's movable. QScopedPointer had 
> the problem that it didn't know what it wanted to be: boost::scoped_ptr or 
> std::unique_ptr. A real scoped pointer would not offer release(), a 
> unique_ptr would need to provide move semantics. QScopedPointer has 
> release(), but no moves (were proposed, but not accepted).


> 
> 
> == QLinkedList -> std::list 
> (https://codereview.qt-project.org/c/qt/qtbase/+/261421) ==
> 
> Of the Qt containers, this one is the most-unused (in Qt code), as well as 
> the one that's furthest behind it's STL counter-part. Whenever I use 
> std::list, I use it for splice(), a function that just cannot be added to a 
> CoW container. Qt is already almost completely QLinkedList-free. Let's bury 
> QLinkedList.

It’s not used a whole lot, and I’m not against deprecating it. But do we need 
to remove it for 6.0? Or maybe go the route we thought about for other 
containers as well and have it wrap a std::list. ie. remove our implementation, 
keep our API.
> 
> 
> == qHash() -> std::hash ==
> 
> Suggested by Lars in https://codereview.qt-project.org/c/qt/qtbase/+/261819. 
> To be precise, he's suggesting to specialise std::hash and have qHash() call 
> std::hash.
> 
> Only problem I see so far is that std doesn't provide us with a tool to hash 
> composites. E.g. there's no std::hash for std::tuple (which would mean we can 
> std::tie the members and hash the result), and only C++17 adds some kind of 
> raw bits hashing (via std::string_view). We'd need to provide these building 
> blocks ourselves, which can be done, but it means we'll have at least _some_ 
> qHash()-like functions we need for std::hash<> implementations.
> 
> Actual problem?

I think this depends on whether we use std::unordered_map to implement QHash or 
not.
> 
> 
> == QPaintDevice ==
> 
> I'd like this to become a static interface. In very shortened terms: 
> everything that has a QPaintEngine *paintEngine() method is a paint device. 
> QPainter's ctor would become a template and do the virtual dispatch 
> internally, just like Sean Parent's document type in C++ Seasoning.
> 
> This would solve a lot of problems: QWidget would no longer need to use 
> multiple inheritance, and QImage and QPixmap would become proper value types, 
> without virtual functions that create problems with move semantics and 
> swapping.

I like this idea. It 

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.
> 
> However, apart from the specifics of why deprecating a certain class / what 
> to replace it with / etc., there's a bigger thing that needs to be clarified, 
> which is: what is the deprecation/removal model going into Qt 6.
> 
> 
> It is my understanding that the current plan is to:
> 
> * _remove_ from Qt 6.0 any API deprecated in Qt 5.x (for any x);
> 
> * in order to ease the migration from Qt 5, any API that is going to be 
> removed/changed in Qt 6.0 (for any reason) is also going to be deprecated in 
> Qt 5.latest (5.15 LTS, AFAIU).
> 
> 
> I guess that the idea is that the port to Qt 6 can then happen in multiple 
> steps:
> 
> 1) port to Qt 5.latest;
> 2) (enable and) fix all deprecation warnings;
> 3) port to Qt 6.
> 
> 
> If this is still the plan, I must say I am not a huge fan of it. It has all 
> the premises to be another Qt3->4 hit. Specifically:

Why do you think so? The plan above is actually stricter than what we did when 
moving from Qt 4 to Qt 5 (where (2) was only partially done).

So I believe that the plan above should not make it harder to move from 5 to 6 
than the Qt4->5 move. Unless we go completely crazy with deprecations in 5.15 
of course, but that’s something we should be careful about.

> 
> * It assumes that any breaking change will happen in Qt 5 first, signalled 
> via deprecation macros, then Qt 6 will simply remove the deprecated parts. As 
> we're already seeing with e.g. QList, this is not happening for all the 
> possible cases, meaning the porting steps above are incomplete and there will 
> be some extra porting fallout to take into account.
> 
> * It does not let users move away at their own pace. Qt 6.0 will be 
> inaccessible for existing Qt 5 software until one has ported away from every 
> deprecated API. If we keep deprecating things (and add replacements) up to 
> 5.latest, then this also makes it complicated for users to build libraries 
> and components targeting both Qt 5 and 6.

Removing deprecated functionality always forces the users hands. But at some 
point it has to be done, or we can never drop anything.

And btw, I’m not a fan of simply removing/deprecating tons of things without 
good reason (so I’m opposed to many of the things Marc brought up in the 
deprecation thread he initiated).
> 
> Such libraries may end up to only be able to target Qt 5.latest and 6 
> together, without resorting to #ifdefs or similar machinery in their code; 
> the reason is that only 5.latest would have the required replacement APIs for 
> the ones deprecated in 5.latest / removed from 6.0.
> 
> * It does not make a distinction w.r.t. _when_ an API has been deprecated. 
> IMHO there is a difference between an API deprecated in 5.0 and one 
> deprecated in 5.15; users had much more time to port away from the former. 
> Dropping them both on the floor in 6.0 seems very unfair to me, again forcing 
> users to tackle the deprecation _immediately_ if they want to port to Qt 6.

We can consider a staged approach, but there might be some cases, where we need 
to do a hard cut to get rid of some very heavy luggage for Qt. Where it doesn’t 
hurt us as much, deprecating and keeping it around in 6.0 is something we could 
discuss.
> 
> * It does not make a distinction between APIs for which we have a 
> straightforward / immediate / scriptable (!) replacement, and APIs for which 
> we don't (yet we'd like to get rid of them). Keeping the latter APIs as 
> stable and supported in Qt 6.0 means keeping them since 7.0 and then face 
> have the same problem again. But simply dropping them means pain for users.

As a general rule, we shouldn’t drop something where we do not have a 
replacement available. But there might be exceptions (XMLPatterns come to my 
mind).

Cheers,
Lars

> 
> 
> Given all the work that went into adding deprecation macros during Qt 5 
> lifetime (even the multiple incantations of them), would it be possible 
> somehow to avoid most of the source breaks caused by removal of the 
> deprecated APIs? I know that it's easier said than done, as it would require 
> doing this on a API-by-API basis rather than turning a big switch; but we 
> could find some compromise somewhere.
> 
> 
> Anyhow, flame away.
> 
> Thanks for reading,
> -- 
> Giuseppe D'Angelo | giuseppe.dang...@kdab.com | Senior Software Engineer
> KDAB (France) S.A.S., a KDAB Group company
> Tel. France +33 (0)4 90 84 08 53, http://www.kdab.com
> KDAB - The Qt, C++ and OpenGL Experts
> 
> ___
> Development mailing list
> Development@qt-project.org
> https://lists.qt-project.org/listinfo/development

___
Development ma

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
>> weight, or
>>  b) Distributors have to deal with the fact that some software
>> doesn't port and have to ship every version of qt side-by-side, or
>>  c) The software that doesn't port has to deal with the fact that it
>> will be dropped by distributions. But any software with sufficiently
>> many users to warrant packaging by the distributors should be able to
>> find a maintainer that at least can keep it compiling.
> 
> The answer is a mix of (b) and (c). Distributions don't ship every version 
> side by side, just one of each major version. Software that doesn't port gets 
> dropped when that major version is dropped.

Yes. (a) is not an option if we want to keep Qt alive in the long term.

Cheers,
Lars

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


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 functionality" is functionality that existing code
relies on and rightfully expects to remain there.


Rightfully? By what right exactly?



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 quality decreases or some things have to get dropped.




See also Boudewijn Rempt's blog post on the subject:
https://valdyas.org/fading/hacking/happy-porting/


I agree with the principle (API breaks are painful), but I strongly 
disagree with the idea that no API breaks can ever possibly happen. And 
the specific example is a terrible one to make a point as the resulting 
API break is trivial to work around (I defined such breakages "scriptable").




Changes such as deprecating or incompatibly rewriting a data
structure as central as QList (as seems to be already consensus for Qt 6)
are just a major disservice to developers.


... exactly, because it's an API break. How can we minimize the damage?


By simply not doing this change, not now, not ever.

An array of pointers is the most efficient data structure in practice
(operations are at most O(n)), dropping it in favor of an O(mn) data
structure (where m = sizeof(T)) such as QVector is a pessimization. And
QList also has the prepend optimization that makes most prepends even O(1)
rather than O(n). I don't see why almost everybody hates it.


As written, the above makes no sense, as it looks like you're comparing 
apples and oranges: time complexities against space complexities.


The fact is: once one removes the big-O factors and deals with actual 
numbers and real world hardware, QVector becomes much better than QList 
as a _general purpose_ sequential container. Emphasis on the general 
purpose, please.


Hence, we want Qt to move away from QList (and encourage users to do the 
same). The point of this thread, once more, was asking how to do that as 
painlessly as possible.







ABI breaks such as the QString
SSO (that also seems to be already consensus for Qt 6) are also
unnecessary and probably also counterproductive in some use cases.


What? Why?


For the "unnecessary" part, because Qt has been working fine without QString
SSO for years. 


Nice try: https://en.wikipedia.org/wiki/Appeal_to_tradition



Whether it is actually a performance win or not is irrelevant
because code manipulating QString is almost never performance-critical. (The
bottleneck is typically the user.)


"Almost never" is simply wrong (or: [citation needed]).

First and foremost, it's wrong because containers and core classes in 
general are the ones MORE likely to be used in performance critical 
scenarios.


Second, string classes in all major C++ libraries and frameworks are 
deploying SSO *because* it is a performance win.


Third, in a library, *every codepath* is a bottleneck for some user, so 
the library must to be as efficient as possible everywhere.




For the "probably also counterproductive" part:
* Because there are surely architectures or environments where copying 256
   bytes (or whatever the SSO max length actually is) 


This is a straw man argument, specifically an exaggeration.

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




* Because the total memory use for an array of QString will likely be
   higher, due to the padding (space reserved for SSO)?


... or much, much, much lower because you don't have to allocate every 
string's payload separately.




* Because it means a QString will no longer fit in a pointer slot, which
   breaks the QList optimization and is the main reason why people want to
   get rid of QList as we know it now?
QString with SSO will make Qt5List work in array-of-pointers 
mode, instead of pure vector mode, yes. But the decision of moving away 
from QList had very little to do with this particular point. And we 
already had our share of this: QList, QList, 
QList, and so on, see the other email.



***ANYHOW***:

This thread was about managing API breaks. Adding SSO to QString is not 
meant to be an API break (*). Please stop derailing the thread.



(*) Emphasis on _meant_, because obviously it yields observable side 
effects.


Thanks,
--
Giuseppe D'Angelo | giuseppe.dang...@kdab.com | Senior Software Engineer
KDAB (France) S.A.S., a KDAB Group company
Tel. France +33 (0)4 90 84 08 53, http://www.kdab.com
KDAB - The Qt, C++ and OpenGL Experts



smime.p7s
Description: Firma crittografica S/MIME
___
Development mailing list
Developm

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 10:1 with zstd). I'd simply make that a read-only sharable
> > variable, which we can easily create with a C++11 raw string.
> 
> https://codereview.qt-project.org/c/qt/qtbase/+/263548
> 
> Unfortunately, MSVC doesn't want to cooperate:
> 
> .\qmimeprovider_database.cpp(1270): fatal error C1091: compiler limit:
> string exceeds 65535 bytes in length
> 

moc had similar problem, it was solved by generating something like that:

struct {
  char[65535] 
  char[65535]
  
}

instead of a string.

Cheers,
  Jędrek



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