Re: [Development] QFuture and C++20

[Konstantin Tokarev]

03.03.2021, 19:15, "Allan Sandfeld Jensen" :
> On Mittwoch, 3. März 2021 09:32:33 CET Jason H wrote:
>>  I saw Lars's Qt6 talk on youtube, where he said Qt6 requires C++17. He also
>>  mentioned the new QFuture:: then() function... This is an improvement, but
>>  it makes Qt code look like Javascript in 2015.
>>
>>  In C++20 there are async/await mechanisms. Ideally ask that then() code word
>>  be replacing by 'await'. Are there any plans to provide C++20 async/await
>>  interoperability with QFuture?
>
> They are only halfway there in C++20, AFAIK it is missing the standard library
> parts, which means it is not really usable for most people until C++23, so I
> assume we have time before anyone will actually have interaction between the
> two types of code.
>
> Unless I missed something?

What about [1] which requires only C++11?

[1] https://github.com/vmilea/CppAsync


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

Re: [Development] Building additional components with Conan for Qt 6

[Konstantin Tokarev]

14.10.2020, 09:14, "Heikki Halmet" :
> Hi,
>
> I'm not the expert when it comes to Conan so I'm asking what would be the 
> main gain we would achieve by using Conan instead of scripts we currently 
> have..? List of packages and versions in one place? With quick review this 
> would take lot of effort and honestly I'm pretty skeptical about the gain we 
> would have vs time we would spent to make needed changes.

Hi,

I guess we have a bit of misunderstanding here.

My proposition is to use Conan for building libraries which are currently 
bundled with Qt. Rationale:

1. Libraries bundled with qtbase create troubles for downstream projects and 
other Qt modules. There should be a clean way to use the same versions of 
dependencies as used by qtbase binaries and an easy way to rebuild everything 
with newer dependency version.
2. Custom bundling system requires additional maintenance and replace original 
upstream build system with qmake or cmake. For comparison, Conan packages from 
conan-center-index are maintained by the community, and tend to use original 
upstream build system which simplifies updates.
3. As we are introducing Conan as a way of using 3rd party libraries from Qt 
modules, it would makes sense to standardize on that instead of using different 
ways for different libraries

Also, if we go this way, it would also make sense to use Conan for libraries 
like icu and openssl which are currently not bundled, but built in provisioning 
scripts. This would reduce complexity of provisioning (you are right, it's done 
by moving complexity into conanfiles, but they can be easily tested and 
maintained without involving Coin). And, again, use the same way for dealing 
with all Qt dependencies.

As for replacing all provisioning scripts with Conan, I don't think it makes 
much sense, however Toni was interested so I described details how it could be 
done.

Anyway, even if qtbase bundling and building dependencies in Coin are left as 
is, we still need to test using Conan packages in CI in modules where it is 
going to be supported (qtnetworkauth, qt3d, ...) to prevent regressions. To 
avoid network downloads in CI jobs it would be better to install necessary 
packages during provisioning stage. On Windows it could be done by reusing 
existing conan.ps1 machinery (possibly adjusting it if needed)


>
  2) Build stuff from sources in provisioning time, sometimes in a 
 sophisticated way (e.g. 
 https://code.qt.io/cgit/qt/qt5.git/tree/coin/provisioning/common/windows/android-openssl.ps1).
  These can be (and IMO should be) replaced with Conan, to reduce 
 provisioning time and complexity.
>>>  Of course, it's also possible to use conan packages for category (1), 
>>> however this may require writing quite a few custom recipes (see manual 
>>> [1]), possibly containing more boilerplate than existing ps1 snippets. 
>>> However, this would allow to have a nice list of all provisioned packages 
>>> with >> their versions in one place.
>
> You mean reducing provisioning time when everything would be prebuilt 
> already? This is something we could change to existing scripts already. 
> Script could check from the local cache do we have the prebuilt stuff and if 
> don't then build those and add those to cache. And next time use prebuilt 
> package.


So adding new package to CI would require going through all kinds of pain 
making it building in Coin environment without access to VM, instead of just 
testing it on local machine and/or public CI and uploading final result. Also, 
build dependencies of package will reside in provisioning image possibly 
affecting other scripts (e.g. msys2 brought by android-openssl.ps1).

With Conan project is guaranteed to find required dependencies in expected 
place. There is no such issue as "how to prevent CMake finding this header or 
library in a place which I don't want", which easily happens in Coin and is 
hard to solve without introducing Coin-specific hacks.


> Currently, e.g. with gcc installation, script will use prebuilt package if it 
> exist and if don't it will be built from sources. But in some cases we have 
> just prebuilt the package and added it to cache without source build option 
> in the script.
> With installers I don't think there's no point to start putting those under 
> Conan packages. I think the only thing we would gain here is the listing 
> thing.
> And what comes to complexity - if we would start using Conan for everything 
> we still would need to start creating quite complexity conanfiles for it, 
> right? I guess the gain in some cases would be that we could use the same 
> conanfile in unix and windows.
>
  In current implementation stuff is loaded from Internet, but all packages 
 are verified against manifests stored in provisioning repo. But you can 
 also set up internal Conan repository by running instance of Artifactory 
 CE.
>
> Yes, we would have to use our own internal Conan repo and the 

Re: [Development] Building additional components with Conan for Qt 6

[Konstantin Tokarev]

08.10.2020, 11:59, "Toni Saario" :
>>> Most of provisioning scripts fall into 2 categories:
>>> 1) Download installer (or other binary package) of 3rd party stuff, verify 
>>> checksum, install. These scripts are quite simple.
>>> 2) Build stuff from sources in provisioning time, sometimes in a 
>>> sophisticated way (e.g. 
>>> https://code.qt.io/cgit/qt/qt5.git/tree/coin/provisioning/common/windows/android-openssl.ps1).
>>>  These can be (and IMO should be) replaced with Conan, to reduce 
>>> provisioning time and complexity.
>>
>> Of course, it's also possible to use conan packages for category (1), 
>> however this may require writing quite a few custom recipes (see manual 
>> [1]), possibly containing more boilerplate than existing ps1 snippets. 
>> However, this would allow to have a nice list of all provisioned packages 
>> with their versions in one place.
>>
>> [1] 
>> https://docs.conan.io/en/latest/devtools/create_installer_packages.html#create-installer-packages
> That is what the automatic documentation tools are asking. Might be stupid 
> questions due to the knowledge. We would install all dependencies during the 
> provisioning and during the builds conan only exposes dependencies listed in 
> the conanfile?

Yes. There would be no network downloads or unnecessary compilations during 
product builds.

> One thing that conflicts a little bit here is that we want to use cached 
>stuff from our servers instead of downloading from the internet in the 
>provisioning and also have the provisioning to be runnable by anyone, but i 
>guess that if the conan caches all the packages then it equals pretty much the 
>same.

In current implementation stuff is loaded from Internet, but all packages are 
verified against manifests stored in provisioning repo. But you can also set up 
internal Conan repository by running instance of Artifactory CE.


>>>> As for provisioning and why the CI images are different from what are 
>>>> documented, biggest problem there is that the images are used by other 
>>>> components also e.g. RTA testing. Those require some additional stuff and 
>>>> provisioning currently installs everything. AFAIK also all the optional 
>>>> dependencies are installed, this makes it hard to distinguish between them 
>>>> and required dependencies because both are always present. These make it 
>>>> easy that new dependencies etc. slip through unnoticed.
>>>
>>> Note that when Conan packages are used via conanfiles (i.e. as it's 
>>> originally intended by Conan developers), there cannot be any dependency 
>>> slips because Conan dependencies don't become visible to any project which 
>>> doesn't require them via conanfile (directly or indirectly).
>>
>> In this case each testing activity should have its own conanfile with a list 
>> of dependencies, as well as each Qt project which uses them for building.
> Ultimately where would all the conanfiles sit? Currently we only use qt5 
> repository during provisioning and with conan each repo would have its own 
> conanfiles which needs to be read when running provisioning? How big 
> maintenance burden those conanfiles become, are common files across repos 
> possible?

One possible way (which current implementation uses) is to store all conanfiles 
in qt5 repository. For local building of individual modules it's possible to 
use conanfiles right from there, as there are no hard requirements on location 
or filename of conanfile.

>
> I do not see why it would be impossible to use conan in provisioning, the 
> transition is quite big effort though, and some cherry-picks need to be 
> translated to the old format afterwards. Theres also many other things I 
> cannot answer now related to artifactory and any legal sides to distributing 
> the packages etc. 

IANAL, but I don't see why there should be any legal differences between 
distributing 3rd party code as bundled library or Conan package. Of course, 
adding new dependencies will require attention to their licensing terms. Also, 
usage of Conan packages in Coin is not a distribution, only files imported to 
final packages do count.

See also https://docs.conan.io/en/latest/howtos/collect_licenses.html

>There seems to be a lot of research into conan by Iikka, but i cannot find any 
>related to building all the qt modules with it. I am sure it requires 
>developer attention also, related to the CMake changes that needs to be done. 
>It has a low priority now. https://bugreports.qt.io/browse/QTBUG-74397
>
> 
> From: Konstantin Tokarev 
> Sent: Wednesday, October 7, 2020 6:44 PM
&

Re: [Development] Windows Timer Resolution: The Great Rule Change

[Konstantin Tokarev]

08.10.2020, 11:46, "Philippe" :
> On Wed, 7 Oct 2020 17:34:43 -0700
> Thiago Macieira  wrote:
>
>>  Now, the question is how WaitFor{SingleObject,MultipleObjects} are affected.
>>  Does this mean that asking for a timeout of 2 milliseconds could result in
>>  being 13 seconds too late?
>
> I just did a test, and yes, both WaitForSingleObject and
> WaitForMultipleObjects wait at least 15 milliseconds when the events are not
> signaled :(

Is resolution of QElapsedTimer limited to 15 ms as well? If it's more find 
grained
you can try busy-waiting until required time elapses.


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

Re: [Development] Building additional components with Conan for Qt 6

[Konstantin Tokarev]

02.10.2020, 16:20, "Konstantin Tokarev" :
> 02.10.2020, 15:53, "Toni Saario" :
>>  One thing to check is that how much the provisioning it is possible to 
>> translate to Conan, I would believe that in the end it does not work for 
>> everything.
>
> Most of provisioning scripts fall into 2 categories:
> 1) Download installer (or other binary package) of 3rd party stuff, verify 
> checksum, install. These scripts are quite simple.
> 2) Build stuff from sources in provisioning time, sometimes in a 
> sophisticated way (e.g. 
> https://code.qt.io/cgit/qt/qt5.git/tree/coin/provisioning/common/windows/android-openssl.ps1).
>  These can be (and IMO should be) replaced with Conan, to reduce provisioning 
> time and complexity.

Of course, it's also possible to use conan packages for category (1), however 
this may require writing quite a few custom recipes (see manual [1]), possibly 
containing more boilerplate than existing ps1 snippets. However, this would 
allow to have a nice list of all provisioned packages with their versions in 
one place.

[1] 
https://docs.conan.io/en/latest/devtools/create_installer_packages.html#create-installer-packages

>>  As for provisioning and why the CI images are different from what are 
>> documented, biggest problem there is that the images are used by other 
>> components also e.g. RTA testing. Those require some additional stuff and 
>> provisioning currently installs everything. AFAIK also all the optional 
>> dependencies are installed, this makes it hard to distinguish between them 
>> and required dependencies because both are always present. These make it 
>> easy that new dependencies etc. slip through unnoticed.
>
> Note that when Conan packages are used via conanfiles (i.e. as it's 
> originally intended by Conan developers), there cannot be any dependency 
> slips because Conan dependencies don't become visible to any project which 
> doesn't require them via conanfile (directly or indirectly).

In this case each testing activity should have its own conanfile with a list of 
dependencies, as well as each Qt project which uses them for building.

>
> I can see another possible way to use Conan in CI - install packages into the 
> system via "deploy" generator so that Qt build system can find them without 
> any knowledge of Conan. I guess this way may be called "Ossi-friendly because 
> Ossi was adamantly opposed to any explicit support of Conan in build system, 
> see e.g. https://codereview.qt-project.org/c/qt/qtbase/+/184241, however this 
> way indeed may cause dependency slips.


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

Re: [Development] How to perform unattended installations of Qt? (Was: Changes to Qt offering)

[Konstantin Tokarev]

04.10.2020, 01:03, "Croitor Alexandru" :
> On Sat, Oct 3, 2020 at 11:07 PM Konstantin Tokarev  wrote:
>> For comparison, using simple python script from [1] (which was mentioned on 
>> the list a few times before)
>
> Hmm, maybe my search-foo is weak, but searching for 'qt-downloader' in my 
> mail client only shows this
> mail thread as the single result. I've seen references to other tools though, 
> like the script from
> the qbs repo, Cristian's and Volker's scripts, and some other variations.

Seems like you are right, it was not in the list but in the long-running 
https://bugreports.qt.io/browse/QTIFW-166
It was install-qt.sh from qbs repo which was mentioned a couple of times (which 
also works well but ).

BTW, I've recently discovered another script [1]  which seems to be quite 
popular. I haven't tried it myself yet but
looks like it allows fine-grained installation. It even has ready to use github 
action [2].

[1] https://github.com/miurahr/aqtinstall
[2] https://github.com/jurplel/install-qt-action

>
>> results in my workflow [2] in 56 seconds on Windows [3] and 20 seconds on 
>> macOS with
>> *NO CACHE* and *NO CREDENTIALS*. Time is saved because only used Qt modules 
>> are installed,
>> online installer doesn't provide this kind of granularity.
>
> Indeed I tried it out, and it works fast and the DX is nice: discoverable 
> arguments,
> finer module granularity, support for ios and android, no credentials needed.
>
> I'm a bit iffy on the patching it does to make qmake work (regarding the 
> license check), but it's not the first time I see it.
> And parsing the xml files feels like depending on an implementation detail 
> that might change in the future,
> but I guess it worked well so far.
>
> I hope the online installer CLI DX will improve in time to offer similar 
> granularity and user-friendliness,
> with the advantage that it will provide access to commercial packages as well.
>
>> [1] https://github.com/engnr/qt-downloader
>> [2] 
>> https://github.com/qtwebkit/qtwebkit/blob/qtwebkit-dev-wip/.github/workflows/build_cmake.yml#L84
>> https://github.com/qtwebkit/qtwebkit/blob/qtwebkit-dev-wip/.github/workflows/build_cmake.yml#L100
>> [3] 
>> https://github.com/qtwebkit/qtwebkit/runs/1195504225?check_suite_focus=true
>> [4] 
>> https://github.com/qtwebkit/qtwebkit/runs/1195504192?check_suite_focus=true


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

Re: [Development] How to perform unattended installations of Qt? (Was: Changes to Qt offering)

[Konstantin Tokarev]

03.10.2020, 20:26, "Croitor Alexandru" :
> Hi all,
>
> I spent a bit of time trying to get a project of mine to build in Github 
> Actions with a Qt installed via the new online installer.
>
> I used Volker's script as a base, modified it a bit, and created a github 
> workflow that installs Qt 5.15.1 essentials package.
> The workflow then builds a qmake app project and publishes a macdeploy'ed 
> archive as a Github artifact.
>
> I also got some inspiration from qt-creator's and Cristian's ccache GA 
> workflows.
> So credit goes to Volker, Cristian, and anyone that worked on the creator 
> workflow.
>
> Here's the gist of what I have so far: 
> https://gist.github.com/alcroito/549d47b4d961936a24a518aaada685f3
>
> To make the online installer work in the CI setting, i first downloaded it 
> locally and logged in with my account,
> extracted the created JWT token from ~/Library/Application\ 
> Support/Qt/qtaccount.ini
> and saved it as a secret that's set as an environment variable in the CI.
>
> Not sure for how long the token is valid though.
>
> The workflow in the linked gist also uses GA's caching action, to cache the 
> installed Qt (so as not to hammer Qt's mirrors).
> It also reduces the overall Qt installation time:
>
>               initial install time    restore from cache    cache size
> Linux        2m 58s                  35s                           695MB
> Windows   4m 27s                 1m 5s                       783MB
> macOS      3m38s                  22s                           590MB

For comparison, using simple python script from [1] (which was mentioned on the 
list a few times before)
results in my workflow [2] in 56 seconds on Windows [3] and 20 seconds on macOS 
with
*NO CACHE* and *NO CREDENTIALS*. Time is saved because only used Qt modules are 
installed,
online installer doesn't provide this kind of granularity.

[1] https://github.com/engnr/qt-downloader
[2] 
https://github.com/qtwebkit/qtwebkit/blob/qtwebkit-dev-wip/.github/workflows/build_cmake.yml#L84
https://github.com/qtwebkit/qtwebkit/blob/qtwebkit-dev-wip/.github/workflows/build_cmake.yml#L100
[3] https://github.com/qtwebkit/qtwebkit/runs/1195504225?check_suite_focus=true
[4] https://github.com/qtwebkit/qtwebkit/runs/1195504192?check_suite_focus=true


>
> Hope the gist proves useful to someone.
>
> I'm pondering continuing work on the installer script as well as the 
> build_with_qmake script, and perhaps package them as GA actions
> if it's feasible and useful.
>
> On Wed, Sep 16, 2020 at 5:25 PM Volker Hilsheimer  
> wrote:
>>> On 16 Sep 2020, at 17:05, Thiago Macieira  wrote:
>>>
>>> On Wednesday, 16 September 2020 03:39:58 PDT Volker Hilsheimer wrote:
 I’ve recently been doing a bit of work to automate the testing of the 
 online
 installer and the Qt packages through minicoin [1] recently; check

 https://git.qt.io/vohilshe/minicoin/-/tree/master/minicoin/jobs/install-onli
 ne

 for a cmake script that downloads the Qt Online installer and installs the
 latest Qt 6 snapshot, on any host platform Qt supports.

 I’m running things regularly on local and cloud-hosted VMs running
 Windows10, macOS, and Ubuntu. FWIW, the xdotool stuff is only needed
 because I also want to run some basic tests that require a user session.
>>>
>>> Thanks, Volker
>>>
>>> The script is very understandable. When I have the time, I'll take a look at
>>> setting up a GitHub Action for installing Qt on their Linux and Mac hosts. I
>>> really need to get away from Travis, since that is taking 2-3 days to test a
>>> pull request.
>>>
>>> One question: the downloads are currently anonymous. I understood from 
>>> earlier
>>> in this thread that would not remain the case. Did I misunderstand or is 
>>> that
>>> still a change to come?
>>>
>>> --
>>> Thiago Macieira - thiago.macieira (AT) intel.com
>>>  Software Architect - Intel DPG Cloud Engineering
>>
>> The download in the cmake script (and thanks to Christian Adam for some of 
>> the ideas to it) just pulls down the online installer.
>>
>> The online installer then downloads the actual packages, and expects your 
>> qtaccount.ini file to have the credentials and license information.
>>
>> The other scripts take care of that, and are part of how jobs are designed 
>> in minicoin: the pre-run script runs on the host, takes your local 
>> qtaccount.ini file, and puts it into the job; minicoin uploads the entire 
>> job directory ot the VM; the “main” scripts then run on the guest, and put 
>> them where the installer expects them.
>>
>> Cheers,
>> Volker
>>
>> ___
>> Development mailing list
>> Development@qt-project.org
>> https://lists.qt-project.org/listinfo/development
> ,
>
> ___
> Development mailing list
> Development@qt-project.org
> https://lists.qt-project.org/listinfo/development


-- 
Regards,
Konstantin

Re: [Development] Building additional components with Conan for Qt 6

[Konstantin Tokarev]

02.10.2020, 15:53, "Toni Saario" :
> As Iikka said that there has not been plans to use Conan when provisioning 
> the images for CI.

That's sad, I hoped plan was to use Conan for QtBase dependencies eventually to 
avoid custom bundling code and 3rd-party sources checked into the repo. And 
also eliminate potential for conflicts when user's project wants to use the 
same libraries as bundled into QtBase

>
> However there has been some discussions how to make the provisioning easier 
> to manage and have some documentability in them. Currently the provisioning 
> is just a pile of scripts which have zero value for documentation tools. 
> Easiest solution for this would be to list the dependencies on some other 
> file in common format and then install listed dependencies with simple 
> scripts. About using Conan there, I cannot really say anything about it with 
> my knowledge about it.
>
> Another thing is that there are many items built during provisioning which 
> become dependencies, can we reduce the provisioning workload by having these 
> cached in Conan storage?

Yes, I've done this for QtWebKit dependencies. Packages of dependencies are 
built on public CI services for all necessary compilers and uploaded to 
https://bintray.com/qtproject/, then during provisioning they are downloaded 
and verified.

> One thing to check is that how much the provisioning it is possible to 
> translate to Conan, I would believe that in the end it does not work for 
> everything.

Most of provisioning scripts fall into 2 categories:
1) Download installer (or other binary package) of 3rd party stuff, verify 
checksum, install. These scripts are quite simple.
2) Build stuff from sources in provisioning time, sometimes in a sophisticated 
way (e.g. 
https://code.qt.io/cgit/qt/qt5.git/tree/coin/provisioning/common/windows/android-openssl.ps1).
 These can be (and IMO should be) replaced with Conan, to reduce provisioning 
time and complexity.

>
> As for provisioning and why the CI images are different from what are 
> documented, biggest problem there is that the images are used by other 
> components also e.g. RTA testing. Those require some additional stuff and 
> provisioning currently installs everything. AFAIK also all the optional 
> dependencies are installed, this makes it hard to distinguish between them 
> and required dependencies because both are always present. These make it easy 
> that new dependencies etc. slip through unnoticed.

Note that when Conan packages are used via conanfiles (i.e. as it's originally 
intended by Conan developers), there cannot be any dependency slips because 
Conan dependencies don't become visible to any project which doesn't require 
them via conanfile (directly or indirectly).

I can see another possible way to use Conan in CI - install packages into the 
system via "deploy" generator so that Qt build system can find them without any 
knowledge of Conan. I guess this way may be called "Ossi-friendly because Ossi 
was adamantly opposed to any explicit support of Conan in build system, see 
e.g. https://codereview.qt-project.org/c/qt/qtbase/+/184241, however this way 
indeed may cause dependency slips.

>
> -Toni
>
> 
> From: Konstantin Tokarev 
> Sent: Friday, October 2, 2020 3:20 PM
> To: Iikka Eklund ; Richard Weickelt 
> ; development@qt-project.org 
> ; Toni Saario 
> Subject: Re: [Development] Building additional components with Conan for Qt 6
>
> 02.10.2020, 14:47, "Iikka Eklund" :
>> Hi Konstantin, all,
>>
>>>>  thanks for the heads up. I have some further questions:
>>>>
>>>>  1. Will Conan be used to manage dependencies of Qt as well?
>>>>
>>>> If this is the plan, note that there is infrastructure [1] for using Conan 
>>>> in provisioning images,
>>>> with verification of downloaded file checksums and build reproducibility 
>>>> for each qt5 commit [2].
>>
>> Regarding Qt CI @Toni Saario is the best one to answer on this, though I 
>> haven't heard
>> if there are plans to use Conan more extensively by CI/provisioning at this 
>> point?
>
> From my experience, when the way project is built in CI is radically 
> different from a way suggested to
> the end user, it inevitably leads to troubles. Users hit unexpected errors 
> (in this case they may be
> caused by changes in 3rd party Conan recipes/packages, or by contributors to 
> Qt module which
> don't use Conan), and they come back to me asking for solution.
>
>>
>> What comes to add-ons 
>> (https://doc-snapshots.qt.io/qt6-dev/qtmodules.html#qt-add-ons) as mentioned
>> earlier the idea is to release add-ons as src packages accompanied with 

[Development] http://download.qt.io/new_archive/qt/

[Konstantin Tokarev]

Hello,

Seems like a lot of files were removed today from 
http://download.qt.io/new_archive/qt/
Was it intentional? Are these archives available somewhere else?

-- 
Regards,
Konstantin

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

Re: [Development] Building additional components with Conan for Qt 6

[Konstantin Tokarev]

02.10.2020, 14:47, "Iikka Eklund" :
> Hi Konstantin, all,
>
>>>  thanks for the heads up. I have some further questions:
>>>
>>>  1. Will Conan be used to manage dependencies of Qt as well?
>>>
>>> If this is the plan, note that there is infrastructure [1] for using Conan 
>>> in provisioning images,
>>> with verification of downloaded file checksums and build reproducibility 
>>> for each qt5 commit [2].
>
> Regarding Qt CI @Toni Saario is the best one to answer on this, though I 
> haven't heard
> if there are plans to use Conan more extensively by CI/provisioning at this 
> point?

From my experience, when the way project is built in CI is radically different 
from a way suggested to
the end user, it inevitably leads to troubles. Users hit unexpected errors (in 
this case they may be
caused by changes in 3rd party Conan recipes/packages, or by contributors to Qt 
module which
don't use Conan), and they come back to me asking for solution.

>
> What comes to add-ons 
> (https://doc-snapshots.qt.io/qt6-dev/qtmodules.html#qt-add-ons) as mentioned
> earlier the idea is to release add-ons as src packages accompanied with 
> conanfile.py i.e. the build recipe.
> If the add-on depends on 3rd party libraries which are available e.g. in 
> conan-center the recipe could
> naturally utilize packages from there (openssl, zlib, etc.).
>
>> 2. How will the recipes be managed and where on code.qt.io can I find 
>>them?
>
> The recipes of the first two add-ons are not part of the source repositories 
> yet, probably should be.
> Though there are some drawbacks in keeping the recipes and sources in the 
> same repo
> (some related discussion https://github.com/conan-io/conan/issues/4734).
>
> Currently the recipes are part of an internal packaging repository but the 
> current recipes can be found from the src
> installation directory: "6.0.0/Src/qtnetworkauth/conanfile.py" after you have 
> installed an add-on package.
>
> Iikka Eklund
> Senior Software Engineer
>
> iikka.ekl...@qt.io
> http://qt.io
>
> 
> From: Konstantin Tokarev 
> Sent: Friday, October 2, 2020 12:15 PM
> To: Richard Weickelt ; Iikka Eklund 
> ; development@qt-project.org 
> Subject: Spam: Re: [Development] Building additional components with Conan 
> for Qt 6
>
> 01.10.2020, 16:16, "Konstantin Tokarev" :
>> 01.10.2020, 16:07, "Richard Weickelt" :
>>>  Hello Ilkka,
>>>
>>>  thanks for the heads up. I have some further questions:
>>>
>>>  1. Will Conan be used to manage dependencies of Qt as well?
>>
>> If this is the plan, note that there is infrastructure [1] for using Conan 
>> in provisioning images,
>> with verification of downloaded file checksums and build reproducibility for 
>> each qt5 commit [2].
>>
>> If you are interested in details we could discuss them in depth in IRC.
>>
>> [1] 
>> https://code.qt.io/cgit/qt/qt5.git/tree/coin/provisioning/common/windows/conan.ps1
>> [2] requires https://codereview.qt-project.org/c/qt/qt5/+/313930 to handle 
>> situations when the same package version is rebuilt without version bump
>
> Iikka, any comments?
>
> --
> Regards,
> Konstantin


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

Re: [Development] Building additional components with Conan for Qt 6

[Konstantin Tokarev]

01.10.2020, 16:16, "Konstantin Tokarev" :
> 01.10.2020, 16:07, "Richard Weickelt" :
>>  Hello Ilkka,
>>
>>  thanks for the heads up. I have some further questions:
>>
>>  1. Will Conan be used to manage dependencies of Qt as well?
>
> If this is the plan, note that there is infrastructure [1] for using Conan in 
> provisioning images,
> with verification of downloaded file checksums and build reproducibility for 
> each qt5 commit [2].
>
> If you are interested in details we could discuss them in depth in IRC.
>
> [1] 
> https://code.qt.io/cgit/qt/qt5.git/tree/coin/provisioning/common/windows/conan.ps1
> [2] requires https://codereview.qt-project.org/c/qt/qt5/+/313930 to handle 
> situations when the same package version is rebuilt without version bump

Iikka, any comments?

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

Re: [Development] Building additional components with Conan for Qt 6

[Konstantin Tokarev]

01.10.2020, 15:37, "Iikka Eklund" :
> To make it easier to leverage new package manager functionality Qt Installer 
> starts providing conan(.exe) client (https://conan.io)
> which can be used to build the additional libraries from source packages 
> along with your CMake project.

FWIW, Conan supports not only CMake but many build systems, including qmake, 
qbs, and even msbuild.

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

Re: [Development] Building additional components with Conan for Qt 6

[Konstantin Tokarev]

01.10.2020, 16:07, "Richard Weickelt" :
> Hello Ilkka,
>
> thanks for the heads up. I have some further questions:
>
> 1. Will Conan be used to manage dependencies of Qt as well?

If this is the plan, note that there is infrastructure [1] for using Conan in 
provisioning images,
with verification of downloaded file checksums and build reproducibility for 
each qt5 commit [2].

If you are interested in details we could discuss them in depth in IRC.

[1] 
https://code.qt.io/cgit/qt/qt5.git/tree/coin/provisioning/common/windows/conan.ps1
[2] requires https://codereview.qt-project.org/c/qt/qt5/+/313930 to handle 
situations when the same package version is rebuilt without version bump

> 2. How will the recipes be managed and where on code.qt.io can I find them?
> 3. Is TQtC going to host a Conan repository for binary packages as well?
> 4. What is the Qt Company's position regarding conan-center?
>
> Thanks
> BR
> Richard Weickelt
> ___
> 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

[Development] How to debug segfaulting test in Coin

[Konstantin Tokarev]

Hello,

What is the usual procedure of debuggin test segfaults?

As far as I can see now all configurations print
"Skip uploading core files because CORE_FILES_PATH is not set in the 
environment"
so it's not possible to get any further then fact that test finished with 
segmentation fault.

Is there any way to enable core files in custom build configuration? If yes, 
will Coin
automatically load core and print backtrace to log or some other actions are 
needed?

-- 
Regards,
Konstantin

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

Re: [Development] QVariant comparison in Qt6

[Konstantin Tokarev]

18.09.2020, 11:40, "Lars Knoll" :
>>  On 18 Sep 2020, at 10:28, Albert Astals Cid  
>> wrote:
>>
>>  El divendres, 18 de setembre de 2020, a les 10:22:16 CEST, Lars Knoll va 
>> escriure:
>>>  Sorting and equality are two different things. QVariant has never supported
>>>  a lessThan operator.
>>
>>  Yes, it has
>>
>>  
>> https://code.qt.io/cgit/qt/qtbase.git/tree/src/corelib/kernel/qvariant.h?h=5.15#n467
>
> You’re right. I thought it didn’t support that.
>
> What is it you need? Just some total ordering of variants? The method you 
> mentioned in QAbstractItemModel also only does ordering for some types, 
> otherwise falling back to strings.

In Qt4 times comparison operators for QVariant were missing and from my 
experience main limitation was that it wasn't possible to have QVariant as a 
key in QMap without defining one manually.

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

Re: [Development] Applications using -fno-rtti

[Konstantin Tokarev]

20.06.2020, 23:49, "Thiago Macieira" :
> On Saturday, 20 June 2020 11:31:25 PDT Alberto Mardegan wrote:
>>  I think I missed an announcement about Qt applications having to use
>>  RTTI; on the opposite, I thought that the whole point of QMetaObject was
>>  not to require RTTI support; has this changed?
>
> As you can see from the commit, no provision was made for no-RTTI builds. I
> don't think they've ben allowed since 5.0.
>
> No-exceptions is still allowed. No-RTTI is not.

So, any Qt code is allowed crash if user code is compiled with disabled RTTI?
Wonderful.

-- 
Regards,
Konstantin

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

Re: [Development] Applications using -fno-rtti

[Konstantin Tokarev]

20.06.2020, 22:12, "Allan Sandfeld Jensen" :
> On Samstag, 20. Juni 2020 21:00:27 CEST Alberto Mardegan wrote:
>>  On 20/06/20 21:42, Konstantin Tokarev wrote:
>>  > Comparing metaObject() with staticMetaObject() is wrong because it would
>>  > fail even for QProcess.
>>
>>  I didn't try, but why would it fail?
>>
>>  > OTOH, using qobject_cast would handle classes derived
>>  > from QProcess correctly, unlike code with typeid().
>>
>>  But how would you use qobject_cast in this case? We don't know what
>>  class to cast to; we only want to know if we are a subclass of QProcess.
>
> Can't you just check if a cast to QProcess succedes or fails then?
>

Sorry, I haven't read the context carefully. In this particular case it's known
that q is always instance of QProcess or derived class, and subject code
distinguishes QProcess base class from derivatives.

In this case, qobject_cast is not appropriate and it seems like comapring
className() is a way to go.

-- 
Regards,
Konstantin

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

Re: [Development] Applications using -fno-rtti

[Konstantin Tokarev]

20.06.2020, 21:34, "Alberto Mardegan" :
> Hi all!
>   A couple of days ago a bug was filed against a project of mine, which
> has been built with -fno-rtti since Qt4 times:
>
>   https://bugzilla.opensuse.org/show_bug.cgi?id=1172904
>
> The bug, it appears, is a crash in QProcess due to the use of typeid(),
> which was introduced in Qt 5.15:
>
> https://code.qt.io/cgit/qt/qtbase.git/commit/?h=5.15=97645478de3ceffce11f58eab140c4c775e48be5
>
> I think I missed an announcement about Qt applications having to use
> RTTI; on the opposite, I thought that the whole point of QMetaObject was
> not to require RTTI support; has this changed?
>
> Anyway, were I to submit a patch replacing typeid() with something which
> does not require RTTI ("q->metaObject() == QProcess::staticMetaObject()"
> would work, I guess? Or maybe even comparing q->className()?), would
> that be accepted?

I think it should use qobject_cast.

Comparing metaObject() with staticMetaObject() is wrong because it would fail
even for QProcess. OTOH, using qobject_cast would handle classes derived
from QProcess correctly, unlike code with typeid().


-- 
Regards,
Konstantin

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

Re: [Development] Patching QtWebView to use QtWebkit "rebooted"?

[Konstantin Tokarev]

11.06.2020, 20:19, "René J.V. Bertin" :
> On Thursday June 11 2020 12:43:11 Konstantin Tokarev wrote:
>
>> Main reason behind QtWebView is described in the root page of its 
>> documentation, and it's about mobile platforms, namely Android, iOS, and 
>> also WinRT.
>
> For me everything QQuick* is (mostly) about mobile platforms, but that's a 
> different topic :)
>
>> all powerful features of QtWebKit's WebView are located in 
>> WebView.experimental.
>
> Which doesn't get documented by the `qch_docs` build target, correct?

Correct, but Qt Creator gladly autocompletes those properties, also there is 
info in the net.

>
>>  Out of curiosity, what do you want to add there?
>
> QtWebView has a method to run javascript code, and the signals aren't the 
> same. It might be useful if QtWebKit's WebView class were a drop-in 
> replacement for the one from QtWebView, so you can use the one or the other 
> by just changing the import statement.

Makes sense.

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

Re: [Development] Patching QtWebView to use QtWebkit "rebooted"?

[Konstantin Tokarev]

11.06.2020, 11:11, "René J.V. Bertin" :
> On Thursday June 11 2020 04:31:59 Konstantin Tokarev wrote:
>
>> Whole point of QtWebView is to use platform specific backends on platforms 
>> where they do exist, at the cost of limited API. If you need to use 
>> platform-specific backends and want to replace QtWebEngine on platforms with 
>> no "native" browser component, it might make sense.
>
> I couldn't yet find a description of the reason(s) behind QtWebView, but 
> given the similarity between the WebView classes from it and from QtWebkit 
> you'd almost think that QtWebView was written as a replacement that uses 
> QtWebEngine as a backend unless it shouldn't (and that seems to be only on 
> Mac).

Main reason behind QtWebView is described in the root page of its 
documentation, and it's about mobile platforms, namely Android, iOS, and also 
WinRT.

There is similarity between QtWebView's and QtWebKit's WebView QML types, 
however it happens because all powerful features of QtWebKit's WebView are 
located in WebView.experimental. Note that QtWebEngine provides WebEngineView 
type which is also quite similar.


>
> There's no such thing as a native browser component on Linux. Maybe if you 
> look at the DE level that GNOME has such a thing ... and using that would 
> probably mean reopening a discussion we had before (about webkit2-gtk) ;)
>
> Is possible in QML to "proxy" QtWebkit's WebView class, adding just the few 
> missing things to it, without taking a significant performance hit?

It's possible to extend any QML item in QML, or inherit from underlying C++ 
class and register it as a new QML type. Out of curiosity, what do you want to 
add there?
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Patching QtWebView to use QtWebkit "rebooted"?

[Konstantin Tokarev]

11.06.2020, 01:10, "René J.V. Bertin" :
> Hi,
>
> Suppose I wanted to patch QtWebView so it will use WebKit2 from the rebooted 
> QtWebKit libraries instead of the QtWebEngine bloatware, how feasible would 
> that be? A rabbithole, a question of reparenting and changing a limited 
> number of function calls, or pointless because QtWebKit already has a 
> QQuickWebView class?

Whole point of QtWebView is to use platform specific backends on platforms 
where they do exist, at the cost of limited API. If you need to use 
platform-specific backends and want to replace QtWebEngine on platforms with no 
"native" browser component, it might make sense.
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Using dwz on Qt

[Konstantin Tokarev]

14.05.2020, 13:34, "Allan Sandfeld Jensen" :
> Hi Qt
>
> I recently discovered there is a binutils tools for size optimizing dwarf
> debug symbols, and it really works. When applied to Qt debug symbol binaries
> it makes them about 25% smaller on average (some up to 40% smaller). And that
> is just the simple optimization. We can save more by combining duplicates from
> multiple debug symbol binaries into one shared one, but that would change the
> files we ship.

FWIW, I've already reported it at https://bugreports.qt.io/browse/QTBUG-82681

>
> In any case. While too late for 5.15 and written for qmake so not suitable for
> qt6, I would like to share my minimal change with you here, in case anybody
> would like to ship smaller debug binaries.
>
> Is there an existing cmake way to trigger the same? Though we might also want
> to consider triggering compressed dwarf symbols at the same time, as that is
> another great reduction, but ups the minimum tool versions required.

FWIW, I'm using this code for separating and compressing debug info:
https://github.com/qtwebkit/qtwebkit/blob/qtwebkit-dev-wip/Source/cmake/OptionsQt.cmake#L152-L167
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] A modest proposal: disable lower-case keywords (emit, foreach, forever, signals, slots) by default

[Konstantin Tokarev]

14.04.2020, 22:18, "Ville Voutilainen" :
> On Tue, 14 Apr 2020 at 12:31, Lars Knoll  wrote:
>>  What kind of argument is that? htons as a macro was worth considering, but 
>> the ones in Qt are not?
>>
>>  Fixing the htons macro also "only requires changing one place" in the 
>> System C library. You are forgetting, that both changes break a huge amount 
>> of user code out there. And Qt’s macros have been around for about just as 
>> long (25 years), so they also *long* precede the existence of ISO WG21.
>
> Well, there are multiple C libraries. So it was never just one place
> for that particular problem.

I think there are other issues with htons and similar functions:

1) on Unix-like systems C library is integral component of OS which cannot be 
easily updated to
newer version, and while it may be possible to use different libc to build user 
application it means
that those application will not be able to use any libraries shipped with OS 
without risk of conflict;

2) there is no standard way to have inline functions in C without requiring 
C99, while inlining these
particular functions may be crucial for performance of network-related 
applications.

>
> However, we should recognize that "could have been as easily fixed on any
> day of the past 20+ years" applies 100% as well to those macros.
> ___
> 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] Can QImage format plugins require QGuiApplication?

[Konstantin Tokarev]

14.04.2020, 02:27, "Giuseppe D'Angelo via Development" 
:
> Il 13/04/20 18:50, Kevin Kofler ha scritto:
>>  Today, a user on #fedora-kde ran across a crash which resulted from:
>>  * a GTK+/GNOME application (Jami) using (for some reason) QImage to load
>> images, without a QGuiApplication or QApplication constructed, vs.
>>  * a QImage format plugin (QtPBFImagePlugin) using font APIs that require
>> QGuiApplication and abort otherwise.
>>
>>  Obviously, one or the other must be wrong. So, who is to blame?
>
> The golden rule is that you're not allowed to touch any Qt API without
> creating a Q*Application object first, unless the documentation says
> otherwise.

Question is whether Q_Core_Application should be sufficient for using and image 
format plugin,
or QGuiApplication/QApplication is required.

-- 
Regards,
Konstantin

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

[Development] Coin: default build instructions in yaml format

[Konstantin Tokarev]

Hello,

Do "classic" qmake-based build instructions of Qt modules exist in a format
suitable for module_config.yaml?

If no, is it possible to write module_config.yaml which would "inherit"
default build but specify custom "accept_configuration:" block?

-- 
Regards,
Konstantin

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

Re: [Development] GitHub Pull requests

[Konstantin Tokarev]

15.03.2020, 05:30, "Thiago Macieira" :
> On Saturday, 14 March 2020 09:11:39 EST Konstantin Tokarev wrote:
>>  My feeling about the last item is quite opposite:
>>  * UI cuts long lines, when I wanted to check if specific compiler flag is
>>  actually in use, and of course it was beyond "..."
>>  * UI doesn't allow using built-in search of browser, and their search is
>>  really sluggish * Overall experience is quite sluggish, even in Chrome -
>>  looks like this thing wasn't meant to handle large logs efficiently.
>>  * When build finishes, and you need to check log of certain stage, UI forces
>>  you to scroll its content from very beginning, loading lines incrementally
>
> That's not different from reading source in GitHub. On my 4K 27" monitor in
> the office, the code occupies the central third of the screen, horizontally. I
> always have to scroll sideways (and unlike Qt-based applications, Chrome does
> not scroll horizontally when you hold Alt while using the mouse wheel). The
> raw form is useful in those cases.
>
>>  So, the only thing which really works is "raw log". It's approximately the
>>  same what Coin provides to external users. The only benefit is that with
>>  GitHub Actions you still can get an idea of overall progress of build,
>>  while in Coin you just have to wait with fingers crossed.
>
> https://testresults.qt.io/coin/

Results are uploaded there only after build finishes. Before that, build 
progress 
can only be seen on internal site.

-- 
Regards,
Konstantin

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

Re: [Development] GitHub Pull requests

[Konstantin Tokarev]

12.03.2020, 23:31, "Robert Löhning" :
> Hi,
>
> after having worked in a project in GitHub for a couple of months now
> and seeing their CI from the user perspective, this sounds feasible to me.
> ...
> - the progress and results are comprehensible, you can look at the CI
> run just like you look at your local console window, in real time

My feeling about the last item is quite opposite:
* UI cuts long lines, when I wanted to check if specific compiler flag is 
actually in
use, and of course it was beyond "..."
* UI doesn't allow using built-in search of browser, and their search is really 
sluggish
* Overall experience is quite sluggish, even in Chrome - looks like this thing 
wasn't
meant to handle large logs efficiently. 
* When build finishes, and you need to check log of certain stage, UI forces 
you to
scroll its content from very beginning, loading lines incrementally

So, the only thing which really works is "raw log". It's approximately the same 
what
Coin provides to external users. The only benefit is that with GitHub Actions 
you
still can get an idea of overall progress of build, while in Coin you just have 
to wait
with fingers crossed.

-- 
Regards,
Konstantin

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

Re: [Development] GitHub Pull requests

[Konstantin Tokarev]

13.03.2020, 08:55, "Thiago Macieira" :
> For a complex set of needs like Qt's, you'l still need a dedicated person or
> multiple people. And this isn't free either, despite there being a lot of free
> CIs for open source projects: first, because it's meant to serve the
> commercial version too and second because the free computing power is likely
> to be insufficient for Qt's needs. We'll need to purchase additional time or
> do Bring Your Own VM or Bring Your Own Container so we can test on more
> configurations than the CI provides, which means sysadmins are needed to keep
> those configurations running.

Also note that it's impossible to do performance testing in the cloud, using
self-hosted runners it is imperative for reproducibility of results.

-- 
Regards,
Konstantin

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

Re: [Development] GitHub Pull requests

[Konstantin Tokarev]

11.03.2020, 15:18, "Oswald Buddenhagen" :
> On Tue, Mar 10, 2020 at 02:40:41PM +, Cristian Adam wrote:
>> What about Pull requests?
>
> before you continue reinventing the wheel, i recommend that you read the
> comments on QTPM-314 (yes, all of them).

"You can't view this issue

It may have been deleted or you don't have permission to view it. "

Sure.


-- 
Regards,
Konstantin

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

Re: [Development] GitHub Pull requests

[Konstantin Tokarev]

10.03.2020, 22:26, "Matthew Woehlke" :
> On 10/03/2020 12.19, Cristián Maureira-Fredes wrote:
>>  On 3/10/20 3:40 PM, Cristian Adam wrote:
>>>  What stops us from accepting the contributions via GitHub?
>>>
>>>  Is it:
>>>
>>>   1. The CLA
>>>   2. Qt Account
>>>
>>>  For the CLA one can simply add an instance of:
>>>
>>>  https://github.com/cla-assistant/cla-assistant
>>
>>  I think that's a good idea,
>>  in the past I was told that even a written consent accepting
>>  the CLA was enough (please correct me if I'm wrong),
>>  so if we can also include it on the Github
>>  mirror, that will allow us to get more contributions.
>>
>>  The only thing I wonder is CI,
>>  what do you think could be a good workflow?
>
> In an ideal world...
>
> - Alice opens a pull request on GitHub.
> - A bot sees the PR and opens a corresponding request on Gerrit.
> - Bob comments on the Gerrit request.
> - A bot sees Bob's comment and replicates it to the GitHub PR.
> - Alice replies (on GitHub) to Bob's comment.
> - A bot sees Alice's comment and replicates it to Gerrit.
>
> ...and so on.

Then Bob asks Alice to make a change in commit, and she has to make
push -f in her branch. After that, review comments on GitHub are smashed,
while remain perfectly readable in Gerrit, and Bob can see difference
between patch versions while Alice cannot.

>
> I'm not sure to what extent this is actually plausible, but it would
> seem to solve CI nicely, and would also mean that maintainers don't need
> to look in multiple places.
>
> Note that I believe nothing needs to be done to "merge" the GitHub PR;
> if the commits become reachable from the target branch, it should
> automatically get marked as "merged".
>
> --
> Matthew
> ___
> 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] GitHub Pull requests

[Konstantin Tokarev]

10.03.2020, 19:25, "Cristián Maureira-Fredes" :
> Hello,
>
> On 3/10/20 3:48 PM, Konstantin Tokarev wrote:
>>  I think, lowering barrier of entry at expense of reviewers' convenience 
>> should
>>  have its limits
>
> Totally agree,
> so we should plan to accept patches from platform and systems
> made for code development, like Github :)
>
> , otherwise we may end up accepting contributions from Twitter:)
>
> If Twitter becomes on a code development platform
> with pull-requests, reviews, and so on...sure :P

My point is that GitHub is inferior as a code review platform. Lowering entry 
barrier 
for drive-by contributors (who quite likely won't come back to maintain code 
they've
introduced), it reduces quality of life for reviewers.

-- 
Regards,
Konstantin

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

Re: [Development] GitHub Pull requests

[Konstantin Tokarev]

10.03.2020, 17:42, "Cristian Adam" :
> Hi,
>
> With the “GitHub issues” E-Mail thread we made sure the Issues are gone
>
> from the projects.
>
> What about Pull requests?
>
> For example qtbase has 7 pull requests.  Usually people point out that
>
> the Qt project uses a different collaboration method:
>
> https://wiki.qt.io/Qt_Contribution_Guidelines
>
> What stops us from accepting the contributions via GitHub?
>
> Is it:
>
> * The CLA
> * Qt Account
>
> For the CLA one can simply add an instance of:
>
> https://github.com/cla-assistant/cla-assistant
>
> And it’s only one click away.
>
> When I contributed to vcpkg, the process of signing the Microsoft
>
> CLA was like that, one click.
>
> Regarding Qt Account, maybe one can use the GitHub account to
>
> create a Qt Account via openid.
>
> With GitHub actions (or Azure Pipelines, like vcpkg) we can also validate
>
> the pull requests.
>
> We should encourage developers to contribute to Qt, not having to learn
>
> how to use gerrit, and using a workflow that they are familiar with, should
>
> be a plus.

I think, lowering barrier of entry at expense of reviewers' convenience should
have its limits, otherwise we may end up accepting contributions from Twitter :)

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

Re: [Development] Github issues

[Konstantin Tokarev]

06.03.2020, 17:07, "Alex Blasche" :
> I fixed all of them up.

What about setting issue template with warning in case situation repeats in 
future?
To do this you create ".github" repository inside organization, and add
ISSUE_TEMPLATE file there.

-- 
Regards,
Konstantin

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

Re: [Development] Github issues

[Konstantin Tokarev]

06.03.2020, 14:04, "Alex Blasche" :
>> Thanks for the heads up. Whoever is maintaining those repos (?) need to turn 
>> off issues: 
>> >https://help.github.com/en/github/managing-your-work-on-github/disabling-issues
>
> I wish this could be done via the parent organization. But there doesn't seem 
> to be an option for it. Sigh, I guess I have to walk each repo.

At least it's possible to create global issue template with an appropriate 
warning.
Setting up many repositories can probably be automated via API.

-- 
Regards,
Konstantin

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

Re: [Development] A modest proposal: disable lower-case keywords (emit, foreach, forever, signals, slots) by default

[Konstantin Tokarev]

28.02.2020, 21:34, "Thiago Macieira" :
> On Friday, 28 February 2020 07:28:34 PST Matthew Woehlke wrote:
>>  If we had to do it over again, it might make sense to follow Python and
>>  make signals *objects* instead of *methods*. Then the code would look like:
>>
>>    this->emptied.emit(...);
>
> Binary compatibility issue: if it's a member of the class, it can't be added
> or removed without changing the class's size and layout, so it would tie our
> hands for future improvements.
>
> You'd see instead:
>
> this->emptied().emit(...);
> connect(foo, foo->emptied(), ...);

I think it could be a static member as well - there is no real reason for such 
member
to be per-instance in the first place.

-- 
Regards,
Konstantin

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

Re: [Development] A modest proposal: disable lower-case keywords (emit, foreach, forever, signals, slots) by default

[Konstantin Tokarev]

26.02.2020, 19:28, "Alex Blasche" :
>>  Am 26.02.20 um 13:42 schrieb Tor Arne Vestbø:
>>  > We don’t need one rule to rule them all either. Many signals are named
>>  fooChanged(), and can perfectly well stand on their own, without 
>> annotations.
>>  Corner cases like "emit pressed();” can be annotated with Q_EMIT or a 
>> comment
>>  to make it clearer what’s going on.
>
> Some end with "Changed". The overwhelming amount does not follow this rule 
> and we won't change the naming for Qt 6 either. The naming convention merely 
> states that there is a verb at the end.

For example, let's consider QAbstractButton::clicked() signal. There is no sense
in renaming it to anything ending with "Changed".

-- 
Regards,
Konstantin

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

Re: [Development] A modest proposal: disable lower-case keywords (emit, foreach, forever, signals, slots) by default

[Konstantin Tokarev]

26.02.2020, 16:34, "Simon Hausmann" :
> Am 26.02.20 um 13:42 schrieb Tor Arne Vestbø:
>>>  We’re neither enforcing the use of ‘emit’ currently. And I honestly find 
>>> most of the alternatives to be worse than no annotation at all.
>>  I agree.
>>
>>  As others have argued, a signal is not special, in the sense that any 
>> function can do anything, including emitting signals, so annotating it 
>> doesn’t seem critical, as we apparently are fine without in all other cases.
>>
>>  We don’t need one rule to rule them all either. Many signals are named 
>> fooChanged(), and can perfectly well stand on their own, without 
>> annotations. Corner cases like "emit pressed();” can be annotated with 
>> Q_EMIT or a comment to make it clearer what’s going on.
>
> This is also what tipped me over. We have stronger conventions nowadays
> with property based APIs and the Changed suffix for the corresponding
> signals. We'll be fine without "emit" :-)

FWIW, not all signals in world have corresponding properties.

-- 
Regards,
Konstantin

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

Re: [Development] Priority field in Jira

[Konstantin Tokarev]

Actually, priority field is not that useful. Anything except P0 and P1 can hang
indefinitely in unsolved state, and I agree that assigning P0 or P1 should be
restricted.

-- 
Regards,
Konstantin

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

Re: [Development] A modest proposal: disable lower-case keywords (emit, foreach, forever, signals, slots) by default

[Konstantin Tokarev]

24.02.2020, 18:19, "Allan Sandfeld Jensen" :
>
> Yeah you would need something like qEmit(_signal, Args..) or without &
> using a macro. Or.. qEmit(std::bind(_signal, Args...));

FWIW, using lambda expression is almost always a better solution that std::bind.

-- 
Regards,
Konstantin

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

Re: [Development] Commercial support for Coin and related infrastructure

[Konstantin Tokarev]

21.02.2020, 18:37, "Volker Hilsheimer" :
>>  On 20 Feb 2020, at 16:28, Konstantin Tokarev  wrote:
>>
>>  Hello,
>>
>>  Are there any options available for subject? I've tried to use official 
>> contacts page, but it forces use of corporate email, but my request has 
>> nothing to do with any commercial development.
>>
>>  --
>>  Regards,
>>  Konstantin
>
> There are no plans to make Coin or related infrastructure available as a 
> commercial service.
>
> But curious about the problem you think you would solve better with Coin than 
> with any other commercially or freely available alternative.

What I had in mind are mostly "quality of life" things for a person like me who 
doesn't have access to internal network of TQtC and thus have to nag people to 
do trivial things for me like look up if patch got stuck or it's still making 
progress after being integrating for last 8 hours, or look up why snapshot 
artifacts were not uploaded to public server.

Another issue which bothered me is 
https://bugreports.qt.io/browse/COIN-421?focusedCommentId=489603=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-489603
 - as it was ignored I believed that it wasn't something needed for Qt Company, 
however it would help me a lot.

I was also looking for "multi product builds" feature (COIN-199) to be finally 
delivered.

However, after recent announcement about Qt Creator moving to GitHub Action all 
of that seems worthless, as Coin presumably fails "doogfooding" inside The Qt 
Company.


-- 
Regards,
Konstantin

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

Re: [Development] Gerrit comment "Continuous Integration: Running"

[Konstantin Tokarev]

23.02.2020, 23:42, "Liang Qi" :
> Please help to create ticket for Project:Coin(COIN) in jira, thanks.

https://bugreports.qt.io/browse/COIN-514

-- 
Regards,
Konstantin

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

[Development] Gerrit comment "Continuous Integration: Running"

[Konstantin Tokarev]

Weird thing is happening with Coin or Gerrit - all integrating changes got 
"Continuous Integration: Running"
comment. Restaging leads to "Continuous Integration: Running" posted again to 
gerrit with state changed
back to Active.

Affected changes:
https://codereview.qt-project.org/c/qt/qtwebkit/+/289122
https://codereview.qt-project.org/c/qt/qtwebengine/+/290492
https://codereview.qt-project.org/c/qt/qtwebengine/+/291481
https://codereview.qt-project.org/c/qt/qtwebengine/+/283463

-- 
Regards,
Konstantin


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

Re: [Development] A modest proposal: disable lower-case keywords (emit, foreach, forever, signals, slots) by default

[Konstantin Tokarev]

21.02.2020, 16:18, "Ville Voutilainen" :
> On Fri, 21 Feb 2020 at 14:58, Sérgio Martins  wrote:
>>  > Why do I need to know that it's a signal being emitted? How is that
>>  > "vital information"? I could just as well
>>  > invoke any other callback, but I find myself not exactly yearning for
>>  > being able to write
>>  > callback somethingHappened();
>>
>>  Signals have different semantics than regular functions.
>
> In what way?
>
>>  If I'm reading the body of makePlane() I can ignore the signal
>>  emissions, as they aren't important for how a plane is made, they just
>>  inform whoever is listening.
>
> That doesn't seem to be correct in general. Some signals absolutely
> must be emitted
> for clients to work correctly.
>
>>  And I'd argue that the emitter shouldn't even know who or how many slots
>>  are connected to the signal, might even be zero, it shouldn't matter.
>
> ..and? What does that have to do with whether you do or do you emit?

E.g. it's possible to check if there are any listeners on the signal, and make
a shortcut in code if there aren't any. I've seen such code somewhere in 
qtwidgets

-- 
Regards,
Konstantin

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

[Development] Commercial support for Coin and related infrastructure

[Konstantin Tokarev]

Hello,

Are there any options available for subject? I've tried to use official 
contacts page, but it forces use of corporate email, but my request has nothing 
to do with any commercial development.

-- 
Regards,
Konstantin

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

Re: [Development] Co-maintainer of QtNetwork

[Konstantin Tokarev]

20.02.2020, 08:48, "Timur Pocheptsov" :
> Hi all,
>
> I want to propose a colleague of mine, Mårten Nordheim, as a co-maintainer of 
> QtNetwork module with him
> becoming the maintainer of  „High-Level network access (HTTP)"* (which 
> essentially means QNetworkAccessManager
> and related classes/code, sub-module 'access' etc.)  component and me 
> continuing as the maintainer of  "Low-level
> access (Sockets, SSL, Hostname resolution, Bearer mgmt, etc)"**. Since the 
> first day he joined the Qt Core
> and Network team several years ago, Mårten is making a significant 
> contribution to the QtNetwork module, which
> includes numerous improvements and fixes in QNetworkAccessManager and also 
> new developments (among other things
> he is the author of SChannel TLS backend on Windows). He has a good, solid 
> knowledge of QtNetwork code/components
> and making him the maintainer "de jure" will help us (the Qt Core and Network 
> team) to optimise and streamline the
> future developments in QtNetwork module.
>
> Best regards,
>    Timur.
>
> * and ** - these are names taken from our wiki page on the Qt maintainers.

+1


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

[Development] Patch workflow in qt5 supermodule (provisioning)

[Konstantin Tokarev]

Hello,

In the light of recent changes, should provisioning patches be merged to dev 
first now and then cherry-picked, or previous workflow remains?

-- 
Regards,
Konstantin

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

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

[Konstantin Tokarev]

12.02.2020, 12:36, "Vitaly Fanaskov" :
>>  You seem to repeat your initial statements.
>
> Yes, because most of the participants of this discussion tend to agree,
> as far as I can see.

AFAIK, we don't have a procedure to make project-level decisions by majority 
vote.

If we want to achieve anything more constructive than just summarizing 
opinions, these
ways are possible:
1) discuss Daniel's patch in Gerrit and get it approved or rejected;
2) someone could come up with another proposal in of form of (possibly WIP) 
patch
and get it formally reviewed in the same way;
3) someone could come up with a text of QUIP and get it formally reviewed

-- 
Regards,
Konstantin

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

Re: [Development] Changes to Qt offering

[Konstantin Tokarev]

28.01.2020, 19:57, "Matthew Woehlke" :
> On 28/01/2020 11.07, Alberto Mardegan wrote:
>>  But it will discourage contributions, and encourage competition from
>>  other Qt consulting companies
>
> At this point, I'm not sure that's a *bad* thing...

I'm pretty sure that "discourage contributions" part is surey bad thing.

With current process some contributors make efforts to ensure that their bug 
fixes are applied to all branches that are still open, even if it includes 
dealing with source conflicts. If LTS branches are not public, it might lead to 
degradation of their quality.

-- 
Regards,
Konstantin

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

Re: [Development] Changes to Qt offering

[Konstantin Tokarev]

27.01.2020, 21:30, "Tuukka Turunen" :
> Hi,
>
> I do not know why the link does not work. But I remember that post very well.
>
> On hindsight, it was too much of a rush back then to ask everyone to create a 
> Qt account immediately.
>
> As I wrote in my earlier reply, situation is different now:
>
> * Most users have already Qt account

FWIW, I've recently helped one Qt user on IRC who was refraining from 
submitting a bug report because they thought it was required to buy Qt license 
to obtain Qt account.

> * Marketplace needs it
> * More common to be connected
> If someone does not want to use Qt account, it is possible to build from 
> source.
>
> Yours,
>
> Tuukka


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

Re: [Development] Changes to Qt offering

[Konstantin Tokarev]

27.01.2020, 17:36, "Lars Knoll" :
> The second change is that a Qt Account will be in the future required for 
> binary packages. Source code will continue to be available as currently. This 
> will simplify distribution and integration with the Marketplace. In addition, 
> we want open source users to contribute to Qt or the Qt ecosystem. Doing so 
> is only possible with a valid Qt Account (Jira, code review and the forums 
> all require a Qt Account).

Will it be possible to download binaries bypassing QtIFW installer while having 
appropriate credentials? Right now, both online and offline installers are very 
inefficient to use in free CI systems like Travis CI, and many people including 
me are using scripts which download and unpack minimal set of 7z packages 
directly.

-- 
Regards,
Konstantin

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

Re: [Development] Moving math3d classes from GUI to CORE

[Konstantin Tokarev]

23.01.2020, 15:56, "Laszlo Agocs" :
> 4. Longer term, let's rather focus the energy on improving performance (via 
> SSE, NEON) in math3d, as that would probably bring more benefits to Qt Quick 
> and Quick 3D than spending effort on trying to get QtCore compete with 
> existing linear algebra solutions out there.

FWIW, "existing linear algebra solutions" like Eigen already implement SIMD 
support for many CPU architectures.

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

Re: [Development] QtCS19 Notes: Qt 6 Network Overview

[Konstantin Tokarev]

26.11.2019, 16:11, "Mårten Nordheim" :
> On 26.11.2019 13:54, Konstantin Tokarev wrote:
>>  What about an elephant in the room, i.e. HTTP/3? Will it be implemented 
>> anytime soon?
>
> Given the size and requirements of QUIC (and http3) we plan to wait for
> it to stabilize and get closer to release, then we can consider
> 3rd-party libraries to implement an internal (at least for QUIC v1 IMO)
> "QQuicSocket" of sorts (glorious name). Then HTTP/3 would be on-top of
> that or through a library as well.
> If we cannot find a suitable library we'll have to make one ourselves.
> So no plans for an implementation "soon", it will depend on the outside
> world. I would rather we be a little late to the game than have a flawed
> API for the lifetime of Qt 6 :)

Does last sentence imply that HTTP/3 will not be supported in QNAM transparently
and will use entirely new public API?

-- 
Regards,
Konstantin

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

Re: [Development] QtCS19 Notes: Qt 6 Network Overview

[Konstantin Tokarev]

What about an elephant in the room, i.e. HTTP/3? Will it be implemented anytime 
soon?

21.11.2019, 10:55, "Maurice Kalinowski" :
> Hi,
>
> Following the notes taken on the Networking session:
>
> - What to do in Networking for Qt 6
> ○ https://bugreports.qt.io/browse/QTBUG-75638 is the parent 
> item to track
> - Get rid of stale backend
> ○ OpenSSL 1.1 and following supported
> ○ SSL2/3
> - Additional TLS
> ○ mbedTLS contribution exists, will get it in but requires 
> work
> - QNetworkAccessmanager
> ○ Default policies
> - Removing bearer management
> ○ There has been complaints about it
> ○ Radio interfaces as bearer are not best option
> ○ Legacy from S60
> ○ Let's just get rid of it and move on
> ○ Webkit used bearer management to just identify whether 
> you're online or not
> ○ However, system services exist
> § We should have something similar in Qt
> § WIP: Connection Monitoring
> ○ Proposal:
> § Remove it
> § Add requested features afterwards
> □ Which socket is a connection using
> □ Set preferred connection
> - We want to avoid temporary buffers, especially in TLS case
> - QSSLsocket need to change
> ○ Going through tcp socket is complicated
> ○ Lots of effort, might be too big for Qt 6
> ○ Similar to QDTLS, which does not go through QUDPSocket
> - (Connection loss)
> ○ Problem not 100% clear
> ○ We have connection caching
> ○ Should not be exposed to user
> - Move WebSocket to QtNetwork?
> ○ Not sure why this is needed in network itself
> ○ Currently not actively maintained
> ○ Before moving to QtNetwork it needs to be significantly 
> refactored
> - Removing QFTP
> ○ This is about QFTP backend in QNetworkAccessManager
> ○ There are still public users, but how many?
> ○ Proposal: Disable it in 6.0 and check for amount of 
> complaints
> § If limited (as expected) remove in 6.2 completely
> - What about adding backends to QNetworkAccessManager?
> ○ Right now you can only exchange it
> ○ AP: Create research user story on JIRA
> ○ Help request
> - What about using libcurl as a backend?
> ○ Not only ftp, but everything?
> ○ It's not the best API, but provides a lot
> ○ We'd have to different underlying architectures, impossible 
> to use libcurl with our own stuff
> ○ Libcurl also has its own secure transport implementation, 
> etc…
> ○ Windows provides native API, what about that?
> § Mac probably as well
> - More and more projects need to do certificate management etc
> ○ KNX, OpcUA, CoAP, …
> ○ Can we find an abstraction? Potentially move that into a 
> separate module and have Qt Network use it?
> ○ QTBUG-76499, QTBUG-76876
> ○ It's a lot of work, but might be better than duplicating 
> less work again and again
> - QUIC / HTTP3
> ○ Rather wait for it to stabilize, but on the radar
> - QIODevice and zero copy
> ○ Needs to move to QtCS core session as no time left
> - How to test
> ○ Current testserver is probably not the best option
> ○ Use docker images
> ○ Windows is not ready for nested virtualization
> ○ However, might be worth considering run the network test 
> containers on one machine and then have the Windows VMs connect to this one.
>
> ___
> 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] QML 3 and JavaScript

[Konstantin Tokarev]

11.11.2019, 13:35, "Kevin Kofler" :
> Simon Hausmann wrote:
>>  Am 11.11.19 um 09:10 schrieb Dmitriy Purgin:
>>>  I understand that QML 2 is not going anywhere in Qt 6 but maintaining
>>>  both QML 2 and QML 3 will be a burden for the developers of the Qt
>>>  Framework, and I'm afraid QML 2 won't get much love after QML 3 is
>>>  released. Just as it happened to Widgets, it will be in the "done" state.
>>
>>  One thing we'd like to do differently is to allow good co-existence and
>>  mixing.
>
> So, whereas we C++ developers get to deal with all the deprecations and
> porting for Qt 6, QML developers can just stick to QML 2 forever and keep
> their code completely unchanged because you are going to maintain the entire
> old QML 2 for them??? How is that fair?

Suffering is unavoidable for C++ users, so a handful of deprecations doesn't 
add that much :)

-- 
Regards,
Konstantin

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

Re: [Development] Porting QT to new OS

[Konstantin Tokarev]

07.11.2019, 18:08, "drwho" :
> On 2019-11-07 12:42 a.m., Thiago Macieira wrote:
>>  On Wednesday, 6 November 2019 20:41:10 PST martin ribelotta wrote:
>>
>>>  4) What about the memory footprint?
>>  A couple of megabytes.
>
> I'd love to see a build how too that results in a couple of megabytes.
> The smallest I've ever got Qt with a "cut everything out" configure is...
>
>  text    data   bss hex filename
>
> 5199292   129564   11596   517d24 libQt5Core.so.5.6.2
>
> 3904283 81384   10616   3cfa7b  libQt5Gui.so.5.6.2
>
> 4893838   212704   840   4deeb6 libQt5Widgets.so.5.6.2

This is ELF section sizes, not a memory footprint. Actual memory footprint 
(RSS/PSS values) can be obtained from smaps file


-- 
Regards,
Konstantin

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

Re: [Development] When next Coin update can be expected?

[Konstantin Tokarev]

01.11.2019, 16:38, "Heikki Halmet" :
> Hi,
>
> We don't know the exact date yet. It depends when we get fixes for 
> https://bugreports.qt.io/browse/QTBUG-79623 or we need to make some kind of 
> workaround for the patches we have in master branch.
>
> If those patches are urgent then I think we can take those in as hotfixes if 
> production update keeps pending too long.

That would be nice, thanks!

>
> Br
> Heikki
>
> -Original Message-
> From: Development  On Behalf Of 
> Konstantin Tokarev
> Sent: perjantai 1. marraskuuta 2019 14.26
> To: development@qt-project.org
> Subject: Re: [Development] When next Coin update can be expected?
>
> 29.10.2019, 13:29, "Konstantin Tokarev" :
>>  In particular, I'm interested in fixes for COIN-412 and COIN-421
>
> Ping
>
> --
> Regards,
> Konstantin
>
> ___
> 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] When next Coin update can be expected?

[Konstantin Tokarev]

29.10.2019, 13:29, "Konstantin Tokarev" :
> In particular, I'm interested in fixes for COIN-412 and COIN-421

Ping

-- 
Regards,
Konstantin

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

[Development] When next Coin update can be expected?

[Konstantin Tokarev]

In particular, I'm interested in fixes for COIN-412 and COIN-421

-- 
Regards,
Konstantin

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

[Development] Provisioning error on Ubuntu 18.04 image

[Konstantin Tokarev]

Trying to provision Ubuntu 18.04 image with older commits of qt5 repo on 5.13.2 
branch (so that image is not just taken from cache) results in the following 
reproducible error:

+ sudo apt-get install docker-ce -y
Reading package lists...
Building dependency tree...
Reading state information...
Some packages could not be installed. This may mean that you have
requested an impossible situation or if you are using the unstable
distribution that some required packages have not yet been created
or been moved out of Incoming.
The following information may help to resolve the situation:

The following packages have unmet dependencies:
 docker-ce : Depends: containerd.io (>= 1.2.2-3) but it is not going to be 
installed
E: Unable to correct problems, you have held broken packages.


It seems like there were no recent docker-related changes in provisioning, so 
I'm afraid that it affects head of 5.13.2 as well (and maybe other branches), 
and will break things if cache of VM images is cleared

-- 
Regards,
Konstantin

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

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

[Konstantin Tokarev]

Following error had reproduced several times for me:

qwebglintegration_p.h:43:10: fatal error: 
QtFontDatabaseSupport/private/qwindowsfontdatabase_p.h: No such file or 
directory

Both MinGW and MSVC seem to be affected.
Example build logs:

https://testresults.qt.io/logs/qt/qtwebglplugin/87539f0467ac06174008e7eacaf2ba824b68351e/WindowsWindows_7x86WindowsWindows_7x86Mingw73qtci-windows-7-x86-3-b142bdDisableTests/58cdeff5cfc2360d3d8f7d496a8c2f08d3c92441/build_1571837037/log.txt.gz

https://testresults.qt.io/logs/qt/qtwebglplugin/87539f0467ac06174008e7eacaf2ba824b68351e/WindowsWindows_10x86_64WindowsWindows_10x86_64MSVC2015qtci-windows-10-x86_64-14-61643fDisableTests/e8e1bb3c60e19e1ce500d948d1bcf0d385710421/build_1571867849/log.txt.gz

-- 
Regards,
Konstantin

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

Re: [Development] The age-old T* foo vs. T *foo

[Konstantin Tokarev]

18.10.2019, 19:11, "Sérgio Martins" :
> On Thu, Oct 17, 2019 at 7:05 PM Ville Voutilainen
>  wrote:
>>  Since we are about to do a major version upgrade, should be stop being
>>  a special snowflake in the C++ world and start attaching pointer-stars
>>  and reference-ampersands to the type instead of to the variable?
>
> Make git move the star for you at checkout time (similarly to its CRLF 
> options).
> Git "just" needs C++ code model support.

No it doesn't, regular smudge/clean filters can do the work (e.g. by calling 
clang-format)

-- 
Regards,
Konstantin

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

Re: [Development] The age-old T* foo vs. T *foo

[Konstantin Tokarev]

17.10.2019, 21:06, "Ville Voutilainen" :
> As a quick example of how our current style is just odd, consider
>
> for (auto & : oink)
>
> Sure, that's in accordance with our style. It looks very out of place when
> coming back to our code after adventures in other code. Quick reading
> of it tends to suggest that it's a by-value thing since quick eyes see
> auto without any decorations.

I don't buy this. Space before '&&' may confuse simple tools like grep when
used naively, but definitely not a human reader.

-- 
Regards,
Konstantin

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

Re: [Development] Coming up: Coin production update

[Konstantin Tokarev]

16.10.2019, 13:42, "Aapo Keskimölö" :
> Hi Qt Developers,
>
> We are preparing for Coin production update to baseline version 1.2.0
> which will contain a major change that will force all builds to compile
> their test binaries during build phase by default - unless they are
> static builds because those test binaries would be too large to be saved.
>
> This will require clearing up the entire old storage and with its old
> artifacts, which means that there might be some delay due to dropping
> the Coin storage cache. As a benefit, however, this the feature allows
> us to save the compiled test binaries in storage and uploads them to a
> VM during test phase resulting in time savings for repeated/flaky test
> runs that would always re-compile test binaries. Now they will be reused.

Does it mean that test step won't attempt to build tests from sources anymore?
Could you give a link to example of changes which are needed to make caching
of test binaries working?

-- 
Regards,
Konstantin

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

Re: [Development] Change in open-source licensing of Qt Wayland Compositor, Qt Application Manager and Qt PDF

[Konstantin Tokarev]

11.10.2019, 04:09, "Kevin Kofler" :
> I wrote:
>>  Tuukka Turunen wrote:
>>>  Qt PDF is a new module, which has not been released earlier despite the
>>>  pre-release code being available. Changing the license to GPLv3 will
>>>  allow The Qt Company to support the module going forward.
>>
>>  But this license change makes the module effectively useless for the
>>  community because we already have a GPLv3-licensed implementation,
>>  Poppler-Qt. The more liberal license was the only added value of PDFium.
>
> PS: In addition, Qt PDF is de facto not a new module, but was added to the
> existing LGPL-licensed QtWebEngine module (because it uses the PDFium from
> QtWebEngine), so you will be shipping one tarball with differently licensed
> parts. This will be really confusing!

FWIW, that tarball already contains code under various licenses (BSD, LGPL 2.1, 
LGPL 3/GPL 2/Commercial, Apache 2.0, MIT, MPL 2, etc.)


-- 
Regards,
Konstantin

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

Re: [Development] Where to find development snapshots of Qt

[Konstantin Tokarev]

09.09.2019, 17:15, "Richard Weickelt" :
> Hello,
>
> I would like to build and test Qbs against development snapshots of Qt in 
> order to prevent disasters like https://bugreports.qt.io/browse/QBS-1492 from 
> happening again.
>
> Are there any snapshots of the Qt SDK available in some form? Something like 
> the 7z packages used by the installer tool would be perfect. I checked 
> download.qt.io and it looks like snapshots have been published at some point 
> in the past, but it is hard to see through there. QtCreator publishes daily 
> builds. I found https://wiki.qt.io/How_to_get_snapshot_via_online_installer 
> but does that apply to commercial customers only?

I guess that building Qbs in Coin is the only way to build against unreleased 
Qt versions.

-- 
Regards,
Konstantin

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

Re: [Development] Qt 6: inline namespace Qt

[Konstantin Tokarev]

06.09.2019, 20:28, "Thiago Macieira" :
> On Friday, 6 September 2019 09:04:09 PDT Giuseppe D'Angelo via Development
> wrote:
>>  I was actually proposing option A, to avoid clashes. The Qt:: namespace
>>  at the moment is simply too big to reasonably claim that there will be
>>  no conflicts. A few examples that come into mind: Qt::horizontal,
>>  Qt::vertical, Qt::[color name], Qt::SHIFT, Qt::Monday, Qt::XAxis.
>>
>>  Option C does not work, a namespace is either entirely inline or it's not.
>
> Option D: the inline namespace gets another name, something different from
> "Qt".
>
> Suggestion: Qt6

+1

I think this is the only sensible choice

-- 
Regards,
Konstantin

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

Re: [Development] Requiring minimum GCC 7/MinGW (was: Dropping MinGW support in Qt 6 (Was: HEADS-UP: QStringLiteral))

[Konstantin Tokarev]

23.08.2019, 21:11, "Thiago Macieira" :
> On Friday, 23 August 2019 09:04:55 PDT Konstantin Tokarev wrote:
>>  > libgcc on pure MinGW doesn't use winpthreads, it uses Win32.
>>
>>  std::thread and co are not implemented for win32, so we use pthreads version
>>  in Coin and distribute it with SDK.
>
> We don't use std::thread in Qt, so why are you telling us this?

I'm telling this to correct your misinformation about MinGW variant which we 
are using in CI.
However, from this moment I'm not going help you with such things and let your 
figure them out yourself.
-- 
Regards,
Konstantin


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

Re: [Development] Requiring minimum GCC 7/MinGW (was: Dropping MinGW support in Qt 6 (Was: HEADS-UP: QStringLiteral))

[Konstantin Tokarev]

23.08.2019, 18:11, "Thiago Macieira" :
> On Friday, 23 August 2019 00:12:50 PDT Roland Winklmeier wrote:
>>  Just for your awareness: There is an old bug related to thread_local in
>>  MinGW which afaik was never fixed. It compiles correctly, but every
>>  executable crashes during shutdown. Not sure if this relevant in this case,
>>  just mentioning it:
>>  https://github.com/msys2/MINGW-packages/issues/2519
>
> The description of the bug says "winpthreads", which means it's not MinGW,
> it's Cygwin/MSYS2.
>
> libgcc on pure MinGW doesn't use winpthreads, it uses Win32.

std::thread and co are not implemented for win32, so we use pthreads version
in Coin and distribute it with SDK.

>
> Anyway, let's apply Q_THREAD_LOCAL. If that causes GCC-built MinGW
> applications to crash on exit, then we stop using GCC and switch to Clang.
>
> --
> 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] HEADS-UP: QStringLiteral

[Konstantin Tokarev]

22.08.2019, 17:14, "Edward Welbourne" :
> Konstantin Tokarev (22 August 2019 15:48) wrote:
>>  At least we need a wiki page with optimization guidelines
>
> Would a page in our documentation suffice ?
> https://codereview.qt-project.org/c/qt/qtdoc/+/268079
>

Sure, though I've meant not only use of strings but other kinds of 
optimizations which
Marc is adding to Qt code base. Something like "Efficient Qt" but updated to the
current state of the art.

-- 
Regards,
Konstantin

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

Re: [Development] HEADS-UP: QStringLiteral

[Konstantin Tokarev]

22.08.2019, 16:44, "Martin Smith" :
> But Marc, your last paragraph calls for separating the API and implementation 
> discussions, but the paragraph just before it argues that the API to work 
> around our slowness is vital.
>
> If Qt developers must not forget Q_DECLARE_TYPEINFO, why isn't it important 
> for users?
>
> Should we have a pre-Qt 6 optimization period, where you first write up an 
> exhaustive list of all the implementation optimizations that should be used 
> in all Qt library code, and then we take the time to ensure that every class 
> uses them?
>
> I'm still not seeing why these same optimizations shouldn't be important to 
> describe in the Qt documentation for users. Users look at the Qt source code, 
> so when they see Q_DECLARE_TYPEINFO, they should be able to find out what it 
> does.

At least we need a wiki page with optimization guidelines

-- 
Regards,
Konstantin

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

Re: [Development] HEADS-UP: QStringLiteral

[Konstantin Tokarev]

22.08.2019, 02:39, "Kevin Kofler" :
> André Pönitz wrote:
>>  Traditionally, "ease of use" and "consistent API" have been a core values
>>  of Qt, even consciously bought at the cost of some bytes and some cycles.
>>
>>  Of course, this has meant that in certain parts of certain types of
>>  applications Qt could not sensibly be used. Still, in most cases all, or
>>  almost all of the code could be "plain Qt", benefiting for creation and
>>  maintenance from those values. I do believe this was a sensible setup for
>>  Qt, and I do think there's room for a general purpose framework living
>>  that compromise also in today's world.
>>
>>  During the last years (ok, let's say, starting around \epsilon A.J. -
>>  "After Jasmin") this promise has been more or less silently broken, once
>>  by "leaf" modules deviating, partially intentionally, from previous naming
>>  conventions, then for real accidents that couldn't be corrected due to
>>  too-late discovery and compatibility promises, and finally by attempts to
>>  provide "high performance" alternatives in some places.
>>
>>  In the end we lost uniform, easy-to-use interfaces, and the performance
>>  gains are only present in very isolated areas of the offering with long
>>  stretches in-between, hidden by obscure and continuously changing do's and
>>  don'ts so that they are effectively not visible in real-world GUI-centric
>>  applications.
>
> The creeping STLization of Qt (deprecating some classes for STL
> alternatives, using STL classes in some APIs, etc.) is also part of this
> disturbing trend. It typically regresses both ease of use and API
> consistency in the name of the holy performance cow.

If you don't need performance, don't use C++. For example, consider Qt for 
Python.

-- 
Regards,
Konstantin

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

Re: [Development] Dropping MinGW support in Qt 6 (Was: HEADS-UP: QStringLiteral)

[Konstantin Tokarev]

21.08.2019, 22:39, "Henry Skoglund" :
> Yes, I also used app-local deployment, problem is that Microsoft has not
> committed 100% to allow it (as far as I know), instead they have a
> seesaw approach, saying "you can temporarily use app-local deployment but.."
>
> Anyway, my ultimate goal is to create and distribute my Qt apps the same
> way as Qt's installation program (you can tell I really admire that
> program a lot :-)
> i.e. link *everything* statically and build myself a ~ 20 MB humongous
> .exe file (which only needs msvcrt.dll). And that kind of linking,
> Microsoft has never supported nor allowed it.

Does it mean that distribution of software built with /MT runtime is illegal?

-- 
Regards,
Konstantin

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

Re: [Development] Dropping MinGW support in Qt 6 (Was: HEADS-UP: QStringLiteral)

[Konstantin Tokarev]

21.08.2019, 22:56, "Thiago Macieira" :
> On Wednesday, 21 August 2019 12:29:29 PDT Massimo Callegari via Development
> wrote:
>>  Instead, please consider switching to MSYS2 for Qt6
>
> MSYS2 is Cygwin-like. It tries to emulate a Unix on Windows. It's great for
> porting Unix software to Windows and I love that it gives me a bash and pacman
> for when I need to develop on Windows. But it's emulation, like:
> https://github.com/Alexpux/Cygwin/blob/master/winsup/cygwin/fork.cc
>
> Native Windows software, which Qt on Windows is, shouldn't use that. MinGW is
> supposed to be *actual* Windows.

MSYS2 provides repositories with native toolchains (i.e., MinGW) and libraries 
as well.

-- 
Regards,
Konstantin

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

Re: [Development] HEADS-UP: QStringLiteral

[Konstantin Tokarev]

21.08.2019, 19:02, "Thiago Macieira" :
> On Wednesday, 21 August 2019 08:23:27 PDT Konstantin Tokarev wrote:
>>  I hope that standard committee will never introduce implicit generation of
>>  UTF16 literals from C string literals.
>
> You're over 10 years too late. That's exactly what u"" does.
>

That's explicit request, not implicit.

-- 
Regards,
Konstantin

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

Re: [Development] HEADS-UP: QStringLiteral

[Konstantin Tokarev]

21.08.2019, 18:29, "Tor Arne Vestbø" :
>>  On 21 Aug 2019, at 17:24, Konstantin Tokarev  wrote:
>>
>>  21.08.2019, 18:22, "Tor Arne Vestbø" :
>>>>   On 21 Aug 2019, at 16:55, Thiago Macieira  
>>>> wrote:
>>>>
>>>>   On Wednesday, 21 August 2019 07:47:23 PDT Thiago Macieira wrote:
>>>>>   On Wednesday, 21 August 2019 03:01:29 PDT Tor Arne Vestbø wrote:
>>>>>>   This should just be test[“key”] = “value”. How do we get there?
>>>>>
>>>>>   Do you mean "make this the most optimal?" If so, then we don't get 
>>>>> there.
>>>>>   It's not possible.
>>>>
>>>>   Oh, the following is nearly the most optimal:
>>>>
>>>>   test[u"key"] = u"value”;
>>>
>>>  So that would be utf16, can’t we let test["key"] = “value” assume utf8, ie 
>>> u8”foo” without the explicitness?
>>
>>  Conversion of UTF8 to UTF16 costs more, and here we know that literal is 
>> ASCII-only.
>
> Sure, okey, I’m happy with “foo” being interpreted as ascii, u8”" as utf8 and 
> u”” as utf16, as long as I can use all of them in other Qt APIs that take a 
> stringish. Ideally with automatic make-it-a-qstring-literal using C++ 
> fanciness over QFooLiteral :)

I would prefer if Qt APIs didn't insist on using QString and could work with 
sane string encodings

-- 
Regards,
Konstantin

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

Re: [Development] HEADS-UP: QStringLiteral

[Konstantin Tokarev]

21.08.2019, 18:22, "Tor Arne Vestbø" :
>>  On 21 Aug 2019, at 16:55, Thiago Macieira  wrote:
>>
>>  On Wednesday, 21 August 2019 07:47:23 PDT Thiago Macieira wrote:
>>>  On Wednesday, 21 August 2019 03:01:29 PDT Tor Arne Vestbø wrote:
  This should just be test[“key”] = “value”. How do we get there?
>>>
>>>  Do you mean "make this the most optimal?" If so, then we don't get there.
>>>  It's not possible.
>>
>>  Oh, the following is nearly the most optimal:
>>
>>  test[u"key"] = u"value”;
>
> So that would be utf16, can’t we let test["key"] = “value” assume utf8, ie 
> u8”foo” without the explicitness?

Conversion of UTF8 to UTF16 costs more, and here we know that literal is 
ASCII-only.

-- 
Regards,
Konstantin

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

Re: [Development] HEADS-UP: QStringLiteral

[Konstantin Tokarev]

21.08.2019, 18:19, "Tor Arne Vestbø" :
>>  On 21 Aug 2019, at 16:47, Thiago Macieira  wrote:
>>
>>  On Wednesday, 21 August 2019 03:01:29 PDT Tor Arne Vestbø wrote:
>>>  This should just be test[“key”] = “value”. How do we get there?
>>
>>  Do you mean "make this the most optimal?" If so, then we don't get there. 
>> It's
>>  not possible.
>
> Optimal enough :) With a way to micro-optimise it using a more explicit API 
> i needed.
>
>>  We could do it for literals with some constexpr help in the QString
>
> That’s what I was hoping. We have QFooLiteral today to let the compiler do 
> the work up front, isn’t it possible with newer c++ standards to have that 
> happen automatically without an explicit QFooLiteral?

I hope that standard committee will never introduce implicit generation of 
UTF16 literals from C string literals.

-- 
Regards,
Konstantin

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

Re: [Development] Accelerating deprecation of MSVC 2017

[Konstantin Tokarev]

21.08.2019, 00:45, "Thiago Macieira" :
> I'd like to propose we announce now that it will not be supported for Qt 5.15.
>
> Even if 2019 still has code generation problems. 

Does it mean that you recommend using 2015 instead?

> We should assume that MS will
> fix them soon.
>
> --
> 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] Dev branch moving towards Qt 6

[Konstantin Tokarev]

16.08.2019, 18:25, "Thiago Macieira" :
> On Friday, 16 August 2019 03:26:09 PDT Lars Knoll wrote:
>>  To reflect that and help us all understand that the development focus is now
>>  towards Qt 6, I would like to propose that dev becomes the Qt 6 branch
>>  after we branched away 5.14 (and we merge wip/qt6 back into dev). We can
>>  then either create a 5.15 branch at the same time, or slightly later, once
>>  5.14 has stabilised a bit more (e.g. after the beta or RC).
>
> I don't mind either way what happens to dev. But if we do make it Qt 6, I
> recommend we create 5.15 off of 5.14 at 5.14's feature freeze time. We won't
> need it earlier.

+1

Also, what branch mode will 5.15 be in, from view point of QUIP 5? I assume it 
will
use same policy as dev until 5.15 feature freeze is announced.

-- 
Regards,
Konstantin

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

Re: [Development] Supported compilers for Qt 6

[Konstantin Tokarev]

14.08.2019, 23:53, "Allan Sandfeld Jensen" :
> On Tuesday, 13 August 2019 18:13:05 CEST Thiago Macieira wrote:
>>  On Tuesday, 13 August 2019 00:50:48 PDT Friedemann Kleint wrote:
>>  > Hi,
>>  >
>>  > > VC++ 2019
>>  >
>>  > Just for the record, this compiler still has a number of optimizer bugs,
>>  > see https://bugreports.qt.io/browse/QTQAINFRA-2875 .
>>
>>  Unfortunately, despite those, it's still the best available. MSVC 2017 has
>>  *serious* problems with static libraries (as in, crash on start) and MSVC
>>  2015 is too old.
>
> Note btw, that referring to the major year numbers of MSVC might be an
> obsolete way of thinking. MSVC 2017 started with only C++11 support but gained
> up to almost full C++17 in patches.

Also introducing bugs, causing regressions in valid code in its minor updates, 
e.g.
https://developercommunity.visualstudio.com/content/problem/343550/webkit-an-undefined-class-is-not-allowed-as-an-arg.html


> MSCV 2019 is new is so far mostly the
> same as MSVC 2017 ended up as, but it seems likely to also improve greatly in
> point releases.
>
> 'Allan
>
> ___
> 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 PDF as a new TP module for Qt 5.14

[Konstantin Tokarev]

12.08.2019, 21:01, "Thiago Macieira" :
> On Monday, 12 August 2019 08:24:05 PDT Konstantin Tokarev wrote:
>>  I guess bigger problem is that Poppler is GPL. PDFium is probably the only
>>  permissively licensed PDF engine.
>
> And? If Poppler is a superior alternative, then people can accept its GPL
> requirements or not display PDF.

s/not display PDF/use alternative solution like pdf.js/

fixed

-- 
Regards,
Konstantin

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

Re: [Development] Qt PDF as a new TP module for Qt 5.14

[Konstantin Tokarev]

12.08.2019, 18:25, "Konstantin Tokarev" :
> 12.08.2019, 18:19, "Thiago Macieira" :
>>  On Monday, 12 August 2019 05:35:06 PDT Kai Köhne wrote:
>>>   I suggest to promote Qt PDF to a Qt module. For Qt 5.14, it will be in 
>>> Tech
>>>   Preview state, and Shawn Rutledge is volunteering to be the maintainer.
>>>   Although still staying an independent library from the user's perspective,
>>>   it will be hosted and built in the qtwebengine.git repository. Initially
>>>   only the desktop platforms (Windows, Linux, macOS) would be supported.
>>>
>>>   Qt PDF is so far a Qt labs module [1]. It allows Qt applications to
>>>   render/view PDF's in QWidget based applications [2], and is built on top 
>>> of
>>>   PDFium. However, development has been stagnant, also because it is built 
>>> on
>>>   top of a rather old version of PDFium.
>>
>>  Has any analysis been done comparing the feature and platform support, and
>>  codebase size, for PDFium versus Poppler?
>>
>>  Or is the big problem that the library we need to use (poppler-qt) depend on
>>  Qt itself?
>
> I guess bigger problem is that Poppler is GPL. PDFium is probably the only
> permissively licensed PDF engine.

OTOH, original authors of code base from which Poppler was forked from provide
solution [1] which is available under both GPL and commercial license. Of course
this is not something that can be sold by The Qt Company, but still can be 
useful
for those who develop proprietary applications.

[1] http://www.glyphandcog.com/XpdfWidgetQt.html

-- 
Regards,
Konstantin

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

Re: [Development] Qt PDF as a new TP module for Qt 5.14

[Konstantin Tokarev]

12.08.2019, 18:25, "Konstantin Tokarev" :
> 12.08.2019, 18:19, "Thiago Macieira" :
>>  On Monday, 12 August 2019 05:35:06 PDT Kai Köhne wrote:
>>>   I suggest to promote Qt PDF to a Qt module. For Qt 5.14, it will be in 
>>> Tech
>>>   Preview state, and Shawn Rutledge is volunteering to be the maintainer.
>>>   Although still staying an independent library from the user's perspective,
>>>   it will be hosted and built in the qtwebengine.git repository. Initially
>>>   only the desktop platforms (Windows, Linux, macOS) would be supported.
>>>
>>>   Qt PDF is so far a Qt labs module [1]. It allows Qt applications to
>>>   render/view PDF's in QWidget based applications [2], and is built on top 
>>> of
>>>   PDFium. However, development has been stagnant, also because it is built 
>>> on
>>>   top of a rather old version of PDFium.
>>
>>  Has any analysis been done comparing the feature and platform support, and
>>  codebase size, for PDFium versus Poppler?
>>
>>  Or is the big problem that the library we need to use (poppler-qt) depend on
>>  Qt itself?
>
> I guess bigger problem is that Poppler is GPL. PDFium is probably the only
> permissively licensed PDF engine.

(not counting PDF.js)

-- 
Regards,
Konstantin

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

Re: [Development] Qt PDF as a new TP module for Qt 5.14

[Konstantin Tokarev]

12.08.2019, 18:19, "Thiago Macieira" :
> On Monday, 12 August 2019 05:35:06 PDT Kai Köhne wrote:
>>  I suggest to promote Qt PDF to a Qt module. For Qt 5.14, it will be in Tech
>>  Preview state, and Shawn Rutledge is volunteering to be the maintainer.
>>  Although still staying an independent library from the user's perspective,
>>  it will be hosted and built in the qtwebengine.git repository. Initially
>>  only the desktop platforms (Windows, Linux, macOS) would be supported.
>>
>>  Qt PDF is so far a Qt labs module [1]. It allows Qt applications to
>>  render/view PDF's in QWidget based applications [2], and is built on top of
>>  PDFium. However, development has been stagnant, also because it is built on
>>  top of a rather old version of PDFium.
>
> Has any analysis been done comparing the feature and platform support, and
> codebase size, for PDFium versus Poppler?
>
> Or is the big problem that the library we need to use (poppler-qt) depend on
> Qt itself?

I guess bigger problem is that Poppler is GPL. PDFium is probably the only
permissively licensed PDF engine.

-- 
Regards,
Konstantin

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

Re: [Development] atomic reference counting implementation

[Konstantin Tokarev]

07.08.2019, 21:02, "Mutz, Marc via Development" :
> Hi Philippe,
>
> This was discussed in
> https://codereview.qt-project.org/c/qt/qtbase/+/66118. See, in
> particular, Olivier's comment.
>
> TL;DR: ref() is documented to be ordered, so cannot be changed.
>
> Consequently, I didn't merge it even with Thiago's +2.
>
> To fix, we'd need to port all of the Qt classes away from the public
> classes (QSharedData, QAtomicInt) and implement ref-counting completely
> from scratch (well, copy QSharedData → QSharedDataV2, QAtomicInt →
> QAtomicIntV2, and do the change in V2). That, or we introduce silent
> breakages into user code by applying 66118, something our Chief Whip has
> just announced publicly should not happen:
>
> https://blog.qt.io/blog/2019/08/07/technical-vision-qt-6/
>>  If we must break compatibility, a compile-time error is preferable
>>  over a silent breakage at runtime (as those are much harder to detect).
>
> I think I'm on record saying such impl details as ref-counting for Qt
> implicitly shared classes should not be public API. This is a perfect
> example of why I believe that to be fundamentally true.

It would be even better if it was possible to choose type of reference counting,
e.g. via template parameter. In many cases atomic counters are not needed
and just reduce performance.

-- 
Regards,
Konstantin

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

Re: [Development] is it possible to increase the max. document size for the JSON parser?

[Konstantin Tokarev]

07.08.2019, 02:21, "Sérgio Martins via Development" 
:
> On 2019-08-06 22:49, Sérgio Martins via Development wrote:
>>  On 2019-08-06 13:48, René J. V. Bertin wrote:
>>>  Joerg Bornemann wrote:
>>>
  Unfortunately, this isn't possible at the moment.
  This issue is tracked in QTBUG-47629.
>>>
>>>  Thanks, I'll try the patch!
>>
>>  Can you also check how much memory is occupied by reading that 100 MB
>>  file ?
>>  My memory is hazy but I think it was several GBs.
>
> I looked at it again and the test-case was flawed, it was using unneeded
> QStrings and QString::toUtf8().
>
> By reading directly from the file heaptrack now reports only 300 MB
> peak.

That's what should be expected, as QJsonDocument uses binary serialization 
format
as its in-memory representation.

-- 
Regards,
Konstantin

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

Re: [Development] Maybe add some kind of accessible pipeline for QSettings serialization in Qt6?

[Konstantin Tokarev]

09.07.2019, 18:12, "NIkolai Marchenko" :
> We (at our company) realy, REALLY don't like qsettings for a multitude of 
> reasons but are forced to deal with it because the details of how UI types 
> are saved are hidden deep in the qt's implementation and are subject to any 
> kind of changes qt wants.
>
> What we would really like is to have functions for all of this that hide 
> implementation but do expose the inputs/outputs of how settings of Qt's 
> classes are saved and loaded so that we can feed those into a separate 
> settings class to be stored and managed externally.
>
> Can it be done with Qt6?

Do you mean https://doc.qt.io/qt-5/qsettings.html#registerFormat or something 
else?

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

Re: [Development] Oslo, we have a problem [char8_t]

[Konstantin Tokarev]

06.07.2019, 17:20, "Mutz, Marc via Development" :
> On 2019-07-06 14:50, Fabian Kosmale wrote:
> [...]
>>   See https://godbolt.org/z/e6OinY for how this would look for a
>>  trivial function.
>
> [...]
>
> Now also handle test(NULL) and extend to binary:
>
> test2([0, NULL, nullptr, "", u8""], [0, NULL, nullptr, "", u8""])
>
> This doesn't scale...

It can be argued that use of NULL in C++ code is more relict thing and should 
not be
supported. It's also much easier to migrate code base from NULL to nullptr - 
simple text
replacement is enough.


-- 
Regards,
Konstantin

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

Re: [Development] HTML5/CSS vs Qt QML and QtCreator / Assistant

[Konstantin Tokarev]

01.07.2019, 17:10, "Giuseppe D'Angelo" :
> Il 01/07/19 15:56, Konstantin Tokarev ha scritto:
>>  If we include assumption #4, we can just render document 
>> paragraph-by-paragraph, encode
>>  resulting images of paragraphs to PNG and send to UI process.
>
> All of this "cross platform" (possibly), "efficient" (on the spot PNG
> compression through local sockets is everything but efficient),
> "flicker-free" (I'll believe it when I see it).
>
> So, where's this magic code?
>
> (And all of this instead of adding 1px table borders and maybe other 2-3
> features to QTextDocument; and developing a layout engine in Qt Quick.
> Not to mention it makes for a great user story for Qt, "Yes, the QtHelp
> module requires Qt Quick. No don't worry, it doesn't use OpenGL, it uses
> the software rasterizer, but no, not directly! It spawns another process
> and pushes frames through a local socket")

I agree, this sounds ridiculous

-- 
Regards,
Konstantin

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

Re: [Development] HTML5/CSS vs Qt QML and QtCreator / Assistant

[Konstantin Tokarev]

01.07.2019, 13:30, "Ville Voutilainen" :
> On Sat, 29 Jun 2019 at 14:34, Konstantin Tokarev  wrote:
>>  29.06.2019, 14:27, "Konstantin Tokarev" :
>>  > 29.06.2019, 14:00, "Giuseppe D'Angelo" :
>>  >> Il 29/06/19 12:59, Konstantin Tokarev ha scritto:
>>  >>>> This makes the exercise an couple of orders of magnitude harder, not
>>  >>>> simpler. Which cross platform, efficient, flicker-free, (possibly
>>  >>>> supported out of the box by some Qt module) ways are available right 
>> now
>>  >>>> to have a QWidget host another process' raster content?
>>  >>> Push rendered frames through QLocalSocket :)
>>  >>
>>  >> *BUZZER* wrong answer: I asked for _efficient_. :-P
>>  >
>>  > For docs it may be efficient enough: we can render whole page and then 
>> scroll it
>>  > on client side
>>
>>  Or even better: split page into "tiles" (i.e. portions of page with height 
>> of viewport) and
>>  render long page as a sequnece of tiles. This would reduce time needed to 
>> show initial
>>  content.
>>
>>  (Idea borrowed from WebKit and simplified to extreme)
>
> That sounds curiously like "reimplement how Chromium renders web pages" to me.

Not exactly:

1. We don't have any updates, so all tiles are immutable
2. We don't need to support hardware acceleration for CSS animations, so we 
don't need
to create dedicated tiles for some of page elements
3. We can assume that page contents is properly flowed into column, so we don't 
need
to support tiling in horizontal direction, and tiling system is thus reduced to 
one-dimensional
array of immutable images
4. We also don't necessarily need to delay rendering of tiles until they are 
exposed (but this
may be a good additional feature)

If we include assumption #4, we can just render document 
paragraph-by-paragraph, encode
resulting images of paragraphs to PNG and send to UI process.


-- 
Regards,
Konstantin

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

Re: [Development] HTML5/CSS vs Qt QML and QtCreator / Assistant

[Konstantin Tokarev]

29.06.2019, 14:27, "Konstantin Tokarev" :
> 29.06.2019, 14:00, "Giuseppe D'Angelo" :
>>  Il 29/06/19 12:59, Konstantin Tokarev ha scritto:
>>>>   This makes the exercise an couple of orders of magnitude harder, not
>>>>   simpler. Which cross platform, efficient, flicker-free, (possibly
>>>>   supported out of the box by some Qt module) ways are available right now
>>>>   to have a QWidget host another process' raster content?
>>>   Push rendered frames through QLocalSocket :)
>>
>>  *BUZZER* wrong answer: I asked for _efficient_. :-P
>
> For docs it may be efficient enough: we can render whole page and then scroll 
> it
> on client side

Or even better: split page into "tiles" (i.e. portions of page with height of 
viewport) and
render long page as a sequnece of tiles. This would reduce time needed to show 
initial
content.

(Idea borrowed from WebKit and simplified to extreme)

-- 
Regards,
Konstantin

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

Re: [Development] HTML5/CSS vs Qt QML and QtCreator / Assistant

[Konstantin Tokarev]

29.06.2019, 14:00, "Giuseppe D'Angelo" :
> Il 29/06/19 12:59, Konstantin Tokarev ha scritto:
>>>  This makes the exercise an couple of orders of magnitude harder, not
>>>  simpler. Which cross platform, efficient, flicker-free, (possibly
>>>  supported out of the box by some Qt module) ways are available right now
>>>  to have a QWidget host another process' raster content?
>>  Push rendered frames through QLocalSocket :)
>
> *BUZZER* wrong answer: I asked for _efficient_. :-P

For docs it may be efficient enough: we can render whole page and then scroll it
on client side

-- 
Regards,
Konstantin

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

Re: [Development] HTML5/CSS vs Qt QML and QtCreator / Assistant

[Konstantin Tokarev]

29.06.2019, 13:52, "Giuseppe D'Angelo via Development" 
:
> Il 29/06/19 09:57, Cristian Adam ha scritto:
>>  We could have the help plugin using an external process, this way that 
>> process can
>>  use the software renderer by itself.
>
> This makes the exercise an couple of orders of magnitude harder, not
> simpler. Which cross platform, efficient, flicker-free, (possibly
> supported out of the box by some Qt module) ways are available right now
> to have a QWidget host another process' raster content?

Push rendered frames through QLocalSocket :)

-- 
Regards,
Konstantin

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

Re: [Development] HTML5/CSS vs Qt QML and QtCreator / Assistant

[Konstantin Tokarev]

28.06.2019, 14:29, "Jedrzej Nowacki" :
> On Friday, June 28, 2019 11:32:43 AM CEST Cristian Adam wrote:
>>  Hi,
>>
>>  Some of you might have been familiar with white papers such as Qt QML v
>>  HTML5 – a practical
>>  comparison>  %20QT4/WHITEPAPER_HTML5vQML.pdf>.
>
>>  Qt Creator already ships with QML support, why not transform the HTML
>>  offline documentation into QML?
>
>  Does it have to be HTML5/CSS?
>>  Having the documentation as QML will have no additional constrains for Qt
>>  Creator. No 76MiB Qt5WebEngineCore.dll file, no memory increase, no startup
>>  penalty.
>
>>  QML is supported on all platforms, right? Builds with MinGW on Windows, and
>>  so on.
>
>>  Cheers,
>>  Cristian.
>
> 10 points for thinking out of the box :-)
>
> It would solve a lot of problems like; scaling, integration, fonts, _embedding
> qml snippets_, binary size... It would leave us with security issues, we could
> restrict the content somehow (documentation viewer would need to be
> sandboxed). As I like the idea, some prototyping is needed :-)

What about external documentation? Right now people can use a lot of 3rd party
QCH docs, and obtain more by converting 3rd party HTML files. If you want to
render docs with QML, you need some kind of automatic converter between HTML
and QML.

-- 
Regards,
Konstantin

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

Re: [Development] Assistant WebKit/WebEngine support

[Konstantin Tokarev]

27.06.2019, 22:15, "André Pönitz" :
> On Thu, Jun 27, 2019 at 06:57:08AM +0200, Richard Weickelt wrote:
>>  Is it well known, how many QtCreator users are even using the integrated
>>  help functionality? How many Qt users are using QtAssistant and how many
>>  prefer the online documentation?
>
> The exact numbers are not known (to me), but the patterns as such are in
> principle. It is known that effectively the full range of possibilities
> starting from reading the doc comments in Qt sources up to online docs
> only are used in practice.
>
> And it is known that no matter what option is selected as "the only
> true one" some people will be left out.
>
>>  I stopped using the integrated help and QtAssisant at some point and now I
>>  am exclusively using the online documentation in my regular browser. I can't
>>  give an exact reason, but I can see a correlation of multiple things:
>>
>>  1) Fast internet access became available everywhere I worked and there
>> was no noticable delay anymore in page loading.
>>  2) I am reading so much in the browser anyway that I feel more
>> comfortable also reading the Qt docs in it.
>>  3) I am using my browser anyway while working with Qt because
>> I often search in the mailing list, forum, other docs, etc.
>>  4) Using a regular search engine leads to good-enough search results
>> and is very fast
>>  5) There was the point where Qt's online docs started to look better.
>> Cripser fonts, more whitespace, better code highlighting.
>>
>>  I guess no matter how hard you try and how much effort you put into it, I'll
>>  probably never use QtCreator's integrated help again.
>
> That's a valid usage pattern.
>
>>  I'd rather appreciate
>>  QtCreator to be slim and fast, both when using and building it. I think the
>>  time, energy should rather be spend in improving the documentation as a
>>  whole. I'd like to see more video tutorials about QtCreator best practices,
>>  for instance.
>
> I usuall run a mixture of online docs and reading the comments directly,
> except in the occasional off-line case where it is QTextBrowser and/or
> comments.
>
>>  And yes, I (and a lot of users) would appreciate if qdoc would output
>>  exactly the same nice html design as doc.qt.io.
>
> And as usual, beauty is in the eye of the beholder. E.g. I still dislike
> the current Qt Green, especially as text color. And unfortunately for me
> in that case the rate of change of design seems to have slowed down
> lately in that area;&}

Be my guest. With QtWebKit you can set user style sheet [1] to override
those properties that you don't like, e.g. change green color to something
else. And this does not even require enabling JS support for the page.

[1] 
https://qtwebkit.github.io/doc/qtwebkit/qwebsettings.html#setUserStyleSheetUrl

-- 
Regards,
Konstantin

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

Re: [Development] Moving to Gerrit 2.16.9

[Konstantin Tokarev]

27.06.2019, 18:12, "Thiago Macieira" :
> On Thursday, 27 June 2019 07:10:36 PDT Frederik Gladhorn wrote:
>>  The only real challenge was upgrading Bazel, since every Gerrit version
>>  seems to only compile with one exact Bazel version (roughly).
>
> Argument against home-cooked, not-widely-used build systems right here.

This argument is more about imprecise build instructions than that.

-- 
Regards,
Konstantin

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

Re: [Development] Assistant WebKit/WebEngine support

[Konstantin Tokarev]

26.06.2019, 02:57, "Bastiaan Veelo" :
> On 26/06/2019 00:15, Jean-Michaël Celerier wrote:
>> There's also Zeal which is a nice Qt-based documentation browser which 
>> covers much more than the current .qch offering: https://zealdocs.org/ & 
>> https://github.com/zealdocs/zeal
>>
>> I see it used more and more.
>>
>> Best,
>> Jean-Michaël
> That's QWebView based (WebKit) pre Qt 5.6. Back then Assistant was great as 
> well.

It uses QtWebKit 5.212, not ancient version from Qt 5.5

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

Re: [Development] Assistant WebKit/WebEngine support

[Konstantin Tokarev]

26.06.2019, 11:13, "Eike Ziller" :
> I agree with Thiago that this also requires WebKit to be updated with 
> security fixes. It will potentially show downloaded content from anywhere, 
> and it’s not nice if someone can offer a malicious qch, using known security 
> issues in WebKit. And with JavaScript etcetera the “attack area” is much 
> larger than actually necessary for browsing documentation.

Note that it's possible to disable JavaScript completely at run time, reducing 
attack surface.

> We also either need to be able to register a scheme handler for qthelp, or 
> use a local server for the help.
> Also, WebView can use the “platform” API, but on Linux there is none. So we 
> need an implementation on Linux based on one of the other options in any case.

As well as implementation for Windows.

-- 
Regards,
Konstantin

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

Re: [Development] Assistant WebKit/WebEngine support

[Konstantin Tokarev]

25.06.2019, 22:32, "Bastiaan Veelo" :
> On 21/05/2019 14:50, Konstantin Tokarev wrote:
>>  21.05.2019, 15:47, "Bastiaan Veelo" :
>>>  On 20/05/2019 19:02, Konstantin Tokarev wrote:
>>>>    [...] Current version of QtWebKit from 5.212 works on Windows,
>>>>    there are binaries at
>>>>
>>>>    http://download.qt.io/snapshots/ci/qtwebkit/5.212/latest/qtwebkit/
>>>  Extracted into qtbase and Assistant builds like a charm! However running
>>>  it gives
>>>
>>>  "The procedure entry point
>>>  ?staticMetaObject@QSslSocket@@2UQMetaObject@@B could not be located in
>>>  the dynamic link library D:\Qt\gerrit\qt5\qtbase\bin\Qt5WeKit.dll".
>>>
>>>  I have checked out the Qt dev branch from May 11, which I can imagine
>>>  could cause problems. Do you happen to know which Qt version those
>>>  QtWebKit binaries are known to work with?
>>  5.10
>
> I decided not to compile Qt myself any more, because I can't wait until
> the next day for it to finish each time. Therefore I have forked qttools
> and am compiling Assistant separately using a stock binary Qt
> distribution. For some reason though, 5.10 is completely absent from the
> installer. I'll have to let the WebKit approach rest for the time being.

You can use these binaries with Qt 5.12:

http://download.qt.io/snapshots/ci/qtwebkit/5.212/1560153112/qtwebkit/


-- 
Regards,
Konstantin

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

Re: [Development] Assistant WebKit/WebEngine support

[Konstantin Tokarev]

25.06.2019, 19:01, "Thiago Macieira" :
> On Tuesday, 25 June 2019 06:43:06 PDT Eike Ziller wrote:
>>  What is the state of QtWebKit(2)
>
> It hasn't been updated in years. Don't use it, since it's clearly not getting
> security updates.

New version is currently in development, and should be ready in time frame of
Qt 5.14 (at least functionality required for displaying help)

5.212 branch should be fine for use with local help files, e.g. you can take 
fresh\
from http://download.qt.io/snapshots/ci/qtwebkit/5.212/1560153112/

-- 
Regards,
Konstantin

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