Re: [Development] Future of QBS

[Konstantin Tokarev]

16.10.2017, 16:17, "Adam Treat" :
> You'll need a strongly normalizing language for that which does not
> allow general recursion. Something built on the simply typed lambda
> calculus, but with added syntactic sugar would do.

Maybe Prolog would do it too.

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

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

Re: [Development] Future of QBS

[Konstantin Tokarev]

16.10.2017, 16:08, "Ulf Hermann" :
>>  I have no real experience with Meson, but at least it has following 
>> advantages:
>>
>>  * Its language is typed(!), has native support for arrays(!), and 
>> functions/methods have
>>  first-class return values(!)
>>  * Its language has native support for properties, with syntax that really 
>> looks like
>>  properties in another languages
>>  * It is target-oriented from the start and is not so burdened by legacy 
>> ways of doing
>>  things wrong, which plague old CMake projects and confuse newcomers
>>  * It is written in scripting language, so it's easier to add (and possibly 
>> distribute) new
>>  functionality without getting it through upstream hands first.
>>
>>  That said, I totally dislike the idea of inventing restricted DSL language 
>> for build system
>>  instead of using general purpose language (like e.g. in QBS or Premake).
>
> You could also argue that build systems should not use turing complete 
> languages, so that other tools can get an idea of what they're doing without 
> exercising the halting problem. However, apparently Meson fails at that, like 
> so many others.

This problem is solved by having access to full "project" model from the same 
language. E.g. this is how I implemented Premake plugin for Qt Creator a while 
ago: added Lua code to traverse Premake's project structure, and run it with 
all of Premake from inside Creator's plugin, by linking liblua.

I think this is a good compromise. Alternative is using pure XML (e.g. ant) or 
JSON (e.g. gyp) to describe projects, which convenient for tools but 
inconvenient for humans.

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

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

Re: [Development] Future of QBS

[Konstantin Tokarev]

16.10.2017, 15:06, "Kevin Kofler" :
> Tobias Hunger wrote:
>>  I am still missing a comparison of qbs and *current* build system options.
>>  All I see is qbs vs. qmake and qbs vs. cmake 2.x. Neither qmake nor cmake
>>  is what qbs will be competing with by the time it is ready to be used in
>>  earnest.
>>
>>  So far we excluded most possible build systems on the grounds that they do
>>  not support the mixed host/target builds we do. That requirement is going
>>  away. So we have more options now. Just to name two: Bazel promises great
>>  scalability and reliability, meson claims to be simple and fast. Even
>>  CMake made a lot of progress since version 2.x.
>
> This is the first time I hear of Bazel, so it cannot be that popular. The
> fact that it is written in Java also makes it a poor fit for Qt, as it would
> make Qt depend on the huge Java stack to build.

That tool is made by Google and tailored for Google internal needs. As we've 
learned
with gyp, they don't mind to abandon their stuff next day when something more 
cool
and more tailored comes out.

>
> Meson is, as far as I can tell (I had already looked at it a couple times),
> mostly a CMake clone written in Python. I fail to see how it is conceptually
> any different from (let alone better than) CMake. It is mainly pushed by
> GNOME developers who are fed up of stone-age autotools, but apparently do
> not want to use the same thing KDE uses (CMake) just because KDE uses it.

I have no real experience with Meson, but at least it has following advantages:

* Its language is typed(!), has native support for arrays(!), and 
functions/methods have
first-class return values(!)
* Its language has native support for properties, with syntax that really looks 
like
properties in another languages
* It is target-oriented from the start and is not so burdened by legacy ways of 
doing
things wrong, which plague old CMake projects and confuse newcomers
* It is written in scripting language, so it's easier to add (and possibly 
distribute) new
functionality without getting it through upstream hands first.

That said, I totally dislike the idea of inventing restricted DSL language for 
build system
instead of using general purpose language (like e.g. in QBS or Premake).

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

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

Re: [Development] Future of QBS

[Konstantin Tokarev]

16.10.2017, 13:59, "Konstantin Tokarev" <annu...@yandex.ru>:
> 15.10.2017, 12:20, "Christian Gagneraud" <chg...@gmail.com>:
>>  On 14 October 2017 at 04:22, Jean-Michaël Celerier
>>  <jeanmichael.celer...@gmail.com> wrote:
>>>>   nobody is going to port Qt to CMake (if you disagree start a new thread)
>>>
>>>   https://plus.google.com/+AaronSeigo/posts/fWAM9cJggc8
>>
>>  I would resume this post as "I love CMake, CMake is the only way.
>>  You're all wrong."
>>  This post doesn't explain anything, doesn't gives any analysis, no
>>  comparison, no argument whatsoever, nothing.
>>
>>  How many people had the same reaction when clang started?
>>  Nowadays, clang is actually far superior to gcc, it brought tooling
>>  like we would never have dared to dream of .
>>
>>  Same goes with SVN vs git, now (almost) everyone have given up with SVN.
>>  SVN was "CVS in better", git is a completely different approach to
>>  SCM, SVN is now a zombie.
>>
>>  "Not reinventing the wheel" has to be balanced with "innovation".
>>
>>  IMHO, Qbs' great potential is the "completely new approach".
>
> It isn't new actually, there were many build systems with similar concepts 
> before
> Qbs existed, e.g. Tundra [1]. Problem is that such projects tend to be one-man
> shows and don't get wide adoption.
>
> [1] https://github.com/deplinenoise/tundra/blob/master/doc/manual.asciidoc

Going further: as far as I understand, "battle of build systems" is not at all 
about
who has better user experience or more sound design, it's about ability to push 
your
system to the market (agressive promotion and consulting services).

>
>>  Qbs would be a failed attempt if it was "CMake in better".
>>
>>  I think it's worth thinking about that, and be critical instead of
>>  being blind nay-sayer.
>>
>>>>   a complete CMake build for Qt was already contributed upstream (quite 
>>>> some
>>>>   time ago) .. and rejected ..
>>
>>  It would be interesting to know why. Oswald said "we (...) are
>>  strongly biased against a
>>  cmake-based solution", but didn't give any reason/justification (Or I
>>  missed it).
>>
>>  Did this CMake port cover all the features provided by qmake?
>>  Did this CMake port provide all the configuration needed by Qt, on all
>>  the supported platform?
>>  Could the Qt CI switch to CMake then?
>>
>>  And what about this "Nominating Kevin Funk for Maintainer qtbase/Build
>>  Systems/CMake" thread?
>>  Will Kevin Funk (aka. "The CMake guy" according to Sergio) be fair
>>  when it comes to evaluating new build systems for Qt? or is it an
>>  hijack attempt, an insider infiltration?
>>  Or is it pure timing coincidence, and Kevin Funk is actually a "build
>>  system*s* guy"?
>>
>>  I have no power of decision, so i will accept any.
>>
>>  Nonetheless, I think it would be a mistake to choose a build system
>>  over the other because "I love Xyz, Xyz is the only way. You're all
>>  wrong."
>>
>>  Who knows, maybe the answer to "Which new build system for Qt" could
>>  be neither CMake, neither Qbs.
>>
>>  My 2 cents,
>>  Chris
>>  ___
>>  Development mailing list
>>  Development@qt-project.org
>>  http://lists.qt-project.org/mailman/listinfo/development
>
> --
> Regards,
> Konstantin
> ___
> Development mailing list
> Development@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development

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

Re: [Development] Future of QBS

[Konstantin Tokarev]

15.10.2017, 12:20, "Christian Gagneraud" :
> On 14 October 2017 at 04:22, Jean-Michaël Celerier
>  wrote:
>>>  nobody is going to port Qt to CMake (if you disagree start a new thread)
>>
>>  https://plus.google.com/+AaronSeigo/posts/fWAM9cJggc8
>
> I would resume this post as "I love CMake, CMake is the only way.
> You're all wrong."
> This post doesn't explain anything, doesn't gives any analysis, no
> comparison, no argument whatsoever, nothing.
>
> How many people had the same reaction when clang started?
> Nowadays, clang is actually far superior to gcc, it brought tooling
> like we would never have dared to dream of .
>
> Same goes with SVN vs git, now (almost) everyone have given up with SVN.
> SVN was "CVS in better", git is a completely different approach to
> SCM, SVN is now a zombie.
>
> "Not reinventing the wheel" has to be balanced with "innovation".
>
> IMHO, Qbs' great potential is the "completely new approach".

It isn't new actually, there were many build systems with similar concepts 
before
Qbs existed, e.g. Tundra [1]. Problem is that such projects tend to be one-man 
shows and don't get wide adoption.

[1] https://github.com/deplinenoise/tundra/blob/master/doc/manual.asciidoc

> Qbs would be a failed attempt if it was "CMake in better".
>
> I think it's worth thinking about that, and be critical instead of
> being blind nay-sayer.
>
>>>  a complete CMake build for Qt was already contributed upstream (quite some
>>>  time ago) .. and rejected ..
>
> It would be interesting to know why. Oswald said "we (...) are
> strongly biased against a
> cmake-based solution", but didn't give any reason/justification (Or I
> missed it).
>
> Did this CMake port cover all the features provided by qmake?
> Did this CMake port provide all the configuration needed by Qt, on all
> the supported platform?
> Could the Qt CI switch to CMake then?
>
> And what about this "Nominating Kevin Funk for Maintainer qtbase/Build
> Systems/CMake" thread?
> Will Kevin Funk (aka. "The CMake guy" according to Sergio) be fair
> when it comes to evaluating new build systems for Qt? or is it an
> hijack attempt, an insider infiltration?
> Or is it pure timing coincidence, and Kevin Funk is actually a "build
> system*s* guy"?
>
> I have no power of decision, so i will accept any.
>
> Nonetheless, I think it would be a mistake to choose a build system
> over the other because "I love Xyz, Xyz is the only way. You're all
> wrong."
>
> Who knows, maybe the answer to "Which new build system for Qt" could
> be neither CMake, neither Qbs.
>
> My 2 cents,
> Chris
> ___
> Development mailing list
> Development@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development

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

Re: [Development] Future of QBS

[Konstantin Tokarev]

16.10.2017, 10:31, "Jake Petroules" :
>>  On Oct 16, 2017, at 4:42 AM, Kevin Kofler  wrote:
>>
>>  Christian Gagneraud wrote:
>>>  I would resume this post as "I love CMake, CMake is the only way.
>>>  You're all wrong."
>>>  This post doesn't explain anything, doesn't gives any analysis, no
>>>  comparison, no argument whatsoever, nothing.
>>
>>  It makes one important point (and elaborates it to great lengths): developer
>>  familiarity. Even if QBS were actually a lot better than CMake (something I
>>  am also very sceptical about), it would still be universally hated simply
>>  because it is not what developers (and distribution packagers!) know.
>>
>>  As a distribution packager, I am really fed up of some upstream projects
>>  reinventing their own custom build systems (qmake, gyp, gn, qbs, etc.) that
>>  don't work with our existing packaging boilerplate.
>
> Keep in mind - and this is VERY important - Qbs is NOT "the Qt build system". 
> It happens to be developed by the same people - that is all. We actually 
> encourage people to use it for non-Qt projects.

I'm afraid folks outside of Qt will continue to see it this way though, as it 
depends on Qt and uses QML syntax

And if you untie it from but make dependent on JSC, it won't help much, as it's 
a large library with other dependencies (except on macOS where it's built-in).

>
> There's actually a lot of design decisions that went into making Qbs better 
> in ways that are not even necessarily important for Qt itself right now, but 
> are important for ensuring that it's suitable for *any* project (and just in 
> general having a better foundation that Qt could also benefit from in the 
> future as well). As I said in my talk at World Summit, "Qbs should go beyond 
> Qt".
>
> I agree projects should not invent their own build systems. But Qbs is not 
> "Qt's" build system, it is a new product and when I said in my talk that it's 
> intended to compete with CMake, I didn't just mean "as a build system for Qt 
> or for Qt based projects". ;)
>
>>>  How many people had the same reaction when clang started?
>>>  Nowadays, clang is actually far superior to gcc, it brought tooling
>>>  like we would never have dared to dream of .
>>
>>  Yet, Fedora packages are still built using GCC and there are no plans to
>>  change that any time soon. The generated code is simply more efficient.
>>
>>>  Same goes with SVN vs git, now (almost) everyone have given up with SVN.
>>>  SVN was "CVS in better", git is a completely different approach to
>>>  SCM, SVN is now a zombie.
>>
>>  Yet, the git way to do things is not necessarily better. Revision IDs are
>>  not comparable without having the absolute history. Developers can commit
>>  their work locally without pushing it, encouraging intransparent
>>  development. And the learning curve is a lot steeper if you are not used to
>>  it yet.
>>
>>  That said, git nowadays has the exact same argument going for it as CMake:
>>  it is what everyone is now used to.
>>
>> Kevin Kofler
>>
>>  ___
>>  Development mailing list
>>  Development@qt-project.org
>>  http://lists.qt-project.org/mailman/listinfo/development
>
> --
> Jake Petroules - jake.petrou...@qt.io
> The Qt Company - Silicon Valley
> Qbs build tool evangelist - qbs.io
>
> ___
> Development mailing list
> Development@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development

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

Re: [Development] Future of QBS

[Konstantin Tokarev]

16.10.2017, 05:43, "Kevin Kofler" :
> Christian Gagneraud wrote:
>>  I would resume this post as "I love CMake, CMake is the only way.
>>  You're all wrong."
>>  This post doesn't explain anything, doesn't gives any analysis, no
>>  comparison, no argument whatsoever, nothing.
>
> It makes one important point (and elaborates it to great lengths): developer
> familiarity. Even if QBS were actually a lot better than CMake (something I
> am also very sceptical about), it would still be universally hated simply
> because it is not what developers (and distribution packagers!) know.
>
> As a distribution packager, I am really fed up of some upstream projects
> reinventing their own custom build systems (qmake, gyp, gn, qbs, etc.) that
> don't work with our existing packaging boilerplate.

FWIW, some major open project have migrated to Meson recently [1], so that
build system is becoming something that packagers *have to* know how to
deal with.

[1] https://en.wikipedia.org/wiki/Meson_%28software%29#Adopters

>
>>  How many people had the same reaction when clang started?
>>  Nowadays, clang is actually far superior to gcc, it brought tooling
>>  like we would never have dared to dream of .
>
> Yet, Fedora packages are still built using GCC and there are no plans to
> change that any time soon. The generated code is simply more efficient.
>
>>  Same goes with SVN vs git, now (almost) everyone have given up with SVN.
>>  SVN was "CVS in better", git is a completely different approach to
>>  SCM, SVN is now a zombie.
>
> Yet, the git way to do things is not necessarily better. Revision IDs are
> not comparable without having the absolute history. Developers can commit
> their work locally without pushing it, encouraging intransparent
> development. And the learning curve is a lot steeper if you are not used to
> it yet.
>
> That said, git nowadays has the exact same argument going for it as CMake:
> it is what everyone is now used to.
>
> Kevin Kofler
>
> ___
> Development mailing list
> Development@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development

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

Re: [Development] Nominating Kevin Funk for Maintainer qtbase/Build Systems/CMake

[Konstantin Tokarev]

13.10.2017, 23:37, "Thiago Macieira" :
> On Friday, 13 October 2017 12:30:59 PDT André Pönitz wrote:
>>  Hi all.
>>
>>  I would like to nominate Kevin Funk for Maintainer of the
>>  Build Systems/CMake area.
>>
>>  Kevin is effectively doing the job today.
>
> +1 from me

+1 from me too

>
> --
> Thiago Macieira - thiago.macieira (AT) intel.com
>   Software Architect - Intel Open Source Technology Center
>
> ___
> Development mailing list
> Development@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development

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

Re: [Development] Speeding up the review process (was: PostgreSQL cross compile for Pi)

[Konstantin Tokarev]

13.10.2017, 14:05, "Viktor Engelmann" :
> On the [Interest] mailing list there was a discussion about the 
> review-process taking to long and we also had multiple discussions about that 
> at the world summit. I have complained about this myself, so I would like to 
> start a new thread and collect your thoughts and ideas on how to improve the 
> situation.
>
> My suggestions would be
>
> * Allow approving your own commits under certain circumstances. examples:
>
> * when you only changed minor things like a variable name (except in public 
> API), a string, a comment or qdoc entry
> * when you already had a +2 and only changed minor things like a variable 
> name, a string, a comment or qdoc entry (or more generally: when you already 
> had a +2 and only did something that is also on this list :-D )

FWIW, in WebKit project it's a usual workflow to set "r+" and at the same time 
request minor changes to the patch, fixed version of patch is submitted without 
new review.

> * when you only increased a timeout in an autotest. Increasing timeouts is a 
> safe change - it can only solve false negatives and false positives, but not 
> create false positives or false negatives.
> * or more general: when you only made an autotest harder to pass - like 
> adding a Q_VERIFY, Q_COMPARE, etc.
> * when the change is something auto-generated - like you just updated 
> plugins.qmltypes using qmlplugindump
> * when you only changed something in accordance to the guidelines - like 
> Q_DECL_OVERRIDE -> override
> * when you have a certain count of +1's from people who have approver rights

Note that at least some of this rules can be implemented in gerrit itself, so 
you don't need self-approve

https://codereview.qt-project.org/Documentation/prolog-cookbook.html
https://codereview.qt-project.org/Documentation/prolog-change-facts.html

> * Towards that last point: I think many of us are afraid to get blamed for 
> +2'ing something that causes problems later (introduces a new bug or so), but 
> as far as I have seen, nobody gets blamed for such problems, so we should not 
> be THAT afraid of approving something. Also, don't forget that there is still 
> the CI to get past!
> * Remember that brain-cycles are far more expensive than CPU cycles - so when 
> in doubt, rather test-run something on the CI than make a human think about 
> whether the CI "would" accept it. If that causes CI outages, we need to buy 
> more CI machines. It is just a naive fallacy to "save" CI expenses by 
> assigning the CI's work to employees who are much more expensive.
> * I don't think we need to be as paranoid towards contributions from our own 
> employees as we need to be towards external contributions.

Hey, it's a discrimination!

> * Set a deadline for criticism on the general approach to a change. Too often 
> I have had the situation that I uploaded a patch, then we debated the qdoc 
> entries, variable names, method names, etc FOR MONTHS - and when I thought we 
> were finally wrapping up and I could soon submit it, someone else chimes in 
> and says "this should be done completely differently". Even if the person is 
> right - they should have said that months earlier - before I wasted all that 
> valuable time on variable names, compliance with qdoc guidelines, etc.
> In earlier discussions I have been told that such a deadline would have to be 
> long, because someone who might have an opinion might be on vacation. IMHO, 
> this doesn't count, because a) you can still make an exception to the rule in 
> such a situation and b) by that logic you should never approve anything, 
> because we also might hire a new employee in 10 years who might have an 
> opinion.
>
> -- Viktor Engelmann Software Engineer The Qt Company GmbH Rudower Chaussee 13 
> D-12489 Berlin viktor.engelm...@qt.io +49 151 26784521 http://qt.io 
> Geschäftsführer: Mika Pälsi, Juha Varelius, Mika Harjuaho Sitz der 
> Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 144331 
> B The Future is Written with Qt www.qtworldsummit.com
> ,
>
> ___
> Development mailing list
> Development@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development


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

Re: [Development] QtCS 2017 CoAP session notes

[Konstantin Tokarev]

10.10.2017, 13:10, "Thiago Macieira" <thiago.macie...@intel.com>:
> On Tuesday, 10 October 2017 11:59:07 CEST Konstantin Tokarev wrote:
>>  10.10.2017, 12:50, "Thiago Macieira" <thiago.macie...@intel.com>:
>>  > On Tuesday, 10 October 2017 11:48:02 CEST Konstantin Tokarev wrote:
>>  >> > We would like to have CBOR support in QtCore.
>>  >>
>>  >> If you do this, please support stringref extension:
>>  >> http://cbor.schmorp.de/stringref
>>  >
>>  > Point me to the IETF draft. No action before then.
>>
>>  At the moment, there are only 25 and 256 tags registered in
>>  https://www.iana.org/assignments/cbor-tags/cbor-tags.xhtml
>>
>>  However, I believe that without this extension CBOR with string keys isn't
>>  much better than JSON, as you still need to compress it on the wire.
>
> Sure, it isn't much better than JSON. Just a little, which is fine.
>
> If you want something much better, just use integer keys. That's what COSE is
> doing. See
> https://tools.ietf.org/html/rfc8152#section-3.1
>
> IANA registries:
> https://www.iana.org/assignments/cose/cose.xhtml

Hard-wired integers are not convenient for evolving production systems. If one 
of peers
screws up serialization or parsing, it's always nice to dump data and 
immediately see which
side got it wrong. See also my other reply about fixed-schema formats

>
> --
> Thiago Macieira - thiago.macieira (AT) intel.com
>   Software Architect - Intel Open Source Technology Center
>
> ___
> Development mailing list
> Development@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development

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

Re: [Development] QtCS 2017 CoAP session notes

[Konstantin Tokarev]

10.10.2017, 12:59, "Konstantin Tokarev" <annu...@yandex.ru>:
> 10.10.2017, 12:50, "Thiago Macieira" <thiago.macie...@intel.com>:
>>  On Tuesday, 10 October 2017 11:48:02 CEST Konstantin Tokarev wrote:
>>>   > We would like to have CBOR support in QtCore.
>>>
>>>   If you do this, please support stringref extension:
>>>   http://cbor.schmorp.de/stringref
>>
>>  Point me to the IETF draft. No action before then.
>
> At the moment, there are only 25 and 256 tags registered in
> https://www.iana.org/assignments/cbor-tags/cbor-tags.xhtml
>
> However, I believe that without this extension CBOR with string keys isn't 
> much better
> than JSON, as you still need to compress it on the wire.

And with integer keys, that you've mentioned, it's not really better than 
fixed-schema
formats, e.g. Cap'n'Proto or protobuf, which have other benefits like RPC 
extensions

>
>>  --
>>  Thiago Macieira - thiago.macieira (AT) intel.com
>>    Software Architect - Intel Open Source Technology Center
>>
>>  ___
>>  Development mailing list
>>  Development@qt-project.org
>>  http://lists.qt-project.org/mailman/listinfo/development
>
> --
> Regards,
> Konstantin
> ___
> Development mailing list
> Development@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development

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

Re: [Development] QtCS 2017 CoAP session notes

[Konstantin Tokarev]

10.10.2017, 12:50, "Thiago Macieira" <thiago.macie...@intel.com>:
> On Tuesday, 10 October 2017 11:48:02 CEST Konstantin Tokarev wrote:
>>  > We would like to have CBOR support in QtCore.
>>
>>  If you do this, please support stringref extension:
>>  http://cbor.schmorp.de/stringref
>
> Point me to the IETF draft. No action before then.

At the moment, there are only 25 and 256 tags registered in 
https://www.iana.org/assignments/cbor-tags/cbor-tags.xhtml

However, I believe that without this extension CBOR with string keys isn't much 
better
than JSON, as you still need to compress it on the wire.

>
> --
> Thiago Macieira - thiago.macieira (AT) intel.com
>   Software Architect - Intel Open Source Technology Center
>
> ___
> Development mailing list
> Development@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development

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

Re: [Development] QtCS 2017 CoAP session notes

[Konstantin Tokarev]

10.10.2017, 12:43, "Thiago Macieira" :
> == CoAP Client ==
>
> * Contribution consists of CoAP client
> ** Supports PUT/GET/POST/DELETE
> *** Not yet FETCH/PATCH (RFC 8132)
> ** Supports Blockwise transfer
> ** Supports Notification (QCoapReply::notified signal,
> QCoapClient::cancelObserve())
> ** Partially supports multicast
> *** Sending on multicast works and works for receiving one reply
> *** Currently does not work with receiving multiple replies
> * API is modelled after QNAM but does not use it
> ** QCoapClient, QCoapRequest, QCoapReply
> * No DTLS support yet (see network discussion)
> * API does support IETF-style resource discovery (multicast GET to /.well-
> known/core)
> ** QCoapClient::discover, QCoapDiscoveryReply
> ** API needs a little work:
> *** signal and parameters
> *** discover() should be able to send on both IPv4 and v6 multicast, without
> the user hardcoding anything
> *** building of query parameters (QUrlQuery?)
> * Add a method to QCoapClient and QNetworkAccessManager: setDeleteOnFinished /
> setAutoDeleteReplies
> ** Defaults to false on QNAM, defauts to true here
> * No CoAP+TCP plans yet
>
> === Testing ===
>
> * Once we have CoAP server support, we can test client against server
> * Inadviseable to run a CoAP server on the Qt network test server
> ** Network too unstable already in TCP, probably a horrible idea to use it
> with UDP
> * We should run a local server on the testing VM
> ** Californium is Java
> ** We may need to write something with libcoap (C)
>
> == CoAP server ==
>
> We will need it. For example, ''all'' OCF devices are both clients and
> servers.
>
> == DTLS ==
>
> * DTLS support needs to be added to QtNetwork or it will be too difficult
> ** We just need to design it so that it will work for both the CoAP client and
> server
>
> == CBOR ==
> We would like to have CBOR support in QtCore.

If you do this, please support stringref extension: 
http://cbor.schmorp.de/stringref

> * Would the API be part of QJsonDocument or separate (but looking like it)?
> ** Thiago's gut feeling is that making it part of QJsonDocument will make it
> too constrained for future uses (Example: COSE uses integer keys in maps, not
> strings)
> * Volunteers to work with Thiago on doing this
> ** Witekio people
> ** Frederik
> ** Shawn
> ** Alexandro
>
> --
> Thiago Macieira - thiago.macieira (AT) intel.com
>   Software Architect - Intel Open Source Technology Center
>
> ___
> Development mailing list
> Development@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development

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

Re: [Development] Repository request: HTTP server

[Konstantin Tokarev]

06.10.2017, 20:12, "Jason H" :
>>  Hi all,
>>
>>  We have recently been working on a research project looking into the 
>> possibilities for creating a lightweight server component that can easily 
>> enable Qt applications to serve over HTTP. We would like to make this work 
>> public and therefore request a repository.
>>
>>  This work is intended to continue as a research project, to explore 
>> alternatives and reveal areas that need work, so it should be under qt-labs.
>>
>>  Name of the project: Qt HTTP Server
>>  Responsible person: Fredrik de Vibe
>>  Gerrit user/email: fredrik.dev...@qt.io
>>  Desired repository name: qthttpserver
>
> About time :-) I wrote my first HTTP/S server in Qt 10 years ago!
>
> Now, I wonder what is the purpose of this http server?

Purpose of HTTP server is to handle requests from clients by HTTP protocol and 
send replies according to some business logic. It may also include built-in 
capability of serving static files.

> Surely, not serving PHP!?

That would be application server, for running PHP application in this case.

>
> Perhaps making it easy to serve a RESTful QObject-based hierarchy?

That would be some web framework then, not mere HTTP server

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

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

Re: [Development] Needing another advise using git

[Konstantin Tokarev]

04.10.2017, 20:29, "Daniel Savi" :
> Thank you all for the helpful comments on my previous message.
>
> I think that I have now managed to amend my changes into one commit and
> may understand how to react on comments.
>
> While amending my commits I must somehow have pushed another commit
> again that is not from me at all. It is this one:
> https://codereview.qt-project.org/#/c/207639/
>
> I certainly did not intend to push this one. How should I proceed to
> delete this commit from my changes?

Run `git rebase -i HEAD~2`, then remove line with unwanted commit, and close
file with saving (:wq if your EDITOR is vim), then push again

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

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

Re: [Development] QRandomGenerator and boot times

[Konstantin Tokarev]

19.09.2017, 13:14, "Konstantin Tokarev" <annu...@yandex.ru>:
> 14.09.2017, 10:22, "Sami Nurmenniemi" <sami.nurmenni...@qt.io>:
>>  Hi,
>>
>>  Commit 120ecc976fc3d5504d234702f68c2ad3898b77a4 changes default behavior of 
>> QRandomGenerator to use getentropy instead of /dev/urandom. This causes 
>> problems for device boot times when using QRandomGenerator in the boot 
>> sequence. As the commit message itself states "What's more, the glibc 
>> implementation blocks until entropy is available on early boot". Depending 
>> on the hw + kernel configuration of the device, this can increase boot time 
>> by more than a minute. For example in the Boot2Qt image qdbd and qtlauncher 
>> demo now block until the nonblocking pool is initialized. See QTBUG-63188.
>>
>>  What do you suggest for working around this problem?
>>  1. Disable feature "getentropy" from Boot2Qt builds
>>  - This is the behavior in Qt < 5.10.x
>>  - Only difference in the entropy of randomness is in the early boot
>>  2. Add "rng-tools" to the image for inputting entropy to the kernel
>>  - Speeds up initialization of nonblocking pool
>>  - On devices with HW random generator, this adds real entropy to the kernel 
>> pool
>>  - On devices without HW random generator, this adds bad entropy from 
>> /dev/urandom to the kernel pool
>>  3. Setting  QT_HASH_SEED for the affected processes
>>  - Not a good solution IMO
>
> Why? Is hash randomization really important in your case?

Actually, you can read value of QT_HASH_SEED from /dev/urandom, restoring 
previous behavior exactly.

> Also, you may want to replace QHash with a different data structure in your 
> boot code.
>
>>  - It seems code using this in qhash.cpp is the actual reason for the 
>> blocked processes (originated from QDebug)
>>  4. Something else?
>>
>>  Best Regards,
>>  Sami Nurmenniemi
>>
>>  ,
>>
>>  ___
>>  Development mailing list
>>  Development@qt-project.org
>>  http://lists.qt-project.org/mailman/listinfo/development
>
> --
> Regards,
> Konstantin
> ___
> Development mailing list
> Development@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development

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

Re: [Development] QRandomGenerator and boot times

[Konstantin Tokarev]

14.09.2017, 10:22, "Sami Nurmenniemi" :
> Hi,
>
> Commit 120ecc976fc3d5504d234702f68c2ad3898b77a4 changes default behavior of 
> QRandomGenerator to use getentropy instead of /dev/urandom. This causes 
> problems for device boot times when using QRandomGenerator in the boot 
> sequence. As the commit message itself states "What's more, the glibc 
> implementation blocks until entropy is available on early boot". Depending on 
> the hw + kernel configuration of the device, this can increase boot time by 
> more than a minute. For example in the Boot2Qt image qdbd and qtlauncher demo 
> now block until the nonblocking pool is initialized. See QTBUG-63188.
>
> What do you suggest for working around this problem?
> 1. Disable feature "getentropy" from Boot2Qt builds
> - This is the behavior in Qt < 5.10.x
> - Only difference in the entropy of randomness is in the early boot
> 2. Add "rng-tools" to the image for inputting entropy to the kernel
> - Speeds up initialization of nonblocking pool
> - On devices with HW random generator, this adds real entropy to the kernel 
> pool
> - On devices without HW random generator, this adds bad entropy from 
> /dev/urandom to the kernel pool
> 3. Setting  QT_HASH_SEED for the affected processes
> - Not a good solution IMO

Why? Is hash randomization really important in your case?
Also, you may want to replace QHash with a different data structure in your 
boot code.

> - It seems code using this in qhash.cpp is the actual reason for the blocked 
> processes (originated from QDebug)
> 4. Something else?
>
> Best Regards,
> Sami Nurmenniemi
>
> ,
>
> ___
> Development mailing list
> Development@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development


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

Re: [Development] std::allocate_shared for QSharedPointer

[Konstantin Tokarev]

13.09.2017, 04:40, "Ed Leaver" :
> What??? You mean there's actually a reason people aren't knocking the doors 
> down over these things? =-O
>
> A few months ago I was handed a C++ Coding Standard that deigned to prohibit 
> any further heap allocation after program initialization. It was originally 
> intended for a hard real-time system; I racked my feeble mind trying to 
> ascertain how it could possibly apply to our particular project, and finally 
> suggested -- much as yourself -- that if memory allocation were felt to be a 
> legitimate concern, there were hooks enough described in man 5 proc to settle 
> the issue one way or another.
>
> Then tactfully suggested a more appropriate standard. Tactfully enough that 
> the suggestion was accepted.
>
> I ran across TCMalloc in the process. It sounds Really Neat -- but it wasn't 
> clear why it's Really Neat properties hadn't already been incorporated into 
> the standard kernel allocator.  Is why I asked.

Don't confuse kernel allocator with libc (malloc) allocator.

>
> Thanks!
>
> On 09/12/2017 08:43 AM, Thiago Macieira wrote:
>> On Monday, 11 September 2017 17:45:01 PDT Ed Leaver wrote:
>>> Have any of you experience with jemalloc or TCMalloc? 
>>> http://goog-perftools.sourceforge.net/doc/tcmalloc.html
>>
>> Yes. I don't remember which of the two allocators or the details, but I 
>> remember one of them had a huge thread-safety problem and would corrupt 
>> itself. Use at your own risk. I will close any bug reports filed if you 
>> change malloc.
> ,
>
> ___
> Development mailing list
> Development@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development


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

Re: [Development] std::allocate_shared for QSharedPointer

[Konstantin Tokarev]

Don't challenge your allocator, just use intrusive reference counting
(e.g. QSharedData)

12.09.2017, 03:45, "Ed Leaver" :
> Have any of you experience with jemalloc or TCMalloc?
> http://goog-perftools.sourceforge.net/doc/tcmalloc.html
>
> On 09/10/2017 08:26 AM, Thiago Macieira wrote:
>>  On Saturday, 9 September 2017 17:16:24 -03 Sean Harmer wrote:
>>>  Yes, vtune shows the line
>>>
>>>  static_cast(::operator
>>>  new(sizeof(ExternalRefCountWithContiguousData)));
>>>
>>>  is the bottleneck in this particular test case, qt3d/tests/manual/bigscene-
>>>  cpp. I maybe able to reduce the calls to this by a small constant factor 
>>> but
>>>  I'm not sure yet, need to do some more digging/experimenting. So using a
>>>  pool seemed like a viable approach to reducing this bottleneck.
>>>
>>>  Granted, this is an extreme stress test (1k QEntities, each with 2 x
>>>  QPropertyAnimations) but it makes a nice one to profile.
>>  Well, if you microbenchmark, then memory allocation is almost always a
>>  bottleneck. I'd be more interested in real-world numbers.
>>
>>  But anyway, I don't see a way to pool the private pointers. You always get a
>>  new one if you add a new pointer to an object.
>
> ___
> Development mailing list
> Development@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development

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

Re: [Development] QtWebKit is coming back (part 2)

[Konstantin Tokarev]

07.09.2017, 10:45, "Martin Koller" <kol...@aon.at>:
> On Donnerstag, 27. Juli 2017 16:13:05 CEST Konstantin Tokarev wrote:
>>  27.07.2017, 16:41, "Martin Koller" <kol...@aon.at>:
>>  > On Dienstag, 25. Juli 2017 14:20:28 CEST Konstantin Tokarev wrote:
>>  >
>>  >> >> You can compile with GCC 4.8 if IndexedDB and FTL JIT are disabled. 
>> However this brings a
>>  >> >> degradation of user experience, especially in case of IndexedDB which 
>> was supported
>>  >> >> in previous versions. Therefore you have 3 options:
>>  >> >>
>>  >> >> 1) Disable these features and build limited version using GCC 4.8;
>>  >> >
>>  >> > that brings us to the second part of my question which was not 
>> answered: how ?
>>  >> > Is there any qmake or env var I can set ?
>>  >>
>>  >> Pass -DENABLE_FTL_JIT=OFF -DENABLE_INDEXED_DATABASE=OFF
>>  >> -DENABLE_DATABASE_PROCESS=OFF to cmake arguments
>>  >>
>>  >> You should not use qmake in your package, look at [1] for example.
>>  >>
>>  >> [1] 
>> http://pkgs.fedoraproject.org/cgit/rpms/qt5-qtwebkit.git/tree/qt5-qtwebkit.spec
>
> It also seems that it requires a too new ICU devel package (at least for 
> CentOS 7.3), that is
> I need to deactivate INTL by using -DENABLE_INTL=OFF
>
> Can you tell us what I actually disable with that switch, e.g.: what does no 
> longer work ?

Intl

https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Intl

>
> --
> Best regards/Schöne Grüße
>
> Martin
>
> () ascii ribbon campaign - against html e-mail
> /\ - against proprietary attachments

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

Re: [Development] [fix]: Assistant (and others) burning CPU because of #f27d1ccbb24ec2fd4098f2976503478831006cc8 ?

[Konstantin Tokarev]

31.08.2017, 16:48, "René J. V. Bertin" :
> Sergio Martins wrote:
>
>>  Interesting way such as LTTNG/ETW :) ?
>
> Spoiler alert: not on Mac ...

Mac has DTrace

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

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

Re: [Development] Qt and IoT infographic

[Konstantin Tokarev]

29.08.2017, 19:00, "Thiago Macieira" :
> On Tuesday, 29 August 2017 02:43:44 PDT Shawn Rutledge wrote:
>>  And yet it has a web server for serving up either a human-readable page or
>>  JSON on demand, and it also pushes data to a central server periodically.
>
> Is that a static JSON? Because if you need to compose the data on the fly, you
> may also want to replace JSON with something simpler. See
> https://github.com/01org/tinycbor/

This pesky people like to look up replies from their URLs in their browsers, so 
they
want HTTP and text-based serialization.

>
> You'll find that the maintainer is familiar :-)
>
> As for the part about "pushes data to a central server", I hope it's a server
> on the local network, not on the Cloud.
>
>>  After
>>  reading about CoAP I think it would be a much better fit than HTTP for such
>>  a device, so I hope I find the time to try. But then again, browsers don’t
>>  have CoAP yet, so I wonder if there could be a web client that uses JS to
>>  talk to it. Having to build a dedicated Qt client for it would be a step
>>  backwards in a way, but also nice for a desktop widget or some such.
>
> Firefox has a CoAP addon.
> https://addons.mozilla.org/en-US/firefox/addon/copper-270430/
>
> As for Chrome, I'll cat with Alexis and see what he thinks about the chances
> of adding it by default to the browser.
>
>>  Qt for IoT is maybe primarily for devices that have graphically-rich
>>  screens. But they can be clients reading data from truly-embedded sensors,
>>  and they might also have data of their own to serve to other clients
>>  (consolidated results, or just extra sensors that happen to be attached).
>
> Good point on the data of their own.
>
> I really do think we need to reevaluate our position that Qt is for clients
> only. I'm not against the HTTP server stack. I'm just saying it's a much more
> complex beast. And unlike the server that serves a single page, any Qt
> solution that makes to API would need to be a lot more capable.
>
> Otherwise, just lift the MiniHttpServer from the many unit tests.
>
>>  There are some PLCs powerful enough to run Linux, though, like these:
>>  https://www.bachmann.info/en/products/controller-system/ Some industrial
>>  applications can afford to use them, and so can the shipping industry, as I
>>  learned a couple of years ago on a certain consulting gig… and so they can
>>  afford to use Qt too, just for network comms, even though there is no GUI.
>
> Intel has shown that Linux is a viable target at 2 MB of RAM. We can boot a
> kernel at 1 MB, but then there's nothing left for your application. Shrinking
> the kernel further is possible, but it depends on whether the upstream would
> accept such changes -- for example, disabling TCP and leaving only UDP
> enabled. The kernel network maintainers currently have the position that they
> don't want this and you should just switch to a microcontroller RTOS at that
> point.
>
> For Qt, we have to make sure it runs comfortably at 128 MB and we should
> strive to make it possible for 32 MB of RAM.
>
> But the question is whether this is worth the effort. Are there devices that
> have memory in this range? One anecdote I've heard is that you can't buy DRAM
> at less than 512 MB -- since there's just not enough volume for them, their
> prices went up, causing people to stop buying them, further causing the prices
> to go up...
>
> --
> Thiago Macieira - thiago.macieira (AT) intel.com
>   Software Architect - Intel Open Source Technology Center
>
> ___
> Development mailing list
> Development@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development

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

Re: [Development] QtWebKit is coming back (part 2)

[Konstantin Tokarev]

17.08.2017, 18:17, "Thiago Macieira" <thiago.macie...@intel.com>:
> On Thursday, 17 August 2017 08:12:23 PDT Konstantin Tokarev wrote:
>>  Altrernatively, you can drop qtwebkit sources on the same level with other
>>  Qt modules, however it will break if you customize installation paths, e.g.
>>  use custom libdir. Also, cross-compilation is not supported in this way
>
> That doesn't work anymore, as of this week, since commit
> 5a0dc401fad4adccbd975392295d2c77d936900f.

Indeed, I forgot that .gitmodules is used for non-git builds too

>
> --
> Thiago Macieira - thiago.macieira (AT) intel.com
>   Software Architect - Intel Open Source Technology Center
>
> ___
> Development mailing list
> Development@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development

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

Re: [Development] QtWebKit is coming back (part 2)

[Konstantin Tokarev]

17.08.2017, 18:06, "Thiago Macieira" :
> On Thursday, 17 August 2017 07:24:05 PDT Martin Koller wrote:
>>  Hi,
>>
>>  is the 5.212 branch now as integrated in Qt as it was before in Qt 5.5 in
>>  the way that I can build Qt with webkit support so that the help system and
>>  assistant also use it ?
>
> No.
>
> You need to use the split-build mechanism, the one that Linux distributions
> use. Build each of the regular modules individually, then qtwebkit, then
> qtwebkit-examples, qttools (for assistant).

Altrernatively, you can drop qtwebkit sources on the same level with other Qt 
modules,
however it will break if you customize installation paths, e.g. use custom 
libdir. Also,
cross-compilation is not supported in this way

>
>>  What is the recommended way to build Qt and assistant to have webkit support
>>  ?
>
> --
> Thiago Macieira - thiago.macieira (AT) intel.com
>   Software Architect - Intel Open Source Technology Center
>
> ___
> Development mailing list
> Development@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development

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

Re: [Development] QtWebKit is coming back (part 2)

[Konstantin Tokarev]

27.07.2017, 16:41, "Martin Koller" <kol...@aon.at>:
> On Dienstag, 25. Juli 2017 14:20:28 CEST Konstantin Tokarev wrote:
>
>>  >> You can compile with GCC 4.8 if IndexedDB and FTL JIT are disabled. 
>> However this brings a
>>  >> degradation of user experience, especially in case of IndexedDB which 
>> was supported
>>  >> in previous versions. Therefore you have 3 options:
>>  >>
>>  >> 1) Disable these features and build limited version using GCC 4.8;
>>  >
>>  > that brings us to the second part of my question which was not answered: 
>> how ?
>>  > Is there any qmake or env var I can set ?
>>
>>  Pass -DENABLE_FTL_JIT=OFF -DENABLE_INDEXED_DATABASE=OFF
>>  -DENABLE_DATABASE_PROCESS=OFF to cmake arguments
>>
>>  You should not use qmake in your package, look at [1] for example.
>>
>>  [1] 
>> http://pkgs.fedoraproject.org/cgit/rpms/qt5-qtwebkit.git/tree/qt5-qtwebkit.spec
>
> thanks. I'm just trying this but I get a link failure (error below).
>
> Questions:
> - Does QtWebKit allow to disable Qt-Quick alltogether ? I don't need that.

-DENABLE_WEBKIT2=OFF

>   (I had Qt 5.9.1 configured without qtdeclarative, but then the cmake call 
> for QtWebKit already failed)
> - Does QtWebKit allow to be compiled as a namespaced/infixed library, as was 
> possible in e.g. Qt 5.5

QtWebKit has never allowed compilation as namespaced library, but it supports 
compilation against namespaced Qt

As for infix, it is not supported with new build system and this is is indeed a 
regression, patches are welcome

>   so that the result is a libQt5WebKitWinCC_OA.so (Qt 5.9.1 is compiled with 
> -qtnamespace WinCC_OA -qtlibinfix WinCC_OA)
>
> ../../lib/../Source/WebKit2/CMakeFiles/WebKit2.dir/UIProcess/API/qt/qquickwebview.cpp.o:
>  In function 
> `QQuickWebViewExperimental::QQuickWebViewExperimental(QQuickWebView*, 
> QQuickWebViewPrivate*)':
> qquickwebview.cpp:(.text._ZN25QQuickWebViewExperimentalC2EP13QQuickWebViewP20QQuickWebViewPrivate+0xb6):
>  undefined reference to 
> `WinCC_OA::QQmlWebChannel::QQmlWebChannel(WinCC_OA::QObject*)'
> qquickwebview.cpp:(.text._ZN25QQuickWebViewExperimentalC2EP13QQuickWebViewP20QQuickWebViewPrivate+0xfd):
>  undefined reference to 
> `WinCC_OA::QQmlWebChannel::connectTo(WinCC_OA::QObject*)'
> ../../lib/../Source/WebKit2/CMakeFiles/WebKit2.dir/UIProcess/API/qt/qquickwebview.cpp.o:
>  In function 
> `QQuickWebViewExperimental::setWebChannel(WinCC_OA::QQmlWebChannel*)':
> qquickwebview.cpp:(.text._ZN25QQuickWebViewExperimental13setWebChannelEPN8WinCC_OA14QQmlWebChannelE+0x44):
>  undefined reference to 
> `WinCC_OA::QQmlWebChannel::disconnectFrom(WinCC_OA::QObject*)'
> qquickwebview.cpp:(.text._ZN25QQuickWebViewExperimental13setWebChannelEPN8WinCC_OA14QQmlWebChannelE+0x78):
>  undefined reference to 
> `WinCC_OA::QQmlWebChannel::connectTo(WinCC_OA::QObject*)'
> collect2: error: ld returned 1 exit status
> Source/WebKit/CMakeFiles/WebKit.dir/build.make:2647: recipe for target 
> 'lib/libQt5WebKit.so.5.212.0' failed
>
> --
> Best regards/Schöne Grüße
>
> Martin
> A: Because it breaks the logical sequence of discussion
> Q: Why is top posting bad?
>
> () ascii ribbon campaign - against html e-mail
> /\ - against proprietary attachments
>
> Geschenkideen, Accessoires, Seifen, Kulinarisches: www.lillehus.at

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

Re: [Development] QtWebKit is coming back (part 2)

[Konstantin Tokarev]

24.07.2017, 08:33, "Martin Koller" <kol...@aon.at>:
> On Sonntag, 23. Juli 2017 23:45:30 CEST Konstantin Tokarev wrote:
>>  23.07.2017, 23:49, "Martin Koller" <kol...@aon.at>:
>>  > On Mittwoch, 3. Mai 2017 17:03:50 CEST Konstantin Tokarev wrote:
>>  >
>>  >> I'm not sure it would be acceptable, because updated QtWebKit requires 
>> full
>>  >> C++11 support in the compiler (gcc >= 4.9, 4.8 possible with disabling 
>> some
>>  >> features, or with code changes, which were not done yet).
>>  >
>>  > I'm trying to compile QtWebKit (5.212) on my openSuse 42.2, using the 
>> installed
>>  > gcc compiler (4.8.5) and I get:
>>  >
>>  > The WebKit build was disabled for the following reasons:
>>  > * Using gcc version 4.8, but at least gcc version 4.9 is required to 
>> build QtWebKit.
>>  >
>>  > So which features can I disable and how ?
>>  >
>>  > Note that gcc 4.8.5 is the std. compiler on the latest official version 
>> of openSuse and still
>>  > I can not compile ... :-(
>>
>>  You can compile with GCC 4.8 if IndexedDB and FTL JIT are disabled. However 
>> this brings a
>>  degradation of user experience, especially in case of IndexedDB which was 
>> supported
>>  in previous versions. Therefore you have 3 options:
>>
>>  1) Disable these features and build limited version using GCC 4.8;
>
> that brings us to the second part of my question which was not answered: how ?
> Is there any qmake or env var I can set ?

Pass -DENABLE_FTL_JIT=OFF -DENABLE_INDEXED_DATABASE=OFF
-DENABLE_DATABASE_PROCESS=OFF to cmake arguments

You should not use qmake in your package, look at [1] for example.

[1] 
http://pkgs.fedoraproject.org/cgit/rpms/qt5-qtwebkit.git/tree/qt5-qtwebkit.spec

>
> --
> Best regards/Schöne Grüße
>
> Martin
> A: Because it breaks the logical sequence of discussion
> Q: Why is top posting bad?
>
> () ascii ribbon campaign - against html e-mail
> /\ - against proprietary attachments
>
> Geschenkideen, Accessoires, Seifen, Kulinarisches: www.lillehus.at

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

Re: [Development] QtWebKit is coming back (part 2)

[Konstantin Tokarev]

23.07.2017, 23:49, "Martin Koller" <kol...@aon.at>:
> On Mittwoch, 3. Mai 2017 17:03:50 CEST Konstantin Tokarev wrote:
>
>>  I'm not sure it would be acceptable, because updated QtWebKit requires full
>>  C++11 support in the compiler (gcc >= 4.9, 4.8 possible with disabling some
>>  features, or with code changes, which were not done yet).
>
> I'm trying to compile QtWebKit (5.212) on my openSuse 42.2, using the 
> installed
> gcc compiler (4.8.5) and I get:
>
> The WebKit build was disabled for the following reasons:
> * Using gcc version 4.8, but at least gcc version 4.9 is required to 
> build QtWebKit.
>
> So which features can I disable and how ?
>
> Note that gcc 4.8.5 is the std. compiler on the latest official version of 
> openSuse and still
> I can not compile ... :-(

You can compile with GCC 4.8 if IndexedDB and FTL JIT are disabled. However 
this brings a
degradation of user experience, especially in case of IndexedDB which was 
supported
in previous versions. Therefore you have 3 options:

1) Disable these features and build limited version using GCC 4.8;

2) Provide patches that fix compilation with GCC 4.8 and these features enabled 
(it's broken now because GCC 4.8 fails to compile legal C++11 construction, 
namely expansion of vararg template parameter pack inside lambda expression;

3) Use a different compiler to build QtWebKit package which still can be binary 
compatible with the rest of the system. GCC >= 4.9 or Clang is fine

>
> I will have the same issue when I want to compile it for SLES-12-SP2 or RHEL 
> or CentOS-7
> all with gcc 4.8
>
> It would be really nice if the current release branch would compile at least 
> on these major distros
>
> --
> Best regards/Schöne Grüße
>
> Martin
> A: Because it breaks the logical sequence of discussion
> Q: Why is top posting bad?
>
> () ascii ribbon campaign - against html e-mail
> /\ - against proprietary attachments
>
> Geschenkideen, Accessoires, Seifen, Kulinarisches: www.lillehus.at

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

Re: [Development] Qt 5.9's new garbage collector documentation? + root_ptr

[Konstantin Tokarev]

14.07.2017, 10:18, "Thiago Macieira" :
> On quinta-feira, 13 de julho de 2017 17:32:58 PDT Phil Bouchard wrote:
>>  You just helped me figure something out: people want speed, right?
>>
>>  - You offer a service which converts and compiles all Javascript files
>>  for most popular architectures (i386, x86_64, ARM, MIPS, ...)
>>  - You cache these executables on the webserver in question
>>  - The client just downloads and caches the respective executable and
>>  executes it in the browser
>
> Except for the fact that no browser would ever download and execute untrusted
> binaries like that.
>
> The closest is Native Client (NaCl).

Which is being phased out in favor of WebAssembly (JIT-based)

>
>>  Because let's face it: WebGL is not going anywhere. It had the slowest
>>  progress I have ever seen!
>
> What progress does it need? It needs to implement the OpenGL ES API. Once that
> is done, they don't need to do anything. All the work is in the GL drivers and
> GPUs.
>
> --
> Thiago Macieira - thiago.macieira (AT) intel.com
>   Software Architect - Intel Open Source Technology Center
>
> ___
> Development mailing list
> Development@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development

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

Re: [Development] Qt 5.9's new garbage collector documentation? + root_ptr

[Konstantin Tokarev]

13.07.2017, 02:39, "Phil Bouchard" <philipp...@gmail.com>:
> On 07/12/2017 07:25 PM, Phil Bouchard wrote:
>>  On 07/12/2017 04:56 PM, Konstantin Tokarev wrote:
>>>  Now add time of compilation to the sum
>>
>>  So I just did benchmark the following C++ file featuring a loop within
>>  the code (the loop was at the bash shell level previously):
>>  
>> https://github.com/philippeb8/root_ptr/blob/qt/example/javascript_example1.cpp
>>
>>  With the exact equivalent in Javascript:
>>  
>> https://github.com/philippeb8/root_ptr/blob/qt/example/javascript_example1.js
>>
>>  And the executable generated by g++ is still 1.7 times faster than by
>>  using Node.JS. For small Javascript perhaps the net speed are the same
>>  but the more complex the code is then the generated binary by g++ simply
>>  is faster when compared to the Node.JS interpreter.
>
> The browser should "cache" these temporary executables anyway.

A you were following development of WebKit and JavaScriptCore, you should be
aware of story of using LLVM (i.e. "real" compiler) as a final JIT tier, and 
how did it
end up.

https://webkit.org/blog/5852/introducing-the-b3-jit-compiler/

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

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

Re: [Development] Qt 5.9's new garbage collector documentation? + root_ptr

[Konstantin Tokarev]

12.07.2017, 22:35, "Phil Bouchard" <philipp...@gmail.com>:
> Phil Bouchard <philipp...@gmail.com> wrote:
>>  On 07/11/2017 06:36 AM, Konstantin Tokarev wrote:
>>>  10.07.2017, 21:56, "Phil Bouchard" <philipp...@gmail.com>:
>>>>  Phil Bouchard <philipp...@gmail.com> wrote:
>>>>>  BTW converting Javascript into C++ seems very easy to do
>>>>
>>>>  In fact, is it me or it would seem that:
>>>>  - converting the Javascript code into C++ on-the-fly
>>>>  - compiling the resulting C++ code
>>>
>>>  This approach would have abysmal performance
>>>
>>>>  Would be a more efficient alternative than all these JIT tools?
>>>
>>>  Not at all
>>
>>  Maybe we can benchmark all this stuff once I'm done... just out of
>>  curiosity.
>
> Actually I just did a benchmark of my "js2cpp" tool and interpreting the
> code using Node.JS and js2cpp generates an executable that is 34 times
> faster!

Now add time of compilation to the sum

>
> I don't know about you but a minimalist version of g++ embedded inside the
> browser could be beneficial big time.
>
> -Phil
>
> ___
> Development mailing list
> Development@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development

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

Re: [Development] Qt-AES - Looking for comments

[Konstantin Tokarev]

12.07.2017, 19:36, "Thiago Macieira" <thiago.macie...@intel.com>:
> On quarta-feira, 12 de julho de 2017 09:26:52 PDT Konstantin Tokarev wrote:
>>  12.07.2017, 19:21, "Thiago Macieira" <thiago.macie...@intel.com>:
>>  > On quarta-feira, 12 de julho de 2017 07:52:20 PDT Matteo wrote:
>>  >> At the beginning this was for my own personal use as I was in need of
>>  >> some
>>  >> sort of encryption for a work project without using openssl, then I just
>>  >> released the code for the class on github, it's more a code exercise
>>  >> than a real usable class for the issues you pointed out.
>>  >
>>  > Try this instead: https://github.com/01org/tinycrypt
>>
>>  Or https://github.com/libtom/libtomcrypt
>
> How certified is it?
>
> The Intel implementation above is audited.

I don't know, but it's widely used as a part of Dropbear, which is the most 
popular
SSH client and server implementation for embedded systems.

>
> --
> Thiago Macieira - thiago.macieira (AT) intel.com
>   Software Architect - Intel Open Source Technology Center
>
> ___
> Development mailing list
> Development@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development

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

Re: [Development] Qt-AES - Looking for comments

[Konstantin Tokarev]

12.07.2017, 19:21, "Thiago Macieira" :
> On quarta-feira, 12 de julho de 2017 07:52:20 PDT Matteo wrote:
>>  At the beginning this was for my own personal use as I was in need of some
>>  sort of encryption for a work project without using openssl, then I just
>>  released the code for the class on github, it's more a code exercise than a
>>  real usable class for the issues you pointed out.
>
> Try this instead: https://github.com/01org/tinycrypt

Or https://github.com/libtom/libtomcrypt

>
> --
> Thiago Macieira - thiago.macieira (AT) intel.com
>   Software Architect - Intel Open Source Technology Center
>
> ___
> Development mailing list
> Development@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development

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

Re: [Development] Qt 5.9's new garbage collector documentation? + root_ptr

[Konstantin Tokarev]

10.07.2017, 21:56, "Phil Bouchard" :
> Phil Bouchard  wrote:
>>  BTW converting Javascript into C++ seems very easy to do
>
> In fact, is it me or it would seem that:
> - converting the Javascript code into C++ on-the-fly
> - compiling the resulting C++ code

This approach would have abysmal performance

>
> Would be a more efficient alternative than all these JIT tools?

Not at all

>
> My 2 cents,
> -Phil
>
> ___
> Development mailing list
> Development@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development

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

Re: [Development] Qt 5.9's new garbage collector documentation? + root_ptr

[Konstantin Tokarev]

11.07.2017, 07:52, "Phil Bouchard" :
> On 07/10/2017 05:08 PM, Thiago Macieira wrote:
>>  On segunda-feira, 10 de julho de 2017 11:56:07 PDT Phil Bouchard wrote:
>>>  Phil Bouchard  wrote:
  BTW converting Javascript into C++ seems very easy to do
>>>
>>>  In fact, is it me or it would seem that:
>>>  - converting the Javascript code into C++ on-the-fly
>>>  - compiling the resulting C++ code
>>>
>>>  Would be a more efficient alternative than all these JIT tools?
>>
>>  No. That would require having a C++ compiler with all the dependent 
>> libraries
>>  on every user's device.
>>
>>  You must run the JS as provided and interact with the plugins as they exist
>>  today.
>
> Indeed Javascript is not made to run heavy CPU algorithms anyways.

Really? 

http://browserbench.org/JetStream/

>
> On the other hand, I have good news as I think I have found a way to
> simulate functions that return a function. I know a Javascript to C++
> converter is not what we're looking for but it helps me understand these
> cases better.
>
> -Phil
>
> ___
> Development mailing list
> Development@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development

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

Re: [Development] How is Quick Controls 2 deployment meant to be ?

[Konstantin Tokarev]

08.07.2017, 21:01, "Massimo Callegari via Development" 
:
> On Sat, Jul 08, 2017 at 11:24:56AM +, Massimo Callegari via Development 
> wrote:
>
>>>  2) Security ? There is none. If you deploy an application using a 
>>> TextField control with
>>>  echoMode: TextInput.Password, one can easily add some trivial JavaScript 
>>> code to the
>>>  comfortably reachable QtQuick/Controls.2/TextField.qml file and somehow 
>>> display/log a
>>>  password. In general, an end user can seriously mess up an application by 
>>> changing a few
>>>  text files. I'm also wondering how Linux distributions can accept this. In 
>>> my KDE Neon
>>>  distro I've got /usr/lib/x86_64-linux-gnu/qt5/qml/ full of QML files that 
>>> I can edit and
>>>  compromise my system.
>
>>  I'll not argue about the others, but this here is nonsense. Anyone who can 
>> edit
>>  /lib normally can also edit /etc etc.
>
> I disagree. The nonsense, instead, is comparing configuration files with 
> source files.
> Config files are usually parsed by an application, which (hopefully) filters 
> malicious intentions.
> QML files instead, are executed by the application no matter what.
> As long as "edited" QML files have a correct syntax, the QML engine executes 
> them.

Exactly the same situation exists with binary plugins of Qt. Anyone with write 
access to plugins
directory can put malicious code in plugin at it will be executed by Qt. 

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

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

Re: [Development] Problems building qtwebkit in 5.9.1

[Konstantin Tokarev]

14.06.2017, 12:49, "Harald Vistnes" :
> Hi,
>
> Has there been a change in the dependencies for qtwebkit in 5.9.1? I am not 
> able to build it anymore.
>
> I am using these commands:
>
> ...
> perl init-repository 
> --module-subset=all,-ignore,-qtwebkit-examples,-qtwebengine,-qtnetworkauth,-qtspeech,-qtandroidextras,-qtvirtualkeyboard,-qtcanvas3d,-qtdatavis3d,-qtcharts,-qtpurchasing,-qtquickcontrols2,-qtmultimedia,-qtserialport,-qtwayland,-qtdoc
>
> configure -prefix %CD%\qtbase -opensource -shared -confirm-license 
> -debug-and-release -release -opengl desktop -qt-zlib -qt-libpng -no-angle 
> -qt-libjpeg -icu -skip qtconnectivity -skip qtlocation -skip qtsensors -skip 
> qtwayland -skip qtserialbus -skip qtserialport -skip qtvirtualkeyboard -skip 
> qtdatavis3d -skip qtcharts -skip qtpurchasing -skip qtcanvas3d -skip qtspeech 
> -skip qtandroidextras -skip qtnetworkauth -skip qtquickcontrols -skip 
> qtwebengine -platform win32-msvc2015 -nomake tests
>
> cd qtwebkit
>
> ../qtbase/bin/qmake.exe WebKit.pro
>
> In 5.9.1 I get the following output from qmake:
>
> Running configure tests...
>
> Checking for fontconfig... no
> Checking for gccdepends... no
> Checking for glx... no
> Checking for gnuld... no
> Checking for icu... yes
> Checking for leveldb... no
> Checking for libsqlite3... no
> Checking for libwebp... no
> Checking for libXcomposite... no
> Checking for libxml2... no
> Checking for libXrender... no
> Checking for libxslt... no
> Checking for libzlib... no
> Project ERROR: Could not find feature system-jpeg.
>
> I did not get this error in 5.9.0 or in any previous versions.

You should use 5.212 branch of QtWebKit instead of 5.9.1.
Build instruction: 
https://github.com/annulen/webkit/wiki/Building-QtWebKit-on-Windows


>
> I am on Windows, but a colleague got the same error on Linux. He also tried 
> to configure with -system-jpeg, but with the same result.
>
> Thanks,
> Harald
>
> ,
>
> ___
> Development mailing list
> Development@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development


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

Re: [Development] Dropping older compilers for Qt 5.10 (was: Qt 5.10 pre-built bunaries)

[Konstantin Tokarev]

08.06.2017, 01:11, "Thiago Macieira" <thiago.macie...@intel.com>:
> On quarta-feira, 7 de junho de 2017 13:30:30 PDT Konstantin Tokarev wrote:
>>  FWIW, the first really C++11 complete version of GCC is 4.9, 4.8 still has a
>>  number of bugs that result in internal compiler errors, compilation errors,
>>  or runtime errors in some non-trivial but valid C++11 code. See for example
>>  patches in [1, 2]
>
> 4.9 is a 4-year-old compiler today. I'd love to get rid of the buggy 5.3.x,
> but that's too recent. Quick survey shows:
> * GCC 4.9 in Ubuntu 14.04 LTS, Debian Jessie, Fedora 21 [*]
> * GCC 4.8.5 in the latest OpenSUSE Leap, SUSE Linux Enterprise. and CentOS /
>    RHEL.
> [*] F21 is not supported by Fedora; minimum support at the time of Qt 5.10's
>   release will be F24
>
> So I'm guessing we should require GCC 4.8.5 (all the latest fixes). This will
> give us full C++11 support in GCC.

I'd like to insist that GCC 4.8 does not provide full C++11 support (see my 
previous mail),
i.e. targeting GCC 4.8 implementation of C++11 is still substantially different 
than targeting
C++11 standard.

> Clang claims to be fully C++14 compliant in
> 3.4, which we already require.
>
> Then there's MSVC. So... should we begin thinking of dropping MMSVC 2013?
> We'll gain by doing that:
>  * default and delete members
>  * alignas & alignof
>  * inheriting constructors
>  * noexcept
>  * range for (without having to check if it really works)
>  * ref qualifiers (no more need for #ifdef)
>  * thread_local (QRandomGenerator benefits from this, also obviates the need 
> to
> introduce Q_THREAD_LOCAL)
>  * user defined literals
>  * Unicode strings
>  * unrestricted unions
>
> Another benefit is that MSVC 2017 and 2015 are supposedly binary compatible
> with each other. With care, we can even use this feature in Qt.
>
> If we require MSVC 2015 with the most recent update (which is over a year old
> now), in addition we get:
>  * attributes
>  * thread-safe statics (finally! could drop the fallback from Q_GLOBAL_STATIC!
> oh, wait, Apple...)
>  * uniform initialisation (without having to check if it really works)
>
> In other words, there'll be exactly one C++11 feature we won't be able to
> indiscriminately use:
>  * constexpr
>
> (plus whatever fails due to issues in the the Standard Libraries)
>
> --
> Thiago Macieira - thiago.macieira (AT) intel.com
>   Software Architect - Intel Open Source Technology Center
>
> ___
> Development mailing list
> Development@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development

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

Re: [Development] [Releasing] Qt 5.10 pre-built bunaries

[Konstantin Tokarev]

07.06.2017, 23:09, "Thiago Macieira" :
> On Tuesday, 6 June 2017 23:57:10 PDT Jani Heikkinen wrote:
>>  Hi all,
>>
>>  There has been discussion ongoing about 5.10 supported platforms and CI
>>  configurations. What we haven't agreed yet is Qt 5.10 pre-built binaries. I
>>  don't see big need to change anything from 5.9 but there is still couple of
>>  things on my mind:
>>
>>  - Should we now switch from MinGW32 bit -> MinGW 64bit ones? With 5.9 this
>>  was too early but would it be time to do it now? Offering both isn't an
>>  option. And 5,9 is LTS so 5.10 could be good release to change that...
>>
>>  - Can we start using RHEL 7.4 for linux packaging? Tony is planning to add
>>  RHEL 7.4 in CI and so on it would be wise to replace 7.2 with 7.4 in the
>>  packaging as well
>>
>>  Is there some other change proposals which we should discuss about?
>
> I'd like to propose raising the minimum version for GCC to 4.8.1, which is the
> first C++11 complete version, or higher. The reason for this is actually to
> drop GCC 4.7 and earlier, which have a few bugs with their C++11 support. GCC
> 4.7 has been the minimum since Qt 5.7.0 and is now 5 years old.

FWIW, the first really C++11 complete version of GCC is 4.9, 4.8 still has a 
number
of bugs that result in internal compiler errors, compilation errors, or runtime 
errors in
some non-trivial but valid C++11 code. See for example patches in [1, 2]

[1] https://trac.webkit.org/search?q=gcc+4.8=1=on
[2] 
https://trac.webkit.org/search?q=libstdc%2B%2B+4.8=1=on

>
> I've just been bitten by one with QRandomGenerator, relating to calling static
> member functions from a lambda. The workaround suggested in the Coding
> Convention is not applicable going forward because Clang 5.0 will produce a
> warning about it (I've updated the wiki), so we have to choose which one we'll
> support very shortly, as soon as Apple begins shipping Clang based on the
> current trunk version in XCode.
>
> --
> Thiago Macieira - thiago.macieira (AT) intel.com
>   Software Architect - Intel Open Source Technology Center
>
> ___
> Development mailing list
> Development@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development

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

Re: [Development] Future of Qt on Web?

[Konstantin Tokarev]

05.06.2017, 17:20, "Jason H" :
>>  Sent: Monday, June 05, 2017 at 12:34 AM
>>  From: "Lorn Potter" 
>>  To: development@qt-project.org
>>  Subject: Re: [Development] Future of Qt on Web?
>>
>>  On 06/05/2017 07:00 AM, Jason H wrote:
>>  > While Qt is not a web framework, over time there have been efforts to use 
>> it on the web (outlined below).
>>  >
>>  > Given that Chrome is dropping NaCL 
>> (http://www.tomshardware.com/news/chrome-deprecates-pnacl-embraces-webassembly,34583.html)
>>  and the WebGL streaming is also not ideal (but better?), I am wondering 
>> about the future of Qt on Web? Will there be a WebAssembly version of Qt?
>>
>>  We have been working on Qt5 for webassembly.
>>  I was just writing a short blog about this:
>>
>>  http://qtandeverything.blogspot.com.au/2017/06/qt-for-web-assembly.html
>
> That is great news! You mention the wasm is smaller? How much smaller?

This article says it's smaller than asm.js, not NaCl

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

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

Re: [Development] QNumericVector?

[Konstantin Tokarev]

02.06.2017, 19:55, "Jason H" :
> I'm just wondering out loud if it would be a good thing to have a numeric 
> vector type that supports math operations (and optionally will SIMD 
> accelerate them). Qt supports some fixed dimensionality vectors (QVecorXD, 
> x={2,3,4}). But this would add flexibility for say, machine learning 
> applications. The only collision that I know of is length() where the 
> existing fixed-dimension classes provide magnitude as length(). Additionally 
> it may be useful to support non-Euclidean spaces, though I wouldn't see much 
> use beyond polar (haversine) distances and bearings.
>
> Thoughts?

Use Eigen?

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

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

Re: [Development] Blacklisting: CI vs non-CI

[Konstantin Tokarev]

26.05.2017, 09:45, "Thiago Macieira" :
> I've seen some blacklists, in the past, that were real flaky tests: things 
> that
> would be unstable on any machine, given the proper conditions.
>
> But most of the recent blacklists, and certainly all the BPASS I see when I
> run tests, are due to the tests being run in an environment that runs 300x
> slower than normal. Can we invent a blacklist that only applies to slow
> machines?
>
> I don't need to see those BPASS on 100% of the time that the test is run on my
> machine.

If problem is that tests just don't have enough time to complete in CI 
environment,
it would be a good idea to mark such tests as "slow" so they get higher timeout
settings.

>
> --
> Thiago Macieira - thiago.macieira (AT) intel.com
>   Software Architect - Intel Open Source Technology Center
>
> ___
> Development mailing list
> Development@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development

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

Re: [Development] QList

[Konstantin Tokarev]

25.05.2017, 02:19, "Ville Voutilainen" <ville.voutilai...@gmail.com>:
> On 24 May 2017 at 22:25, Marc Mutz <marc.m...@kdab.com> wrote:
>>  On 2017-05-24 15:12, Konstantin Tokarev wrote:
>>>  24.05.2017, 15:49, "NIkolai Marchenko" <enmarantis...@gmail.com>:
>>>>  A semi-sane idea that I think no one has suggested yet:
>>>>
>>>>  What if, starting from Qt6, QList becomes a wrapper for QArrayList with a
>>>>  contructor from this type?
>>>>  After all making existing code slightly _slower_ because of the wrapping
>>>>  overhead is way less problematic than breaking it outright.
>>>>  It will nudge the users of QLists that need to be fast to switch but will
>>>>  leave users of "default no brainer container" happy as they likely 
>>>> wouldn't
>>>>  even notice.
>>>
>>>  If existing Qt APIs switch from QList to QVector in Qt 6, such change
>>>  will make it hard to support both Qt 5 and Qt 6 in the same code base.
>>
>>  Which is why I suggested to make QList a type alias for QVector or
>>  QArrayList, depending on some yet-to-be-determined criteria. Obvious
>>  candidates algorithms are:
>
> I think we need to take a serious step backwards here. I, for various reasons,
> got the impression that a major problem at hand is that when a user (NOT in 
> any
> template code, necessarily) uses QList, that user doesn't know the
> consequences. 

Other problem, that IMO is more serious, is that Qt *requires* user to use 
QList,
by returning or taking it as and argument in various places. That's almost only
reason why I use QList in my code[*].

If Qt 6 APIs are changed from QList to QVector, lots of user code dealing with
this APIs will break, unless QList will become an alias of QVector.

[*] And, fwiw, almost only reason I use QString, but that's off-topic here

> Mostly because depending on the characteristics of Foo,
> the user doesn't know what the performance characteristics and semantics
> of QList are, because QList might or might not use (in)direct storage.
>
> Perhaps I completely fail to understand the problem space. I (think I)
> have read Marc's writings
> on the subject matter, but chances are that the crux of the matter is
> still escaping me.
> How does it help anyone to create a new alias that still results in a
> concrete type
> the semantics of which still depend on the element type?
> ___
> Development mailing list
> Development@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development

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

Re: [Development] QList

[Konstantin Tokarev]

24.05.2017, 16:19, "NIkolai Marchenko" <enmarantis...@gmail.com>:
> I was talking about the solution that assumes making a QArrayList type and 
> deprecating QList entirely,
> not the one that aliases QList to QVector which I, personally, don't like, 
> since it will produce a lot of the code perception problems and incorrect 
> perfomance assumptions.

So, do you propose to replace QList with QArrayList in existing APIs? That 
would be a serious pessimization for small types.

> Not to mention people will still widely use QList as it's "easier to type 
> "(don't laugh) and "looks like a default container by simplicity of its name"
> (again, don't laugh, I am just outlining potential problems with new users)
>
> On Wed, May 24, 2017 at 4:12 PM, Konstantin Tokarev <annu...@yandex.ru> wrote:
>
>> 24.05.2017, 15:49, "NIkolai Marchenko" <enmarantis...@gmail.com>:
>>> A semi-sane idea that I think no one has suggested yet:
>>>
>>> What if, starting from Qt6, QList becomes a wrapper for QArrayList with a 
>>> contructor from this type?
>>> After all making existing code slightly _slower_ because of the wrapping 
>>> overhead is way less problematic than breaking it outright.
>>> It will nudge the users of QLists that need to be fast to switch but will 
>>> leave users of "default no brainer container" happy as they likely wouldn't 
>>> even notice.
>>
>> If existing Qt APIs switch from QList to QVector in Qt 6, such change will 
>> make it hard to support both Qt 5 and Qt 6 in the same code base.
>>
>>>
>>> On Tue, May 23, 2017 at 5:27 PM, Thiago Macieira 
>>> <thiago.macie...@intel.com> wrote:
>>>> On Tuesday, 23 May 2017 04:56:52 PDT Olivier Goffart wrote:
>>>>> In my opinion for Qt6, we should make prepend, takeFirst amortized O(1) in
>>>>> QVector.
>>>>
>>>> That is not very difficult once we move the begin pointer out of the d 
>>>> pointer
>>>> and into the main QVector class. We need to add an interface to QArrayData 
>>>> to
>>>> shrink and expand the buffer without relocating it. With that, we 
>>>> practically
>>>> hide the allocated capacity information from QVector too.
>>>>
>>>> --
>>>> Thiago Macieira - thiago.macieira (AT) intel.com
>>>>   Software Architect - Intel Open Source Technology Center
>>>>
>>>> ___
>>>> Development mailing list
>>>> Development@qt-project.org
>>>> http://lists.qt-project.org/mailman/listinfo/development
>>> ,
>>>
>>> ___
>>> Development mailing list
>>> Development@qt-project.org
>>> http://lists.qt-project.org/mailman/listinfo/development
>>
>> --
>> Regards,
>> Konstantin


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

Re: [Development] QList

[Konstantin Tokarev]

24.05.2017, 15:49, "NIkolai Marchenko" :
> A semi-sane idea that I think no one has suggested yet:
>
> What if, starting from Qt6, QList becomes a wrapper for QArrayList with a 
> contructor from this type?
> After all making existing code slightly _slower_ because of the wrapping 
> overhead is way less problematic than breaking it outright.
> It will nudge the users of QLists that need to be fast to switch but will 
> leave users of "default no brainer container" happy as they likely wouldn't 
> even notice.

If existing Qt APIs switch from QList to QVector in Qt 6, such change will make 
it hard to support both Qt 5 and Qt 6 in the same code base.

>
> On Tue, May 23, 2017 at 5:27 PM, Thiago Macieira  
> wrote:
>> On Tuesday, 23 May 2017 04:56:52 PDT Olivier Goffart wrote:
>>> In my opinion for Qt6, we should make prepend, takeFirst amortized O(1) in
>>> QVector.
>>
>> That is not very difficult once we move the begin pointer out of the d 
>> pointer
>> and into the main QVector class. We need to add an interface to QArrayData to
>> shrink and expand the buffer without relocating it. With that, we practically
>> hide the allocated capacity information from QVector too.
>>
>> --
>> Thiago Macieira - thiago.macieira (AT) intel.com
>>   Software Architect - Intel Open Source Technology Center
>>
>> ___
>> Development mailing list
>> Development@qt-project.org
>> http://lists.qt-project.org/mailman/listinfo/development
> ,
>
> ___
> Development mailing list
> Development@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development


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

Re: [Development] QtWebKit is coming back (part 2)

[Konstantin Tokarev]

11.05.2017, 16:10, "Oswald Buddenhagen" :
> On Wed, May 10, 2017 at 09:53:26AM +0200, Edward Welbourne wrote:
>> Oswald Buddenhagen (4 May 2017 18:35)
>> > i'll say outright that you can't be part of the qt supermodule and yet
>> > have independent releases. while that was the plan once upon a time, 
>> the
>> > whole release infrastructure simply doesn't deliver, and even just
>> > diverging branch names are a pita (proved by enginio).
>>
>> Can you elaborate on the pain here ?
>
> when the branch names are not uniform, they need to be derived from the
> repositories' actual contents (.qmake.conf, in particular). and that has
> historically been a mess because of lagging states due to late module
> additions, tardy version updates, and delayed merges and qt5 integrations.
>
> from the user perspective, diverging versions are a mess, because you
> never know what belongs together. that was particularly annoying with
> enginio, because there was no _reason_ for this being so.
>
>> I note, in particular, that we do have sub-sub-modules on branches
>> with eccentric names, or none
>
> these sub-modules' branches are completely desynchronized with qt, so
> dealing with them is not part of the qt release cycle. qt simply pins
> sha1s, and the modules are not directly in our CI.
>
>> What would we need to do to our release infrastructure to make it
>> cope with (as originally planned) independent release cycles for
>> distinct components ?
>
> i don't see how that would be logically possible at all as long as the
> rest of qt is released as a monolithic product and at the same time some
> qt modules depend on the prospective outliers. you would have to view
> the outlier as an external dependency, but that doesn't work because it
> depends on other qt modules, so it's circular.

I would be possible to pin sha1 in qt5.git from the tip of current stable branch
of the module, in the same manner as it's done now (except branch name
will be different and may be upgraded between Qt's patch releases)

As long as superbuild works, I don't see any technical problem with the
"circular" dependency.

>
> for additional illustration, consider jira: due to the differing
> versioning, you cannot use components for the outliers, but need
> separate products.

That's true.

>
> as atomizing the release of most qt modules is totally unrealistic and
> counterproductive, there isn't a way forward to arrive at a consistent
> model which would accomodate that.

Why?

For example, GNOME has a platform consisting of lots of libraries with
independent versioning and release schedules, and it works because
these libraries provide certain API/ABI guarantees

>
> oh, and then there are the processes for creating an actual release.
> have fun "forking" these for separate products ...
> ___
> Development mailing list
> Development@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development

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

Re: [Development] QtWebKit is coming back (part 2)

[Konstantin Tokarev]

  08.05.2017, 15:11, "Lars Knoll" <lars.kn...@qt.io>: On 5 May 2017, at 13:15, Konstantin Tokarev <annu...@yandex.ru> wrote: 05.05.2017, 10:04, "Tuukka Turunen" <tuukka.turu...@qt.io>:Hi,There has also been some interest also for getting Qt WebEngine to be released much faster cycle than Qt – exactly due to the security update need. Even if we succeed in making substantially more frequent Qt patch releases than before, it may still be better if user would have the option to update some parts (like QWE) more frequently or out of sync.I think what we should consider, is to perhaps carve out Qt WebEngine from Qt as well. Not immediately, but for Qt 6 we should anyway consider our current setup of essential and add-on modules. For the html5 engine there is the matter of binary size in addition to release frequency. This is not to say that we would stop developing html5 engine – just that it might be beneficial to do in in different way than currently.For new updated Qt Webkit, perhaps we could have it as a separate item that works on top of Qt 5.9 for those to use it who prefer it over Qt WebEngine. After it has existed for a while as a separate item, it is also easier to know what would be the best way to get it into a Qt release – or is that even necessary.BTW, let me bring an attention to the elephant in the room.Yes, my fork of QtWebKit existed for a while as a separate item. But it was neverand "official" successor, and even me myself was warning people that it is not anofficial replacement as some features are not yet restored.However, now there is no valid reason to keep using QtWebKit contained in 5.9 anddev branches anymore. Feature parity is achieved to the level of drop-in replacementthat can be applied system-wide. Still many people see 5.9 branch as a source of truth. Yes, we have been keeping the old code compiling, but we have not been supporting it for a while, and it hasn’t been tested since then neither.We need to convey a message to wide audience that old QtWebKit should no longer beused, and that there is a new release that should be used instead. Not only with Qt 5.9.0,but also with older Qt releases, down to Qt 5.2.x if people still use it (e.g., Ubuntu 14.04). I agree here. We’ve kept the old Qt Webkit compiling against newer Qt version because of requests from the community. I think we can drop this now, and tell people to use your branch instead. It’ll certainly be better and safer than the old code base.This is why question about version numbers and related stuff is important. If this is notdone, it doesn't matter at all whatever tag names will be picked and what schedules willbe followed. I have no problems dropping the old qtwebkit code base and tell people to move over to use your branch.  One option is that we do not provide any source package from the old code base for qtwebkit with Qt 5.9 anymore. This would free up the version numbers from 5.9 onwards.So I assume it's OK to use 5.9 number for QtWebKit relese that is coming now, right?  At the same time I do agree with Tuukka, that we need to reconsider the coupling between webkit/webengine and Qt releases. if current QtWebkit runs nicely on top of Qt, maybe that’s how we should keep it. This would allow us to provide source/binary packages of it on a more independent schedule. Cheers,Lars   Yours,TuukkaOn 04/05/2017, 22.26, "Development on behalf of Konstantin Tokarev" <development-bounces+tuukka.turunen=qt...@qt-project.org on behalf of annu...@yandex.ru> wrote:04.05.2017, 19:35, "Oswald Buddenhagen" <oswald.buddenha...@qt.io>:> On Thu, May 04, 2017 at 04:51:45PM +0300, Konstantin Tokarev wrote:>> 03.05.2017, 17:27, "Sergio Martins" <sergio.mart...@kdab.com>:>> > On 2017-05-03 15:02, Konstantin Tokarev wrote:>> >> Remaining question is versioning. While it's fine to dub current>> >> release "5.9" (but not 5.0, because we will have another WebKit update>> >> in 5.10 time frame), using Qt versions in QtWebKit has downsides:>> >>>> >> 1. It is not clear if 5.N+1 ships with the same WebKit branch as 5.N,>> >> or is updated>> >> 2. It makes people believe that QtWebKit 5.N should be used with Qt>> >> 5.N only. QtWebKit supports wide range of Qt versions (starting from>> >> 5.2 as of now), and can be used e.g. as security update in Linux>> >> distro that does not normally update Qt version during its life cycle.>> >>>> >> Any comments?>> >>> > If Qt and QtWebKit will have different release schedules then that>> > numbering would indeed confuse people.>>>> What about choice of new versioning scheme?>>>> I'm leaning to

Re: [Development] QtWebKit is coming back (part 2)

[Konstantin Tokarev]

08.05.2017, 15:22, "Lars Knoll" <lars.kn...@qt.io>:
>> On 8 May 2017, at 13:37, Jani Heikkinen <jani.heikki...@qt.io> wrote:
>>
>> Couple of comments below
>>
>> br,
>> Jani
>>
>>> -Original Message-
>>> From: Development [mailto:development-bounces+jani.heikkinen=qt.io@qt-
>>> project.org] On Behalf Of Konstantin Tokarev
>>> Sent: maanantaina 8. toukokuuta 2017 12.56
>>> To: Tuukka Turunen <tuukka.turu...@qt.io>; Oswald Buddenhagen
>>> <oswald.buddenha...@qt.io>; development@qt-project.org
>>> Subject: Re: [Development] QtWebKit is coming back (part 2)
>>>
>>> 05.05.2017, 14:15, "Konstantin Tokarev" <annu...@yandex.ru>:
>>>> 05.05.2017, 10:04, "Tuukka Turunen" <tuukka.turu...@qt.io>:
>>>>>  Hi,
>>>>>
>>>>>  There has also been some interest also for getting Qt WebEngine to be
>>> released much faster cycle than Qt – exactly due to the security update 
>>> need.
>>> Even if we succeed in making substantially more frequent Qt patch releases
>>> than before, it may still be better if user would have the option to update
>>> some parts (like QWE) more frequently or out of sync.
>>>
>>>>>  I think what we should consider, is to perhaps carve out Qt WebEngine
>>> from Qt as well. Not immediately, but for Qt 6 we should anyway consider
>>> our current setup of essential and add-on modules. For the html5 engine
>>> there is the matter of binary size in addition to release frequency. This 
>>> is not
>>> to say that we would stop developing html5 engine – just that it might be
>>> beneficial to do in in different way than currently.
>>>
>>>>>  For new updated Qt Webkit, perhaps we could have it as a separate item
>>> that works on top of Qt 5.9 for those to use it who prefer it over Qt
>>> WebEngine. After it has existed for a while as a separate item, it is also 
>>> easier
>>> to know what would be the best way to get it into a Qt release – or is that
>>> even necessary.
>>>
>>>> BTW, let me bring an attention to the elephant in the room.
>>>>
>>>> Yes, my fork of QtWebKit existed for a while as a separate item. But
>>>> it was never and "official" successor, and even me myself was warning
>>>> people that it is not an official replacement as some features are not yet
>>> restored.
>>>
>>>> However, now there is no valid reason to keep using QtWebKit contained
>>>> in 5.9 and dev branches anymore. Feature parity is achieved to the
>>>> level of drop-in replacement that can be applied system-wide. Still many
>>> people see 5.9 branch as a source of truth.
>>>
>>>> We need to convey a message to wide audience that old QtWebKit should
>>>> no longer be used, and that there is a new release that should be used
>>>> instead. Not only with Qt 5.9.0, but also with older Qt releases, down to 
>>>> Qt
>>> 5.2.x if people still use it (e.g., Ubuntu 14.04).
>>>
>>>> This is why question about version numbers and related stuff is
>>>> important. If this is not done, it doesn't matter at all whatever tag
>>>> names will be picked and what schedules will be followed.
>>>
>>> Since Qt 5.6 QtWebKit is in "removed" state and according to [1] it even 
>>> does
>>> not exist, I think it should be to make exceptions in branch and release
>>> management policies for
>>> 5.9 and 5.9.0 branches, solely to resolve situation described above.
>>
>> Actually 'old ' webkit is in our builds but not part of official releases, 
>> see e.g https://testresults.qt.io/coin/integration/qt/qt5/tasks/1494068162
>> That is because we have agreed to keep it working and deliver src packages 
>> for the releases as well. Not part of official release but in addition.
>
> As I said in my other mail, we could easily drop those unsupported packages. 
> Maybe quickly check whether the 5.8 packages compile against Qt 5.9. If they 
> do, there’s no need at all to release packages that are the same, but remove 
> the option of using the new version number for the updated engine.
>>> I propose the following plan:
>>>
>>> 1. Merge wip/next into 5.9.0, 5.9, and dev. 5.9.0 contents will correspond 
>>> to
>>> "alpha" release, that has feature parity, but is not yet guaranteed to be
>>> polished enough.
&g

Re: [Development] QtWebKit is coming back (part 2)

[Konstantin Tokarev]

05.05.2017, 14:15, "Konstantin Tokarev" <annu...@yandex.ru>:
> 05.05.2017, 10:04, "Tuukka Turunen" <tuukka.turu...@qt.io>:
>>  Hi,
>>
>>  There has also been some interest also for getting Qt WebEngine to be 
>> released much faster cycle than Qt – exactly due to the security update 
>> need. Even if we succeed in making substantially more frequent Qt patch 
>> releases than before, it may still be better if user would have the option 
>> to update some parts (like QWE) more frequently or out of sync.
>>
>>  I think what we should consider, is to perhaps carve out Qt WebEngine from 
>> Qt as well. Not immediately, but for Qt 6 we should anyway consider our 
>> current setup of essential and add-on modules. For the html5 engine there is 
>> the matter of binary size in addition to release frequency. This is not to 
>> say that we would stop developing html5 engine – just that it might be 
>> beneficial to do in in different way than currently.
>>
>>  For new updated Qt Webkit, perhaps we could have it as a separate item that 
>> works on top of Qt 5.9 for those to use it who prefer it over Qt WebEngine. 
>> After it has existed for a while as a separate item, it is also easier to 
>> know what would be the best way to get it into a Qt release – or is that 
>> even necessary.
>
> BTW, let me bring an attention to the elephant in the room.
>
> Yes, my fork of QtWebKit existed for a while as a separate item. But it was 
> never
> and "official" successor, and even me myself was warning people that it is 
> not an
> official replacement as some features are not yet restored.
>
> However, now there is no valid reason to keep using QtWebKit contained in 5.9 
> and
> dev branches anymore. Feature parity is achieved to the level of drop-in 
> replacement
> that can be applied system-wide. Still many people see 5.9 branch as a source 
> of truth.
>
> We need to convey a message to wide audience that old QtWebKit should no 
> longer be
> used, and that there is a new release that should be used instead. Not only 
> with Qt 5.9.0,
> but also with older Qt releases, down to Qt 5.2.x if people still use it 
> (e.g., Ubuntu 14.04).
>
> This is why question about version numbers and related stuff is important. If 
> this is not
> done, it doesn't matter at all whatever tag names will be picked and what 
> schedules will
> be followed.

Since Qt 5.6 QtWebKit is in "removed" state and according to [1] it even does 
not exist,
I think it should be to make exceptions in branch and release management 
policies for
5.9 and 5.9.0 branches, solely to resolve situation described above.

I propose the following plan:

1. Merge wip/next into 5.9.0, 5.9, and dev. 5.9.0 contents will correspond to 
"alpha" release,
that has feature parity, but is not yet guaranteed to be polished enough.
2. Host sources and binaries of QtWebKit corresponding to 5.9.0-alpha release at
http://download.qt.io/community_releases/5.9/
3. For dev branch, follow all necessary procedures to change status of QtWebKit 
and make
it work for Qt 5.10 without any schedule exceptions.

[1] http://doc.qt.io/qt-5/qtmodules.html

>
>>  Yours,
>>
>>  Tuukka
>>
>>  On 04/05/2017, 22.26, "Development on behalf of Konstantin Tokarev" 
>> <development-bounces+tuukka.turunen=qt...@qt-project.org on behalf of 
>> annu...@yandex.ru> wrote:
>>
>>  04.05.2017, 19:35, "Oswald Buddenhagen" <oswald.buddenha...@qt.io>:
>>  > On Thu, May 04, 2017 at 04:51:45PM +0300, Konstantin Tokarev wrote:
>>  >> 03.05.2017, 17:27, "Sergio Martins" <sergio.mart...@kdab.com>:
>>  >> > On 2017-05-03 15:02, Konstantin Tokarev wrote:
>>  >> >> Remaining question is versioning. While it's fine to dub current
>>  >> >> release "5.9" (but not 5.0, because we will have another WebKit 
>> update
>>  >> >> in 5.10 time frame), using Qt versions in QtWebKit has downsides:
>>  >> >>
>>  >> >> 1. It is not clear if 5.N+1 ships with the same WebKit branch as 
>> 5.N,
>>  >> >> or is updated
>>  >> >> 2. It makes people believe that QtWebKit 5.N should be used with 
>> Qt
>>  >> >> 5.N only. QtWebKit supports wide range of Qt versions (starting 
>> from
>>  >> >> 5.2 as of now), and can be used e.g. as security update in Linux
>>  >> >> distro that does not normally update Qt version during its life 
>> cycle.
>>  &

Re: [Development] DBus signals for (dlclose'd) style plugin causing crash during application exit?

[Konstantin Tokarev]

07.05.2017, 22:43, "Thiago Macieira" <thiago.macie...@intel.com>:
> On Sunday, 7 May 2017 12:26:02 PDT Konstantin Tokarev wrote:
>>  I'm doing embedded software development, and wouldn't even consider
>>  including emulated builds into my pipeline.
>
> Then if you have a need for QtDBus, you'll maybe step up and help us solve
> this one-year-old issue.

No, I don't use dbus

>
> --
> Thiago Macieira - thiago.macieira (AT) intel.com
>   Software Architect - Intel Open Source Technology Center
>
> ___
> Development mailing list
> Development@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development

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

Re: [Development] DBus signals for (dlclose'd) style plugin causing crash during application exit?

[Konstantin Tokarev]

07.05.2017, 19:24, "Thiago Macieira" :
> On Sunday, 7 May 2017 03:20:26 PDT Ville Voutilainen wrote:
>>  On 6 May 2017 at 22:48, Thiago Macieira  wrote:
>>  > Second, compiling to ARM requires cross-compilation. Since the problem
>>  > happens because of cross-compilation, it happens for all ARM builds.
>>
>>  Perhaps we should get ARM hardware so that we can do ARM builds
>>  without cross-compilation. :)
>
> You can always just do an emulated build (with qemu). This is how most
> distributions build for non-x86, since most software cannot cross-compile.

That's rather strong claim.

I would say that most of open-source software can be cross-compiled, and
distributions use emulation because it's not 100%, and because their tooling
is not adjusted for cross-compilation.

OTOH there are "distributions" focused entirely on cross-compilation, e.g.
Buildroot and Yocto. 

I'm doing embedded software development, and wouldn't even consider
including emulated builds into my pipeline.

>
> --
> Thiago Macieira - thiago.macieira (AT) intel.com
>   Software Architect - Intel Open Source Technology Center
>
> ___
> Development mailing list
> Development@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development

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

Re: [Development] QtWebKit is coming back (part 2)

[Konstantin Tokarev]

05.05.2017, 10:04, "Tuukka Turunen" <tuukka.turu...@qt.io>:
> Hi,
>
> There has also been some interest also for getting Qt WebEngine to be 
> released much faster cycle than Qt – exactly due to the security update need. 
> Even if we succeed in making substantially more frequent Qt patch releases 
> than before, it may still be better if user would have the option to update 
> some parts (like QWE) more frequently or out of sync.
>
> I think what we should consider, is to perhaps carve out Qt WebEngine from Qt 
> as well. Not immediately, but for Qt 6 we should anyway consider our current 
> setup of essential and add-on modules. For the html5 engine there is the 
> matter of binary size in addition to release frequency. This is not to say 
> that we would stop developing html5 engine – just that it might be beneficial 
> to do in in different way than currently.
>
> For new updated Qt Webkit, perhaps we could have it as a separate item that 
> works on top of Qt 5.9 for those to use it who prefer it over Qt WebEngine. 
> After it has existed for a while as a separate item, it is also easier to 
> know what would be the best way to get it into a Qt release – or is that even 
> necessary.

BTW, let me bring an attention to the elephant in the room.

Yes, my fork of QtWebKit existed for a while as a separate item. But it was 
never
and "official" successor, and even me myself was warning people that it is not 
an
official replacement as some features are not yet restored.

However, now there is no valid reason to keep using QtWebKit contained in 5.9 
and
dev branches anymore. Feature parity is achieved to the level of drop-in 
replacement
that can be applied system-wide. Still many people see 5.9 branch as a source 
of truth.

We need to convey a message to wide audience that old QtWebKit should no longer 
be
used, and that there is a new release that should be used instead. Not only 
with Qt 5.9.0,
but also with older Qt releases, down to Qt 5.2.x if people still use it (e.g., 
Ubuntu 14.04).

This is why question about version numbers and related stuff is important. If 
this is not
done, it doesn't matter at all whatever tag names will be picked and what 
schedules will
be followed.

>
> Yours,
>
> Tuukka
>
> On 04/05/2017, 22.26, "Development on behalf of Konstantin Tokarev" 
> <development-bounces+tuukka.turunen=qt...@qt-project.org on behalf of 
> annu...@yandex.ru> wrote:
>
>     04.05.2017, 19:35, "Oswald Buddenhagen" <oswald.buddenha...@qt.io>:
> > On Thu, May 04, 2017 at 04:51:45PM +0300, Konstantin Tokarev wrote:
> >> 03.05.2017, 17:27, "Sergio Martins" <sergio.mart...@kdab.com>:
> >> > On 2017-05-03 15:02, Konstantin Tokarev wrote:
> >> >> Remaining question is versioning. While it's fine to dub current
> >> >> release "5.9" (but not 5.0, because we will have another WebKit 
> update
> >> >> in 5.10 time frame), using Qt versions in QtWebKit has downsides:
> >> >>
> >> >> 1. It is not clear if 5.N+1 ships with the same WebKit branch as 
> 5.N,
> >> >> or is updated
> >> >> 2. It makes people believe that QtWebKit 5.N should be used with Qt
> >> >> 5.N only. QtWebKit supports wide range of Qt versions (starting from
> >> >> 5.2 as of now), and can be used e.g. as security update in Linux
> >> >> distro that does not normally update Qt version during its life 
> cycle.
> >> >>
> >> >> Any comments?
> >> >
> >> > If Qt and QtWebKit will have different release schedules then that
> >> > numbering would indeed confuse people.
> >>
> >> What about choice of new versioning scheme?
> >>
> >> I'm leaning towards "6.0.0" number, because it's larger than any 5.x 
> and makes it
> >> clear that versioning is different now. Bug fixes will increment patch 
> version (6.0.x),
> >> WebKit updates minor version (6.1.x etc), API/ABI breaking changes - 
> major
> >> verison (7.0 etc.)
> >>
> >> Qt5 supermodule will be tracking latest available stable branch. When 
> release branch
> >> is created (e.g. 5.10.0), corresponding patch release branch is 
> created in qtwebkit
> >> repo (e.g., 6.1.1) and is frozen following the same schedule as Qt 
> release branches.
> >>
> >> However, I'm not sure about two things:
> >> 1) Is it possible to have custom branch names in qtwebkit repository, 
> or there need t

Re: [Development] abi breakage for qtwebengine libraries in 5.9

[Konstantin Tokarev]

05.05.2017, 13:29, "Sergio Martins" :
> On 2017-05-05 11:00, Michal Klocek wrote:
>>  Hi
>>
>>  With 5.8.0 we released web engine libs which export operator new ,
>>  new[] , delete, delete[] globally, unfortunately the issue was not
>>  spotted in time.
>>
>>  https://bugreports.qt.io/browse/QTBUG-60565
>>
>>  With 5.9.0 we plan to correct the issue, unfortunately everything which
>>  was compiled against qtwebengine 5.8.0 will be broken when used with
>>  5.9.0 libraries due to missing symbols and needs to be recompiled.
>
> Ouch, this would be a pretty good argument for the 5.8.1 patch release.
> Now we effectively have a Qt minor version that's ABI incompatible with
> all others.
> Too late for that now though.
>
> Can we leverage the CI to prevent these kinds of mistakes ?

There is ABI tracker, maintained by Andrey Ponomarenko, that tracks ABI
changes between Qt releases:

https://abi-laboratory.pro/tracker/timeline/qt/

However, it seems like QtWebEngine is not tracked.

It should be feasible to set up dedicated instance of ABI tracker for Qt CI and
track changes in braches right after (or even before) they are merged.

>
> Regards,
> --
> Sérgio Martins | sergio.mart...@kdab.com | Senior Software Engineer
> Klarälvdalens Datakonsult AB, a KDAB Group company
> Tel: Sweden (HQ) +46-563-540090, USA +1-866-777-KDAB(5322)
> KDAB - The Qt, C++ and OpenGL Experts
> ___
> Development mailing list
> Development@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development

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

Re: [Development] QtWebKit is coming back (part 2)

[Konstantin Tokarev]

05.05.2017, 10:04, "Tuukka Turunen" <tuukka.turu...@qt.io>:
> Hi,
>
> There has also been some interest also for getting Qt WebEngine to be 
> released much faster cycle than Qt – exactly due to the security update need. 
> Even if we succeed in making substantially more frequent Qt patch releases 
> than before, it may still be better if user would have the option to update 
> some parts (like QWE) more frequently or out of sync.
>
> I think what we should consider, is to perhaps carve out Qt WebEngine from Qt 
> as well. Not immediately, but for Qt 6 we should anyway consider our current 
> setup of essential and add-on modules. For the html5 engine there is the 
> matter of binary size in addition to release frequency. This is not to say 
> that we would stop developing html5 engine – just that it might be beneficial 
> to do in in different way than currently.
>
> For new updated Qt Webkit, perhaps we could have it as a separate item that 
> works on top of Qt 5.9 for those to use it who prefer it over Qt WebEngine. 
> After it has existed for a while as a separate item, it is also easier to 
> know what would be the best way to get it into a Qt release – or is that even 
> necessary.

Note that qttools submodule depends on QtWebKit (for proper HTML rendering in 
Qt Assistant). Also, QtWebEngine is require for QtWebView module on 
Windows/MSVC. BTW, currently QtWebView is unavailable for Windows/MinGW, so it 
would make sense to add QtWebKit backend as well.

That's one reason why we cannot just exclude QtWebKit and QtWebEngine from qt5 
supermodule. Other reason is that Coin doesn't seem to be ready to support 
building projects other than qt5 and its submodules. 

>
> Yours,
>
> Tuukka
>
> On 04/05/2017, 22.26, "Development on behalf of Konstantin Tokarev" 
> <development-bounces+tuukka.turunen=qt...@qt-project.org on behalf of 
> annu...@yandex.ru> wrote:
>
> 04.05.2017, 19:35, "Oswald Buddenhagen" <oswald.buddenha...@qt.io>:
> > On Thu, May 04, 2017 at 04:51:45PM +0300, Konstantin Tokarev wrote:
> >> 03.05.2017, 17:27, "Sergio Martins" <sergio.mart...@kdab.com>:
> >> > On 2017-05-03 15:02, Konstantin Tokarev wrote:
> >> >> Remaining question is versioning. While it's fine to dub current
> >> >> release "5.9" (but not 5.0, because we will have another WebKit 
> update
> >> >> in 5.10 time frame), using Qt versions in QtWebKit has downsides:
> >> >>
> >> >> 1. It is not clear if 5.N+1 ships with the same WebKit branch as 
> 5.N,
> >> >> or is updated
> >> >> 2. It makes people believe that QtWebKit 5.N should be used with Qt
> >> >> 5.N only. QtWebKit supports wide range of Qt versions (starting from
> >> >> 5.2 as of now), and can be used e.g. as security update in Linux
> >> >> distro that does not normally update Qt version during its life 
> cycle.
> >> >>
> >> >> Any comments?
> >> >
> >> > If Qt and QtWebKit will have different release schedules then that
> >> > numbering would indeed confuse people.
> >>
> >> What about choice of new versioning scheme?
> >>
> >> I'm leaning towards "6.0.0" number, because it's larger than any 5.x 
> and makes it
> >> clear that versioning is different now. Bug fixes will increment patch 
> version (6.0.x),
> >> WebKit updates minor version (6.1.x etc), API/ABI breaking changes - 
> major
> >> verison (7.0 etc.)
> >>
> >> Qt5 supermodule will be tracking latest available stable branch. When 
> release branch
> >> is created (e.g. 5.10.0), corresponding patch release branch is 
> created in qtwebkit
> >> repo (e.g., 6.1.1) and is frozen following the same schedule as Qt 
> release branches.
> >>
> >> However, I'm not sure about two things:
> >> 1) Is it possible to have custom branch names in qtwebkit repository, 
> or there need to
> >> be virtual 5.10 etc. branches to match other modules?
> >> 2) What about bug tracking in JIRA? I would like to keep existing 
> issues as is, but assing
> >> new release numbers to items fixed in new releases
> >
> > i'll say outright that you can't be part of the qt supermodule and yet
> > have independent releases. while that was the plan once upon a time, the
> > whole release infrastructure simply doesn't deliver, and even just
>

Re: [Development] Coin: using 64-bit Windows host for 32-bit builds

[Konstantin Tokarev]

05.05.2017, 01:11, "Thiago Macieira" <thiago.macie...@intel.com>:
> Em quinta-feira, 4 de maio de 2017, às 14:22:55 PDT, Konstantin Tokarev
> escreveu:
>>  Unfortunately, VS is the worst offender at the moment, it does not have
>>  anything like -g1, or like -g0 (i.e. option to negate previously added /Zi)
>
> IIRC, the 32-bit linker is a 32-bit application too if you use "vcvarsall
> x86".
>
> You need a cross-compilation setup, like "vcvarsall x64_x86".

Yes, use 64-bit tools while compiling for 32-bit target. That requires 64-bit OS
image to start with.

>
> --
> Thiago Macieira - thiago.macieira (AT) intel.com
>   Software Architect - Intel Open Source Technology Center
>
> ___
> Development mailing list
> Development@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development

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

Re: [Development] Coin: using 64-bit Windows host for 32-bit builds

[Konstantin Tokarev]

05.05.2017, 00:01, "Kevin Kofler" <kevin.kof...@chello.at>:
> Konstantin Tokarev wrote:
>>  It is needed because large projects, namely QtWebEngine and QtWebKit
>>  (wip/next branch) are too large for making 32-bit debug builds on 32-bit
>>  OS. In case of QtWebKit it's possbile to work around this problem by
>>  issuing debug info for API implementation only, however this reduces
>>  debuggability.
>
> In Fedora, we use this to build at least SOME debugging information (-g1
> level rather than the default -g which exhausts the address space) for
> QtWebEngine on 32-bit architectures:
> http://pkgs.fedoraproject.org/cgit/rpms/qt5-qtwebengine.git/tree/qt5-qtwebengine.spec#n374
> http://pkgs.fedoraproject.org/cgit/rpms/qt5-qtwebengine.git/tree/qt5-qtwebengine.spec#n395
>
> (Also note that we build with
> CONFIG+="webcore_debug v8base_debug force_debug_info"
> or we would not be getting complete debugging information anywhere.)
>
> The -g1 trick is probably also workable for QtWebKit if it is hitting the
> same issue on any GCC target (including MinGW). But I don't know whether
> Visual C++ has anything comparable.

Unfortunately, VS is the worst offender at the moment, it does not have 
anything like -g1,
or like -g0 (i.e. option to negate previously added /Zi)

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

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

Re: [Development] QtWebKit is coming back (part 2)

[Konstantin Tokarev]

04.05.2017, 19:35, "Oswald Buddenhagen" <oswald.buddenha...@qt.io>:
> On Thu, May 04, 2017 at 04:51:45PM +0300, Konstantin Tokarev wrote:
>>  03.05.2017, 17:27, "Sergio Martins" <sergio.mart...@kdab.com>:
>>  > On 2017-05-03 15:02, Konstantin Tokarev wrote:
>>  >>  Remaining question is versioning. While it's fine to dub current
>>  >>  release "5.9" (but not 5.0, because we will have another WebKit update
>>  >>  in 5.10 time frame), using Qt versions in QtWebKit has downsides:
>>  >>
>>  >>  1. It is not clear if 5.N+1 ships with the same WebKit branch as 5.N,
>>  >>  or is updated
>>  >>  2. It makes people believe that QtWebKit 5.N should be used with Qt
>>  >>  5.N only. QtWebKit supports wide range of Qt versions (starting from
>>  >>  5.2 as of now), and can be used e.g. as security update in Linux
>>  >>  distro that does not normally update Qt version during its life cycle.
>>  >>
>>  >>  Any comments?
>>  >
>>  > If Qt and QtWebKit will have different release schedules then that
>>  > numbering would indeed confuse people.
>>
>>  What about choice of new versioning scheme?
>>
>>  I'm leaning towards "6.0.0" number, because it's larger than any 5.x and 
>> makes it
>>  clear that versioning is different now. Bug fixes will increment patch 
>> version (6.0.x),
>>  WebKit updates minor version (6.1.x etc), API/ABI breaking changes - major
>>  verison (7.0 etc.)
>>
>>  Qt5 supermodule will be tracking latest available stable branch. When 
>> release branch
>>  is created (e.g. 5.10.0), corresponding patch release branch is created in 
>> qtwebkit
>>  repo (e.g., 6.1.1) and is frozen following the same schedule as Qt release 
>> branches.
>>
>>  However, I'm not sure about two things:
>>  1) Is it possible to have custom branch names in qtwebkit repository, or 
>> there need to
>>  be virtual 5.10 etc. branches to match other modules?
>>  2) What about bug tracking in JIRA? I would like to keep existing issues as 
>> is, but assing
>>  new release numbers to items fixed in new releases
>
> i'll say outright that you can't be part of the qt supermodule and yet
> have independent releases. while that was the plan once upon a time, the
> whole release infrastructure simply doesn't deliver, and even just
> diverging branch names are a pita (proved by enginio). as a product, qt
> is as monolithic as ever.

Understood: no custom branch/tag names in official repo.

>
> your release cycle concerns seem to be centered around the webkit
> backend, and you can deal with that by lowering the compatibility
> guarantees of patch releases at this level, i.e. take the freedom to
> upgrade webkit in a patch release. as long as you keep qt's api/abi
> compat promises, you're fine. that means that you will not be able to
> expose new webkit features until the next minor release if they require
> new api.

That's probably fine with me, except 2 moments that seem to require "out of 
band" releases:

1. Something should be done with current release. As I said, it's not an option 
to postpone
it to 5.10, however it also cannot be released as 5.9.1 because there are API 
additions
which I don't want to revert (in particular because these APIs were already 
shipped by
Linux distros that chose to provide TP4 and TP5). Also there is a change in 
QDataStream
format of QWebHistory.

2. Security updates. WebKitGTK team provides several patch releases for each 
stable branch,
which contain only fixes for bugs and security issues, and towards the end of 
release life cycle
they became primarily security updates. I think we should be able to release 
such updates ASAP,
by making up some tag name and scheduling custom build against newest patch 
release of Qt.

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

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

Re: [Development] DBus signals for (dlclose'd) style plugin causing crash during application exit?

[Konstantin Tokarev]

04.05.2017, 21:07, "René J. V. Bertin" :
> Thiago Macieira wrote:
>
>>  I think our ARM builds are little-endian, so endianness cannot be an issue.
>>
>>  The problem happens before any ARM code is run, so it's not an emulation or
>>  processor issue. It must be a cross-compilation (bootstrapping) issue.
>
> So it cannot be something that has to do with a host application connecting 
> to a
> dbus daemon running off ARM code? A communications glitch would be the 
> simplest
> reason for a timeout in IPC context, in this case presumably when 
> disconnecting
> from a DBus daemon.
>
> Something else: a standard llvm/clang install will generate code for ARM on
> demand without need to install a dedicated cross-compiler.

...except that you need target-specific binutils, glibc, kernel headers...

> Maybe worth checking
> if the same issue arises with clang (on a CI system or a developer 
> workstation)?
>
> R
>
> ___
> Development mailing list
> Development@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development

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

[Development] Coin: using 64-bit Windows host for 32-bit builds

[Konstantin Tokarev]

Hello,

I was told that there is some ongoing work to make subject possible.
What is the current status?

It is needed because large projects, namely QtWebEngine and QtWebKit
(wip/next branch) are too large for making 32-bit debug builds on 32-bit OS.
In case of QtWebKit it's possbile to work around this problem by issuing
debug info for API implementation only, however this reduces debuggability.

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

Re: [Development] QtWebKit is coming back (part 2)

[Konstantin Tokarev]

04.05.2017, 17:17, "Thiago Macieira" <thiago.macie...@intel.com>:
> Em quinta-feira, 4 de maio de 2017, às 06:51:45 PDT, Konstantin Tokarev
> escreveu:
>>  I'm leaning towards "6.0.0" number, because it's larger than any 5.x and
>>  makes it clear that versioning is different now. Bug fixes will increment
>>  patch version (6.0.x), WebKit updates minor version (6.1.x etc), API/ABI
>>  breaking changes - major verison (7.0 etc.)
>
> I thought you weren't breaking either source or binary compatibility.

Correct.

> So using a new major number sounds wrong.

Yes. But using 5.$large_number seems wrong too, because there is no hard
upper limit for Qt 5.x series

>
> And what would you do when Qt 6 gets released in a couple of years?

There will be QtWebKit 7.x by then, because there are some desirable changes
that would break ABI. There is no clear plan yet, though.

>
> --
> Thiago Macieira - thiago.macieira (AT) intel.com
>   Software Architect - Intel Open Source Technology Center
>
> ___
> Development mailing list
> Development@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development

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

Re: [Development] Proposal for Qt 5.10 platforms and configurations changes - SUMMARY

[Konstantin Tokarev]

04.05.2017, 16:53, "Thiago Macieira" :
> Em quinta-feira, 4 de maio de 2017, às 00:23:46 PDT, Heikki Halmet escreveu:
>>  Clang 4: Do we really need this to be tested with Linux in CI? If yes, then
>>  which configuration it will be replaced?
>
> I don't think we need to. The macOS builds should be sufficient for almost
> everything intrinsic to Clang. Those of us who test it on Linux will submit
> fixes as needed.

But we could have Linux clang configuration with clazy plugin.

>
> --
> Thiago Macieira - thiago.macieira (AT) intel.com
>   Software Architect - Intel Open Source Technology Center
>
> ___
> Development mailing list
> Development@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development

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

Re: [Development] QtWebKit is coming back (part 2)

[Konstantin Tokarev]

04.05.2017, 16:52, "Thiago Macieira" :
> Em quinta-feira, 4 de maio de 2017, às 00:17:30 PDT, Jani Heikkinen escreveu:
>>  > I hope for this (if possible, in 5.9 with Technology preview status
>>
>>  I don't think adding new TP in 5.9 at this point isn't that wise anymore. We
>>  have agreed to get all these new submodules (also TP ones) in before FF and
>>  so on 5.10 is first option.
>
> Fair enough, but QtWebKit can release a TP a little afterwards and just say
> it's compatible with Qt 5.9.

Will it be possbile to get binary packages into repositories of online SDK 
updater?

>
> --
> Thiago Macieira - thiago.macieira (AT) intel.com
>   Software Architect - Intel Open Source Technology Center
>
> ___
> Development mailing list
> Development@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development

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

Re: [Development] QtWebKit is coming back (part 2)

[Konstantin Tokarev]

03.05.2017, 17:27, "Sergio Martins" <sergio.mart...@kdab.com>:
> On 2017-05-03 15:02, Konstantin Tokarev wrote:
>>  Remaining question is versioning. While it's fine to dub current
>>  release "5.9" (but not 5.0, because we will have another WebKit update
>>  in 5.10 time frame), using Qt versions in QtWebKit has downsides:
>>
>>  1. It is not clear if 5.N+1 ships with the same WebKit branch as 5.N,
>>  or is updated
>>  2. It makes people believe that QtWebKit 5.N should be used with Qt
>>  5.N only. QtWebKit supports wide range of Qt versions (starting from
>>  5.2 as of now), and can be used e.g. as security update in Linux
>>  distro that does not normally update Qt version during its life cycle.
>>
>>  Any comments?
>
> If Qt and QtWebKit will have different release schedules then that
> numbering would indeed confuse people.

What about choice of new versioning scheme?

I'm leaning towards "6.0.0" number, because it's larger than any 5.x and makes 
it
clear that versioning is different now. Bug fixes will increment patch version 
(6.0.x),
WebKit updates minor version (6.1.x etc), API/ABI breaking changes - major
verison (7.0 etc.)

Qt5 supermodule will be tracking latest available stable branch. When release 
branch
is created (e.g. 5.10.0), corresponding patch release branch is created in 
qtwebkit
repo (e.g., 6.1.1) and is frozen following the same schedule as Qt release 
branches.

However, I'm not sure about two things:
1) Is it possible to have custom branch names in qtwebkit repository, or there 
need to
be virtual 5.10 etc. branches to match other modules?
2) What about bug tracking in JIRA? I would like to keep existing issues as is, 
but assing
new release numbers to items fixed in new releases



Rationale why using Qt version is not optimal anymore:

1. New QtWebKit is using stable branch of WebKitGTK to simplify maintenance, and
plan is to continue doing this in future. Currenly WebKitGTK creates new stable 
branch
twice a year and follows GNOME release schedule. While this more or less matches
Qt release schedule, there may be unfortunate cases when schedules mismatch, and
WebKit upgrade won't be possible in time. Keeping WebKit not upgraded increases
maintenance burden, because it's harder to cherry-pick patches from diverging 
trunk,
and it's not possible anymore to reuse backporting work of WebKitGTK team.

In case WebKit upgrade is finished before Qt release, it's highly desirable to 
allow
downstreams (e.g. Linux distros) to get newer version faster.

In case WebKit upgrade was skipped for some reason when new Qt release is
made, it's important to reflect this in version number as well

2. There may be schedule missses because of lacking man power in QtWebKit team.
Like now for example, release is long overdue and it's just unacceptable to 
hold it
for more than half of year again.

3. As I already mentioned in the starting message, surprisingly large number of 
people
believe that QtWebKit x.y is tied to Qt x.y, while it supports a range of Qt 
versions,
and can be used as security update in Linux distros that do not normally update 
Qt
version during their release life cycle.

Historically, QtWebKit always supported at least N-1 release of Qt, and 
versioning
scheme used in Qt 4 times since Qt 4.7 (QtWebKit 2.0 - 2.3) better reflected 
this fact.


>
> Have you thought about an LTS version too ? What would LTS mean, for
> QtWebKit ? I think during the LTS lifetime we would still need to update
> the inner WebKit, for security reasons, (that even happened for
> QtWebEngine in a 5.6.x patch release).
>
> Thanks for your efforts on this!
>
> Regards,
> --
> Sérgio Martins | sergio.mart...@kdab.com | Senior Software Engineer
> Klarälvdalens Datakonsult AB, a KDAB Group company
> Tel: Sweden (HQ) +46-563-540090, USA +1-866-777-KDAB(5322)
> KDAB - The Qt, C++ and OpenGL Experts

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

Re: [Development] QtWebKit is coming back (part 2)

[Konstantin Tokarev]

03.05.2017, 21:25, "Thiago Macieira" <thiago.macie...@intel.com>:
> Em quarta-feira, 3 de maio de 2017, às 10:55:49 PDT, Konstantin Tokarev
> escreveu:
>>  So, do you think we should update 5.6 branch of QtWebKit with wip/next
>>  contents, fix qmake wrapper project to work with Qt 5.6, and raise
>>  requirements to whatever it can require with Qt 5.9? That's fine with me.
>
> No, you should make a different LTS release that works with Qt 5.6.

OK

>
> --
> Thiago Macieira - thiago.macieira (AT) intel.com
>   Software Architect - Intel Open Source Technology Center
>
> ___
> Development mailing list
> Development@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development

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

Re: [Development] QtWebKit is coming back (part 2)

[Konstantin Tokarev]

03.05.2017, 20:44, "Thiago Macieira" <thiago.macie...@intel.com>:
> Em quarta-feira, 3 de maio de 2017, às 08:03:50 PDT, Konstantin Tokarev
> escreveu:
>>  I'm not sure it would be acceptable, because updated QtWebKit requires full
>>  C++11 support in the compiler (gcc >= 4.9, 4.8 possible with disabling some
>>  features, or with code changes, which were not done yet).
>>
>>  Also, there are differences in supported platforms and system requirements.
>>
>>  macOS: One user reported that QtWebKit TP5 built for OS X 10.9 target is
>>  working fine on OS X 10.7, however the oldest officially supported version
>>  is 10.10 (as in upstream). I'm pretty sure that WK2 IPC with Mach ports
>>  will break when compiling for older targets, though it should be possible
>>  to switch to unix sockets just for 5.6.
>>
>>  Windows: Windows XP support seems to be feasible, if needed, without new
>>  MediaFoundation-based player. Will require backporting Conan-related patches
>>  in qt5.git to 5.6 branch.
>>
>>  Linux: GStreamer 0.10 is not supported, so official builds with video will
>>  have to use QtMultimedia MediaPlayer implementation.
>>
>>  I'm not sure about QNX support in QtWebKit 5.6, it is skipped in CI now
>>  because of missing ICU. However, I guess it will be possible to reintroduce
>>  QNX support if there are interested folks here, at least Widgets API.
>
> None of those look like deal-breakers. You should be able to:
>  * require C++11 [*] and require newer compilers than 5.6 does
>  * drop support for older platforms (XP, macOS < 10.9, etc.)
>  * require upgraded libraries, like GStreamer
>
> Especially if you're going to do releases out of phase with Qt, it should be
> fine to require more than 5.6 did. And people should just accept it: if you're
> dealing with something that evolves rapidly and is a security-sensitive, you
> should be prepared to upgrade your environment quickly too.
>
> [*] actually, we should remove the option from configure.

So, do you think we should update 5.6 branch of QtWebKit with wip/next contents,
fix qmake wrapper project to work with Qt 5.6, and raise requirements to 
whatever it
can require with Qt 5.9? That's fine with me.

>
> --
> Thiago Macieira - thiago.macieira (AT) intel.com
>   Software Architect - Intel Open Source Technology Center
>
> ___
> Development mailing list
> Development@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development

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

Re: [Development] QtWebKit is coming back (part 2)

[Konstantin Tokarev]

03.05.2017, 18:05, "Adalid Claure" <acla...@gmail.com>:
> Does this mean that at some point this new QtWebKit would be packaged with Qt 
> (like in the old days)?

I hope for this (if possible, in 5.9 with Technology preview status ;)

Also note that you can already get binaries compatible with Qt 5.8.0 from

https://github.com/annulen/webkit/releases/tag/qtwebkit-tp5

(but note that TP5 does not include QML API yet)

They are built in Coin just like official binaries packaged in Qt SDK.

>
> On Wed, May 3, 2017 at 10:25 AM, Sergio Martins <sergio.mart...@kdab.com> 
> wrote:
>> On 2017-05-03 15:02, Konstantin Tokarev wrote:
>> Remaining question is versioning. While it's fine to dub current
>> release "5.9" (but not 5.0, because we will have another WebKit update
>> in 5.10 time frame), using Qt versions in QtWebKit has downsides:
>>
>> 1. It is not clear if 5.N+1 ships with the same WebKit branch as 5.N,
>> or is updated
>> 2. It makes people believe that QtWebKit 5.N should be used with Qt
>> 5.N only. QtWebKit supports wide range of Qt versions (starting from
>> 5.2 as of now), and can be used e.g. as security update in Linux
>> distro that does not normally update Qt version during its life cycle.
>>
>> Any comments?
>>
>> If Qt and QtWebKit will have different release schedules then that numbering 
>> would indeed confuse people.
>>
>> Have you thought about an LTS version too ? What would LTS mean, for 
>> QtWebKit ? I think during the LTS lifetime we would still need to update the 
>> inner WebKit, for security reasons, (that even happened for QtWebEngine in a 
>> 5.6.x patch release).
>>
>> Thanks for your efforts on this!
>>
>> Regards,
>> --
>> Sérgio Martins | sergio.mart...@kdab.com | Senior Software Engineer
>> Klarälvdalens Datakonsult AB, a KDAB Group company
>> Tel: Sweden (HQ) +46-563-540090, USA +1-866-777-KDAB(5322)
>> KDAB - The Qt, C++ and OpenGL Experts
>>
>> ___
>> Development mailing list
>> Development@qt-project.org
>> http://lists.qt-project.org/mailman/listinfo/development
> ,
>
> ___
> Development mailing list
> Development@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development


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

Re: [Development] QtWebKit is coming back (part 2)

[Konstantin Tokarev]

03.05.2017, 17:27, "Sergio Martins" <sergio.mart...@kdab.com>:
> On 2017-05-03 15:02, Konstantin Tokarev wrote:
>>  Remaining question is versioning. While it's fine to dub current
>>  release "5.9" (but not 5.0, because we will have another WebKit update
>>  in 5.10 time frame), using Qt versions in QtWebKit has downsides:
>>
>>  1. It is not clear if 5.N+1 ships with the same WebKit branch as 5.N,
>>  or is updated
>>  2. It makes people believe that QtWebKit 5.N should be used with Qt
>>  5.N only. QtWebKit supports wide range of Qt versions (starting from
>>  5.2 as of now), and can be used e.g. as security update in Linux
>>  distro that does not normally update Qt version during its life cycle.
>>
>>  Any comments?
>
> If Qt and QtWebKit will have different release schedules then that
> numbering would indeed confuse people.
>
> Have you thought about an LTS version too ? What would LTS mean, for
> QtWebKit ? I think during the LTS lifetime we would still need to update
> the inner WebKit, for security reasons, (that even happened for
> QtWebEngine in a 5.6.x patch release).

I'm not sure it would be acceptable, because updated QtWebKit requires full
C++11 support in the compiler (gcc >= 4.9, 4.8 possible with disabling some
features, or with code changes, which were not done yet).

Also, there are differences in supported platforms and system requirements.

macOS: One user reported that QtWebKit TP5 built for OS X 10.9 target is 
working fine
on OS X 10.7, however the oldest officially supported version is 10.10 (as in 
upstream).
I'm pretty sure that WK2 IPC with Mach ports will break when compiling for 
older targets,
though it should be possible to switch to unix sockets just for 5.6.

Windows: Windows XP support seems to be feasible, if needed, without new
MediaFoundation-based player. Will require backporting Conan-related patches in
qt5.git to 5.6 branch.

Linux: GStreamer 0.10 is not supported, so official builds with video will have 
to use
QtMultimedia MediaPlayer implementation.

I'm not sure about QNX support in QtWebKit 5.6, it is skipped in CI now because 
of
missing ICU. However, I guess it will be possible to reintroduce QNX support if 
there are
interested folks here, at least Widgets API.

All platforms will need to have cmake >= 2.8.12, this might reduce testing 
coverage for
older cmake versions in 5.6

>
> Thanks for your efforts on this!
>
> Regards,
> --
> Sérgio Martins | sergio.mart...@kdab.com | Senior Software Engineer
> Klarälvdalens Datakonsult AB, a KDAB Group company
> Tel: Sweden (HQ) +46-563-540090, USA +1-866-777-KDAB(5322)
> KDAB - The Qt, C++ and OpenGL Experts

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

[Development] QtWebKit is coming back (part 2)

[Konstantin Tokarev]

Hi all,

A lot of time has passed since original thread [1]. Lots of work was done since 
then, and it took much more time than what I've originally planned, however I 
think now we can use updated QtWebKit as a full replacement of our previous 
branch that didn't have updates of WebKit engine since Qt 5.2.

You can find results of this work in wip/next branch of our QtWebKit repository 
[2] that is checked by Coin on desktop Linux, macOS, and Windows (both MSVC and 
MinGW) configurations.

QtWebKit Technology Preview 5 [3], based on this branch, is already packaged by 
Arch Linux [4] and MSYS2 [5], while KaOS Linux distribution ships it as a 
replacement for old QtWebKit package [6]. It also has had extensive testing by 
developers and users of such open source projects as PhantomJS [7], Otter 
Browser [8], Qutebrowser [9]. Lots of bugs were discovered and fixed in the 
process, a few are not fixed yet but there are no real showstoppers.

Major concern, rased in the previous discussion, was feature parity. You can 
see current status at [10], all major gaps were filled, including support for 
QML API (WebKit 2) on Windows that was causing concerns previously (it isn't 
merged to wip/next yet, but works here). There are still a few missing features 
in QML API, but they affect undocumented experimental part of the API.

I propose we should replace contents of dev branch with wip/next as soon as 
WebKit2/Windows patches are landed. I also think it would be better to release 
it alongside with Qt 5.9 instead of current 5.9 branch contents to stop 
proliferation of old insecure WebKit version. I understand that it does not fit 
into existing schedule of Qt 5.9, however in the previous discussion Lars 
supported the idea of having independent schedule for QtWebKit

Remaining question is versioning. While it's fine to dub current release "5.9" 
(but not 5.0, because we will have another WebKit update in 5.10 time frame), 
using Qt versions in QtWebKit has downsides:

1. It is not clear if 5.N+1 ships with the same WebKit branch as 5.N, or is 
updated
2. It makes people believe that QtWebKit 5.N should be used with Qt 5.N only. 
QtWebKit supports wide range of Qt versions (starting from 5.2 as of now), and 
can be used e.g. as security update in Linux distro that does not normally 
update Qt version during its life cycle.

Any comments?

--

[1] http://lists.qt-project.org/pipermail/development/2016-June/026156.html
[2] https://code.qt.io/qt/qtwebkit.git; it contains snapshots from 
https://github.com/annulen/webkit with unnecessary files excluded
[3] https://github.com/annulen/webkit/releases/tag/qtwebkit-tp5
[4] https://www.archlinux.org/packages/extra/x86_64/qt5-webkit-ng/
 https://www.archlinux.org/packages/extra/i686/qt5-webkit-ng/
[5] 
http://repo.msys2.org/mingw/x86_64/mingw-w64-x86_64-qtwebkit-tp5-4-any.pkg.tar.xz
 
http://repo.msys2.org/mingw/i686/mingw-w64-i686-qtwebkit-tp5-4-any.pkg.tar.xz
[6] 
http://kaosx.tk/packages/index.php?act=show=main=date=qtwebkit-tp-5.6.2.3-3-x86_64.pkg.tar.xz
[7] http://phantomjs.org/
[8] http://otter-browser.org/
[9] http://qutebrowser.org/
[10] https://github.com/annulen/webkit/wiki/Comparison-with-QtWebKit-5.6

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

Re: [Development] Setting CMAKE_PREFIX_PATH to Qt prefix breaks use of system ICU via CMake

[Konstantin Tokarev]

29.04.2017, 23:18, "Thiago Macieira" <thiago.macie...@intel.com>:
> On Saturday, 29 April 2017 06:22:20 -03 Konstantin Tokarev wrote:
>>  > Out of scope and you should be using qmake.
>>
>>  I understand your point, but it seems impractical to provide wrapper qmake
>>  project as an interface for packagers. They know know how to deal with
>>  qmake or cmake packages, but dealing with cmake wrapped with qmake is a
>>  totally different business, and can easily double amount of issues to
>>  solve, especially when cross-compiling. That said, it works fine in Coin.
>
> My point is that there should be no cmake involved at all. The qtwebkit build
> has worked with qmake for 10 years, why should it stop now?

It's getting to the side way from the original topic, but let me tell you the 
story of
WebKit build systems.

When Apple opened WebKit source, initially it had only build system based on
Xcode projects. Of course it didn't work for others, and every WebKit port 
started
to maintain own build system. Qt port, of course, used qmake. GTK port initially
used qmake as well to avoid duplicating work, but later switched to autotools.
Windows ports (AppleWin and WinCairo) used VS project files. wxWidgets port
used waf. Google used gyp for Chromium and makefiles for Android (that was a
separate port that time).

EFL port used CMake, but later other ports, namely Blackberry and WinCE, also
used its build system. Shared build system that could work for different WebKit
ports was born.

Time passed, several ports ceased their existence. In 2013 GTK port decided to
switch from autotools to this shared CMake build system. AppleWin and WinCairo
also switched. Apple maintains CMake build for Mac port as well, AFAIK it is not
used for production builds but provides faster build times, so they are 
evaluating if
they can do full switch in the future.

So, current state of WebKit build systems is:
* All active ports except iOS have cmake as the only build option, or at least 
as
one of the options (Mac)
* CMake is likely the only build system that could be accepted in case Qt port 
would
ever return to trunk, or any other new port 
* Port-independent improvements to CMake build that benefit Qt port are accepted
(and reviewed) by upstream.

>
>>  Maintaining old qmake-based build was not considered because I don't have
>>  resources to maintain a build system that duplicate's one maintained by
>>  upstream. If there are volunteers to do that I can reconsider, but note
>>  that you will have to deal with lots of custom code generators, that are
>>  changed over time, and it would be much harder to backport upsream patches
>>  (that already include necessary cmake changes)
>
> Was the one that used to exist removed?

Yes. After 3 years of being not updated, it would require a ton of changes and
debugging to work with new WebKit. Changed file lists (that are always in flux) 
is
only part of the probem. Other part is figuring out how code generation is 
done, that
would require analysis of cmake code and reimplementing it with qmake. WebKit 
has
lots of different code generators with lots of peculiarities, that resulted in 
very arcane
qmake code in the past. And my name is not Ossi, I'm just a mere mortal with 
very
limited magic abilities :)

Switching to CMake from the start allowed me to get things building very fast, 
without
even knowing all gory details. I would estimate net result of build system 
switch for
now as neutral, because a lot of work was required to make it working in Coin 
and to
restore installation layouts provided by qmake for free. However, I expect next 
updates
of WebKit engine mostly flawless on build system side, as Qt-specific parts 
won't need
huge modifications anymore, and port-independent changes will come from upstream
directly.

Bonus: in case of weird build issues like [1] I can now just backport necessary 
cmake
incantation instead of figuring everything myself.

[1] https://bugs.webkit.org/show_bug.cgi?id=161697

>
>>  As a side effect, having cmake build that is usable as a public build
>>  interface helps with IDE integration, e.g. I'm using existing cmake support
>>  in Qt Creator for development.
>
> And the existing qmake support in Qt Creator did not work?

It would work, if there was something to work with.

>
>>  >> * Remove unversioned symlinks like libicuuc.so from SDK, so that they
>>  >> are not found by FindICU.cmake, and also by linker if it's given -licuuc
>>  >
>>  > That seems like the right solution for me. If we're not supplying the
>>  > headers (and it's not our business to), then we shouldn't supply the *.so
>>  > symlinks either.
>>
>>  Fine with me. Looks like the problem is that archive [1] contains only
>>  necessary files, but [2] 

Re: [Development] Setting CMAKE_PREFIX_PATH to Qt prefix breaks use of system ICU via CMake

[Konstantin Tokarev]

28.04.2017, 18:58, "Thiago Macieira" <thiago.macie...@intel.com>:
> On Friday, 28 April 2017 11:54:53 -03 Konstantin Tokarev wrote:
>>  Hello,
>>
>>  There is a strange situation involving official Qt SDK (>=5.8.0) binaries
>>  for Linux, ICU, cmake, and WebKit project files, I'm not sure which side
>>  really needs to be fixed.
>>
>>  (Qt)WebKit uses custom module to find ICU, you can see its code at [1].
>>  Module uses quite popular practise of invoking pkg-config first, and then
>>  performing search of libs and headers by passing them as HINTS to
>>  find_path() and find_library(). Doing so allows to have a meaningful
>>  fallback if pkg-config is missing, misconfigured, or e.g. returns host libs
>>  when cross-compilation is needed.
>
> qtwebkit is built using qmake, so any CMake modules are irrelevant at this
> point. CMake is only used for building user applications.
>
>>  There are a few possible solutions:
>>
>>  * Provide ICU headers as a part of Qt SDK too. This has a benefit that ICU
>>  libraries, required for QtCore, can be reused in other projects that use Qt
>>  and ICU, e.g. for building of experimental QtWebKit versions against binary
>>  SDK.
>
> Out of scope and you should be using qmake.

I understand your point, but it seems impractical to provide wrapper qmake 
project
as an interface for packagers. They know know how to deal with qmake or cmake
packages, but dealing with cmake wrapped with qmake is a totally different 
business,
and can easily double amount of issues to solve, especially when 
cross-compiling.
That said, it works fine in Coin.

Maintaining old qmake-based build was not considered because I don't have
resources to maintain a build system that duplicate's one maintained by 
upstream.
If there are volunteers to do that I can reconsider, but note that you will 
have to deal
with lots of custom code generators, that are changed over time, and it would be
much harder to backport upsream patches (that already include necessary cmake
changes)

As a side effect, having cmake build that is usable as a public build interface 
helps
with IDE integration, e.g. I'm using existing cmake support in Qt Creator for 
development.

>
>>  * Remove unversioned symlinks like libicuuc.so from SDK, so that they
>>  are not found by FindICU.cmake, and also by linker if it's given -licuuc
>
> That seems like the right solution for me. If we're not supplying the headers
> (and it's not our business to), then we shouldn't supply the *.so symlinks
> either.

Fine with me. Looks like the problem is that archive [1] contains only 
necessary files,
but [2] contains all ICU libraries + unversioned links. Archive [2] is unpacked 
into
SDK image since 5.8.0.

[1] 
http://download.qt.io/development_releases/prebuilt/icu/prebuilt/56.1/icu-linux-g++-Rhel6.6-x64.7z

Files:

Extracting  libicudata.so.56
Extracting  libicui18n.so.56
Extracting  libicuuc.so.56
Extracting  libicudata.so.56.1
Extracting  libicui18n.so.56.1
Extracting  libicuuc.so.56.1

[2] 
http://download.qt.io/development_releases/prebuilt/icu/prebuilt/56.1/icu-linux-g++-Rhel7.2-x64.7z

Files:

Extracting  libicudata.so
Extracting  libicui18n.so
Extracting  libicuio.so
Extracting  libicule.so
Extracting  libiculx.so
Extracting  libicutest.so
Extracting  libicutu.so
Extracting  libicuuc.so
Extracting  libicudata.so.56
Extracting  libicui18n.so.56
Extracting  libicuio.so.56
Extracting  libicule.so.56
Extracting  libiculx.so.56
Extracting  libicutest.so.56
Extracting  libicutu.so.56
Extracting  libicuuc.so.56
Extracting  libicudata.so.56.1
Extracting  libicui18n.so.56.1
Extracting  libicuio.so.56.1
Extracting  libicule.so.56.1
Extracting  libiculx.so.56.1
Extracting  libicutest.so.56.1
Extracting  libicutu.so.56.1
Extracting  libicuuc.so.56.1

>
> --
> Thiago Macieira - thiago.macieira (AT) intel.com
>   Software Architect - Intel Open Source Technology Center
>
> ___
> Development mailing list
> Development@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development

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

[Development] Setting CMAKE_PREFIX_PATH to Qt prefix breaks use of system ICU via CMake

[Konstantin Tokarev]

Hello,

There is a strange situation involving official Qt SDK (>=5.8.0) binaries for 
Linux, ICU, cmake, and WebKit project files, I'm not sure which side really 
needs to be fixed.

(Qt)WebKit uses custom module to find ICU, you can see its code at [1]. Module 
uses quite popular practise of invoking pkg-config first, and then performing 
search of libs and headers by passing them as HINTS to find_path() and 
find_library(). Doing so allows to have a meaningful fallback if pkg-config is 
missing, misconfigured, or e.g. returns host libs when cross-compilation is 
needed.

Before Qt 5.8.0, Qt SDK didn't include unversioned symlinks for ICU libraries, 
e.g. 5.7 had only libicuuc.so.56 and libicuuc.so.56.1, but not libicuuc.so. 
Starting from 5.8.0, unversioned symlinks are also provided.

Now, if someone sets CMAKE_PREFIX_PATH to the Qt root in SDK, cmake starts to 
find ICU libraries in SDK, because  priority logic of find_library makes 
CMAKE_PREFIX_PATH preferred to the HINTS provided by pkg-config.

At the same time, there are no ICU headers in Qt SDK, so include paths are 
taken from pkg-config, that detects system-wide installation of ICU. Note that 
ICU uses versioned suffixes in symbol names, so different versions are binary 
incompatible, resulting in the broken build when headers don't match libraries.

There are a few possible solutions:

* Provide ICU headers as a part of Qt SDK too. This has a benefit that ICU 
libraries, required for QtCore, can be reused in other projects that use Qt and 
ICU, e.g. for building of experimental QtWebKit versions against binary SDK.
* Remove unversioned symlinks like libicuuc.so from SDK, so that they are not 
found by FindICU.cmake, and also by linker if it's given -licuuc
* Avoid using CMAKE_PREFIX_PATH with Qt SDK, using Qt5_DIR and similar 
variables instead
* Change FindICU to ignore libraries Qt-related paths - ugly hack, also 
FindICU.cmake is technically 3rd party code for QtWebKit
* Change priorities in CMake's find_library - probably off-topic for this list, 
and may be impossible because of backward compatibility reasons.

Thoughts?

[1] 
https://github.com/annulen/webkit/blob/qtwebkit-stable/Source/cmake/FindICU.cmake

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

Re: [Development] QList

[Konstantin Tokarev]

26.04.2017, 08:04, "Marc Mutz" :
> On 2017-04-25 23:04, Thiago Macieira wrote:
>>  On Tuesday, 25 April 2017 17:49:16 -03 Alejandro Exojo wrote:
>>>  On Tuesday 25 April 2017 16:35:01 Thiago Macieira wrote:
>>>  > QVector and QList don't have the same API. They're slightly different.
>>>  > What'sm ore, QList has a beginning-of-list optimisation, whereas QVector
>>>  > doesn't (not even my copy, I stopped development shortly before I got to
>>>  > that part, even if I did add a QArrayData::GrowsBackward flag to support
>>>  > the case).
>>>  >
>>>  > (...)
>>>  >
>>>  > So, no, we can't implement that in Qt 5. In Qt 6, we've already agreed we
>>>  > don't want this mess, so QList as it is simply goes away.
>>>
>>>  By the way, which is the exit strategy for QQueue?
>>
>>  Do we need one?
>>
>>  The only reason that QQueue uses QList is because QList has that
>>  takeFirst()
>>  optimisation, while QVector does not. Once we implement that for
>>  QVector, we
>>  should be able to use QQueue with QVector too.
>
> FWIW: I'm against adding even more pessimising goodies to QVector. An
> area for push_front is such a goodie. The addition this causes is
> probably the reason why a QList, even for optimal payloads, is
> outperformed by QVector in my well-known benchmark from -Wmarc. Users
> that need a queue can use std::deque. If you don't iterate over it, it's
> a more than acceptable container.

std::deque is not a contiguous container, unlike QList or QVector, so it cannot 
be a
drop-in replacement.

>
> Thanks,
> Marc
> ___
> Development mailing list
> Development@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development

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

Re: [Development] QCOMPARE & mixed types

[Konstantin Tokarev]

21.04.2017, 13:45, "Milian Wolff" :
> On Freitag, 21. April 2017 12:10:07 CEST Marc Mutz wrote:
>>  Hi,
>>
>>  Jedrzej asked me to raise the issue here.
>>
>>  Rationale for both allowing, as well as for why I think the rationale for
>>  the existing ban is wrong, is included in the commit message:
>>
>>    https://codereview.qt-project.org/192269
>
> I for one welcome this change. I always cringed when I wrote code such as
>
> QCOMPARE(getSomeQUint64(), 0)
>
> and it would fail to compile, forcing me to write ugly code such as
>
> QCOMPARE(getSomeQUint64(), quint64(0))
>
> I've also come across code that failed to compile some platforms, since it
> used something like 0l or 0ll which did not match whatever platform-specific
> type was used on the lhs...
>
> So, from my side a clear +1!

Another case: comparing QString or QByteArray on one side with const char*
literal, or with expression which returns QStringBuilder

> --
> Milian Wolff | milian.wo...@kdab.com | Software Engineer
> KDAB (Deutschland) GmbH KG, a KDAB Group company
> Tel: +49-30-521325470
> KDAB - The Qt Experts
> ,
>
> ___
> Development mailing list
> Development@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development

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

Re: [Development] Deleter that calls deleteLater() for use with std::unique_ptr<> and other smart pointers

[Konstantin Tokarev]

19.04.2017, 21:37, "Darin Broady" <dbroa...@yahoo.com>:
> Is there a reason a new member function for QScopedPointerObjectDeleteLater 
> that conforms to the interface specified by std::default_delete would not 
> work?
>
>    void QScopedPointerObjectDeleteLater::operator()(T *pointer) const { if 
> (pointer) pointer->deleteLater(); }

No strong reason, this was one of my thoughts too. 
One minor thing is that it won't have anything to do with QScopedPointer.

>
> Darin Broady
> dbroa...@yahoo.com
>
> On Wednesday, April 19, 2017 9:44 AM, Konstantin Tokarev <annu...@yandex.ru> 
> wrote:
>
> Hello,
>
> I think it will be a good idea to provide implementation of functor calling
> deleteLater() instead of delete which can be used with std::unique_ptr,
> std::shared_ptr and other smart pointers with compatible interface.
>
> We already have QScopedPointerObjectDeleteLater, however it implements
> cleanup(T*) instead of operator()(T*).
>
> Any suggestions how to name this new class and where to place it?
>
> --
> Regards,
> Konstantin
> ___
> Development mailing list
> Development@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development


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

Re: [Development] Deleter that calls deleteLater() for use with std::unique_ptr<> and other smart pointers

[Konstantin Tokarev]

19.04.2017, 20:58, "Ville Voutilainen" <ville.voutilai...@gmail.com>:
> On 19 April 2017 at 20:48, Konstantin Tokarev <annu...@yandex.ru> wrote:
>>  19.04.2017, 20:43, "Thiago Macieira" <thiago.macie...@intel.com>:
>>>  On quarta-feira, 19 de abril de 2017 06:44:24 PDT Konstantin Tokarev wrote:
>>>>   Hello,
>>>>
>>>>   I think it will be a good idea to provide implementation of functor 
>>>> calling
>>>>   deleteLater() instead of delete which can be used with std::unique_ptr,
>>>>   std::shared_ptr and other smart pointers with compatible interface.
>>>>
>>>>   We already have QScopedPointerObjectDeleteLater, however it implements
>>>>   cleanup(T*) instead of operator()(T*).
>>>>
>>>>   Any suggestions how to name this new class and where to place it?
>>>
>>>  QSharedPointer already supports a PMF as a deleter.
>>>
>>>  auto ptr = QSharedPointer(new QObject, 
>>> ::deleteLater);
>>>
>>>  So I think this actually belongs in the std-proposals mailing list, not in 
>>> Qt.
>>>
>>>  Until C++20 gets it, you can use a lambda.
>>
>>  It's not possible to have members with auto-deduced types in non-template 
>> class,
>>  so I actually cannot.
>
> I fail to see what auto-deduced members have to do with it:
>
> std::unique_ptr<QObject, void(*)(QObject*)> upqobj{nullptr,
> [](QObject* obj) { obj->deleteLater(); }};

Thanks, it works.

Except it's totally unusable because of bolerplate spreading.
Compare with

std::unique_ptr<QObject, QObject::DeleteLater>

that you can initialize without any boilerplate. Also, the second version
does not increase size of unique_ptr with size of function pointer.

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

Re: [Development] Deleter that calls deleteLater() for use with std::unique_ptr<> and other smart pointers

[Konstantin Tokarev]

19.04.2017, 20:43, "Thiago Macieira" <thiago.macie...@intel.com>:
> On quarta-feira, 19 de abril de 2017 06:44:24 PDT Konstantin Tokarev wrote:
>>  Hello,
>>
>>  I think it will be a good idea to provide implementation of functor calling
>>  deleteLater() instead of delete which can be used with std::unique_ptr,
>>  std::shared_ptr and other smart pointers with compatible interface.
>>
>>  We already have QScopedPointerObjectDeleteLater, however it implements
>>  cleanup(T*) instead of operator()(T*).
>>
>>  Any suggestions how to name this new class and where to place it?
>
> QSharedPointer already supports a PMF as a deleter.
>
> auto ptr = QSharedPointer(new QObject, 
> ::deleteLater);
>
> So I think this actually belongs in the std-proposals mailing list, not in Qt.
>
> Until C++20 gets it, you can use a lambda.

It's not possible to have members with auto-deduced types in non-template class,
so I actually cannot.

>
> --
> Thiago Macieira - thiago.macieira (AT) intel.com
>   Software Architect - Intel Open Source Technology Center
>
> ___
> Development mailing list
> Development@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development

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

Re: [Development] Deleter that calls deleteLater() for use with std::unique_ptr<> and other smart pointers

[Konstantin Tokarev]

19.04.2017, 17:52, "Giuseppe D'Angelo" <giuseppe.dang...@kdab.com>:
> Il 19/04/2017 15:44, Konstantin Tokarev ha scritto:
>>  I think it will be a good idea to provide implementation of functor calling
>>  deleteLater() instead of delete which can be used with std::unique_ptr,
>>  std::shared_ptr and other smart pointers with compatible interface.
>>
>>  We already have QScopedPointerObjectDeleteLater, however it implements
>>  cleanup(T*) instead of operator()(T*).
>>
>>  Any suggestions how to name this new class and where to place it?
>
> Where to place it: in qobject.h, unless we claim this is done for STL
> compatibility, and therefore it may need to go somewhere else depending
> on the resolution on the other thread.
>
> I don't think this stuff should be there purely for STL compatibility.
> In hindsight, the QScopedPointer deleters should have had more generic
> names than QScopedPointerFoo, as they should be usable in other
> scenarios too (QSharedPointer?).
>
> So, maybe, just add this as an inner class of QObject?
> QObject::DeleteLater(Functor) maybe?

I thought about it, however I had a concern that QScopedPointerObjectDeleteLater
is a template that in theory can call non-QObject deleteLater() method, while
inner class of QObject is expected to work with QObject-derived classes only

>
> My 2 cents,
> --
> Giuseppe D'Angelo | giuseppe.dang...@kdab.com | Senior Software Engineer
> KDAB (UK) Ltd., a KDAB Group company | Tel: UK +44-1625-809908
> KDAB - Qt, C++ and OpenGL Experts
>
> ,
>
> ___
> Development mailing list
> Development@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development

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

[Development] Deleter that calls deleteLater() for use with std::unique_ptr<> and other smart pointers

[Konstantin Tokarev]

Hello,

I think it will be a good idea to provide implementation of functor calling 
deleteLater() instead of delete which can be used with std::unique_ptr,
std::shared_ptr and other smart pointers with compatible interface.

We already have QScopedPointerObjectDeleteLater, however it implements
cleanup(T*) instead of operator()(T*).

Any suggestions how to name this new class and where to place it?

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

Re: [Development] Make qtstyleplugins an official module and release it

[Konstantin Tokarev]

17.04.2017, 21:20, "Sérgio Martins" :
> On Mon, Apr 17, 2017 at 6:50 PM, Thiago Macieira
>  wrote:
>>  Looks like we moved important functionality from qtbase to qtstyleplugins. 
>> Why
>>  wasn't it added to .gitmodules and included in the 5.7.0 and 5.8.0 releases?
>
> IIRC, the gtk2 stuff was considered non-important (there's was a
> thread about this).
>
> But after reading today's qt-interest I think you're referring to the
> gtk3 style. That style simply doesn't exist, not even in
> qtstyleplugins. If we were to implement it it would probably go to
> qtbase.

FWIW, author of QtCurve gave up on GTK3 support, because things break with every
new version.

>
> Regards,
> Sérgio Martins
> ___
> Development mailing list
> Development@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development

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

Re: [Development] As Qt contemplates its future..

[Konstantin Tokarev]

15.04.2017, 01:23, "Shawn Rutledge" :
>>  On 13 Apr 2017, at 14:02, Randall O'Reilly  
>> wrote:
>>
>>  With the recent language explosion, there are now languages to fit 
>> everyone’s biases and aesthetics.
>
> This explosion is possible because of common language backends and VMs like 
> the JVM, CLR or LLVM. (Hacking gcc to add a new language would’ve been much 
> harder.) So, hopefully that means that you don’t have to champion Go itself 
> as the language of the century and plan on rewriting all of Qt in Go, right? 
> As long as you can generate LLVM-IR somehow from your favorite language at 
> this juncture, you share a foundation with plenty of other languages, so 
> maybe modules written in one could interoperate with modules written in 
> another? Depends on the ABI though.
>
> The Rust guys make the point that it’s necessary to rewrite lots of old stuff 
> in Rust in order to have all the security that it can guarantee. But with Go, 
> is there such a mandate? To me so far, Go seems incrementally better but not 
> quite a revolution; fine to try for new projects but maybe not worth the 
> effort of rewriting old code. And of course I’ve been around the block before 
> with this idea that such-and-such needs to be rewritten in such-and-such 
> new-hotness language. The next rewrite ends up more bloated and slow than the 
> last… that seems to be the rule.
>
> One big obstacle I’ve been seeing for years is the shortage of C++ API for 
> the QtQuick scene graph, and the difficulty of separating the scene graph to 
> be independent of QML. If you want to have one language for your application 
> (which isn’t QML, Javascript or C++) then you need scene graph bindings to at 
> least be possible. And the usual reason we give is that we don’t have public 
> API so that we remain free to change it. But it’s still an obstacle for 
> making bindings. IMO we’ve got to get to the point where at least the private 
> APIs are complete enough and reasonable enough to use, so you could maintain 
> a scene graph binding for another language alongside Qt, and iterate along 
> with it. Or else rewrite the scene graph, but that seems like needless work, 
> doesn’t it? You can search GitHub and find plenty of scene graphs, but how 
> many of them can do internationalized antialiased text using an atlas (not 
> pre-rendering whole words or lines with freetype), and how many of them do 
> batching like Qt's?
>
> Next, why does Go not use LLVM by default? Why do QML and V4 not use it, for 
> that matter? I was hoping we’d do it that way, but we didn’t. I think it 
> would have saved some work, and gained some interoperability, and a lot of 
> tooling possibilities.

Concerning QML/V4: this is a good idea actually. If QML is changed to use AOT 
compilation as the only mode, it might work very well. 

>
>>  This also means that there is an endless potential for language wars, which 
>> I’m sure nobody wants to rehash on this list. My point is just that Go 
>> represents a particular set of choices that I think is very compatible with 
>> a certain (possibly large) segment of the Qt user-base — those who favor 
>> clarity, simplicity, readability, over e.g., extreme performance 
>> optimization or having every different kind of possible language feature at 
>> one’s disposal (aka “language bloat”). As C++ is seemingly in a constant 
>> state of reinvention lately, and is now massively bloated and unwieldy in 
>> some people’s estimation, it might be an opportune moment to consider a 
>> “reboot” — a fresh new framework unburdened by all that cruft. My sense is 
>> that Go has made some really excellent (and hard) choices that benefit from 
>> all the different language experiments and experience (and especially the 
>> limitations of C++), and that one major thing holding it back is lack of a 
>> decent GUI framework, so that Qt could really make a big difference there. 
>> Furthermore, Qt itself has a kind of bloat problem of its own, having 
>> evolved in major ways over the years (Widgets vs. QML, scenegraphs, and now 
>> 3D), so it could possibly benefit from a fresh start / reboot as well.
>>
>>  Perhaps building from the ground-up on a core scenegraph framework that can 
>> support 2D *and* 3D,
>
> and usually it would be pointed out that a 3D engine is terrible overkill for 
> 2D UIs. But now we’re coming out with that third choice anyway, Qt 3D Studio. 
> So maybe we’ll get there after all, and find out whether or not a 3D scene 
> graph is practical for ordinary everyday UIs. Of course if there ends up 
> being a good reason to have a true 3D UI in most everyday ordinary 
> applications, then the 3D scene graph is not overkill I guess.
>
>>  with different back-end renderers (OpenGL ES etc), using e.g., SVG syntax 
>> to do the widget etc painting in a resolution-independent, style-based 
>> manner (no more high-dpi hassles — future proof resolution 

Re: [Development] Qt 5.10 schedule proposal

[Konstantin Tokarev]

13.04.2017, 15:11, "Bogdan Vatra" :
> It's just me or did you forgot to add 5.8.1?

I think I hear how Mr. Turunen is pulling his hair out reading this :)

>
> Cheers,
> BogDan.
>
> On joi, 13 aprilie 2017 11:48:06 EEST Jani Heikkinen wrote:
>>  After short internal discussion here is my proposal for those patch level
>>  releases:
>>
>>  - Branch '5.6.3' from '5.6' at the end of May/beginning of June, 5.6.3
>>  release target August 2017 - Branch '5.9.1' from '5.9' at the end of
>>  July/beginning of August, 5.9.1 release target September 2017 - Branch
>>  '5.9.2' from '5.9' Nov 2017
>>  - Branch '5.6.4' from '5.6' Jan 2018
>>
>>  br,
>>  Jani
>>
>>  > -Original Message-
>>  > From: Development [mailto:development-bounces+jani.heikkinen=qt.io@qt-
>>  > project.org] On Behalf Of Thiago Macieira
>>  > Sent: maanantaina 10. huhtikuuta 2017 18.46
>>  > To: development@qt-project.org; releas...@qt-project.org
>>  > Subject: Re: [Development] Qt 5.10 schedule proposal
>>  >
>>  > Em segunda-feira, 10 de abril de 2017, às 00:39:09 PDT, Jani Heikkinen
>>  >
>>  > escreveu:
>>  > > Hi,
>>  > >
>>  > > Qt 5.9 is proceeding quite well and it is time to start planning Qt
>>  > > 5.10 schedule. We want to to release 5.10 before Christmas so we need
>>  > > to have Qt
>>  > > 5.10 FF at the beginning of August. I propose following initial
>>  > > schedule for Qt 5.10:
>>  > >
>>  > > - Qt 5.10 Feature Freeze: 8.8.2017
>>  > > - Qt 5.10 Alpha Release: 31.8.2017
>>  > > - First Qt 5.10 Beta Release 5.10.2017
>>  > > - Qt 5.10 RC 16.11.2017
>>  > > - Qt 5.10 final release 30.11.2017
>>  >
>>  > Can you add the Qt 5.6.3, 5.6.4 and 5.9.1 relase dates to the list, so we
>>  > have an idea of how much work it will be?
>>  >
>>  > --
>>  > Thiago Macieira - thiago.macieira (AT) intel.com
>>  >
>>  > Software Architect - Intel Open Source Technology Center
>>  >
>>  > ___
>>  > Development mailing list
>>  > Development@qt-project.org
>>  > http://lists.qt-project.org/mailman/listinfo/development
>>
>>  ___
>>  Development mailing list
>>  Development@qt-project.org
>>  http://lists.qt-project.org/mailman/listinfo/development
>
> ___
> Development mailing list
> Development@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development

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

Re: [Development] As Qt contemplates its future..

[Konstantin Tokarev]

13.04.2017, 13:25, "Konstantin Tokarev" <annu...@yandex.ru>:
> 13.04.2017, 12:32, "Nikita Krupenko" <krne...@gmail.com>:
>>  On четверг, 13 апреля 2017 г. 08:24:39 EEST Randall O'Reilly wrote:
>>>   In the context of all this recent discussion about modernizing Qt to
>>>   accommodate updates to C++, has anyone given any thought to the radical
>>>   idea of creating a brand new product using Go? Go (golang) is rapidly
>>>   gaining in popularity, and seems to embody everything that is great about
>>>   Qt (simplicity, elegance, strong concern for readability, etc), and it has
>>>   many features of Qt built directly into the language (reflection, i.e.,
>>>   moc, goroutines and channels for signal / slot functionality). One of its
>>>   main limitations is lack of a dominant, fully-featured GUI toolkit. There
>>>   are existing bindings to Qt and QML, but it seems like creating a brand 
>>> new
>>>   native GUI framework in the Qt mold could be a great opportunity to make a
>>>   huge impact on a language that has a bright future. All the lessons
>>>   learned as Qt has evolved over the years could be consolidated into a 
>>> fresh
>>>   new design, based fundamentally on a 2D & 3D scenegraph, using OpenGL ( /
>>>   Vulkan, etc) as the underlying renderer, or something like that… Obviously
>>>   a huge undertaking, but something that could produce transformative 
>>> effects
>>>   for future programmers (whereas it seems that continued improvements to 
>>> the
>>>   C++ product are likely to be much more incremental). Maybe some funding
>>>   from Google could be obtained to support such an endeavor?
>>>
>>>   - Randy
>>
>>  Why Go? Isn't Rust more close to the C++ niche?
>
> Rust does not have even GCC frontend, so is even less portable than C++

Ooops, I meant "than Go"

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

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

Re: [Development] As Qt contemplates its future..

[Konstantin Tokarev]

13.04.2017, 12:32, "Nikita Krupenko" :
> On четверг, 13 апреля 2017 г. 08:24:39 EEST Randall O'Reilly wrote:
>>  In the context of all this recent discussion about modernizing Qt to
>>  accommodate updates to C++, has anyone given any thought to the radical
>>  idea of creating a brand new product using Go? Go (golang) is rapidly
>>  gaining in popularity, and seems to embody everything that is great about
>>  Qt (simplicity, elegance, strong concern for readability, etc), and it has
>>  many features of Qt built directly into the language (reflection, i.e.,
>>  moc, goroutines and channels for signal / slot functionality). One of its
>>  main limitations is lack of a dominant, fully-featured GUI toolkit. There
>>  are existing bindings to Qt and QML, but it seems like creating a brand new
>>  native GUI framework in the Qt mold could be a great opportunity to make a
>>  huge impact on a language that has a bright future. All the lessons
>>  learned as Qt has evolved over the years could be consolidated into a fresh
>>  new design, based fundamentally on a 2D & 3D scenegraph, using OpenGL ( /
>>  Vulkan, etc) as the underlying renderer, or something like that… Obviously
>>  a huge undertaking, but something that could produce transformative effects
>>  for future programmers (whereas it seems that continued improvements to the
>>  C++ product are likely to be much more incremental). Maybe some funding
>>  from Google could be obtained to support such an endeavor?
>>
>>  - Randy
>
> Why Go? Isn't Rust more close to the C++ niche?

Rust does not have even GCC frontend, so is even less portable than C++

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

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

Re: [Development] As Qt contemplates its future..

[Konstantin Tokarev]

13.04.2017, 08:25, "Randall O'Reilly" :
> In the context of all this recent discussion about modernizing Qt to 
> accommodate updates to C++, has anyone given any thought to the radical idea 
> of creating a brand new product using Go? Go (golang) is rapidly gaining in 
> popularity, and seems to embody everything that is great about Qt 
> (simplicity, elegance, strong concern for readability, etc), and it has many 
> features of Qt built directly into the language (reflection, i.e., moc, 
> goroutines and channels for signal / slot functionality). One of its main 
> limitations is lack of a dominant, fully-featured GUI toolkit. There are 
> existing bindings to Qt and QML, but it seems like creating a brand new 
> native GUI framework in the Qt mold could be a great opportunity to make a 
> huge impact on a language that has a bright future. All the lessons learned 
> as Qt has evolved over the years could be consolidated into a fresh new 
> design, based fundamentally on a 2D & 3D scenegraph, using OpenGL ( / Vulkan, 
> etc) as the underlying renderer, or something like that… Obviously a huge 
> undertaking, but something that could produce transformative effects for 
> future programmers (whereas it seems that continued improvements to the C++ 
> product are likely to be much more incremental). Maybe some funding from 
> Google could be obtained to support such an endeavor?

I think binding like this may work for you:

https://github.com/therecipe/qt

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

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

Re: [Development] Focusing bug fixes to 5.9 branch and patch releases during H1/17

[Konstantin Tokarev]

11.04.2017, 15:45, "Ville Voutilainen" :
> On 11 April 2017 at 15:16, Marc Mutz  wrote:
>>  On Tuesday 11 April 2017 13:49:01 Ville Voutilainen wrote:
>>>  You say we discourage cherry-picking. Why? Is that not a fairly
>>>  natural way to backport
>>>  bugfixes from a bleeding-edge branch to a stabler branch?
>>
>>  Afaict, it's because it's against the workflow of the RCS.
>
> So, we think it's better to forward-merge everything from stable to
> dev, rather than
> cherry-pick from dev to stable?

In git cherry-picking results in duplication of commits between branches, that
have similar content but different hashes. Also, in case of conflicts merge
can result in way less work than cherry-picking, as in O(N) vs O(1)

>
>>  Are you proposing a everything-to-dev-cherry-pick-into-older-branches-only
>>  model?
>
> I'm not proposing it yet, but such models seem plenty attractive to me.
> ___
> Development mailing list
> Development@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development

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

Re: [Development] Focusing bug fixes to 5.9 branch and patch releases during H1/17

[Konstantin Tokarev]

11.04.2017, 14:37, "Tuukka Turunen" :
> Hi,
>
> We have discussed this already multiple times and it is well known by 
> everyone. Closing of the branch has been clearly decided, only item open has 
> been the time. Now that we have 5.9 beta released, I think it clearly is the 
> time to close 5.8 and fully focus into making Qt 5.9 good. The sooner we get 
> 5.9.0 out, the sooner we can also get 5.9.1 out. And note that 5.9.0 contains 
> every fix that would have been part of 5.8.1 and more – a lot more.
>
> No-one is happy about skipping patch releases for 5.8. This is a trade off 
> done in order to get better Qt releases in the future. Keeping 5.8 branch 
> open and pushing fixes there instead of 5.9 results in worse 5.9 than we 
> could have by focusing to it. Every single merge from 5.8 to 5.9 is time away 
> from people to work on 5.9 (and dev), from machines to be able to work on 5.9 
> (and dev), and from calendar time of having fixes on the hands of most of the 
> users (i.e. getting them into a release of Qt or pre-releases of Qt).

Maybe it's plausible to make 5.8.1 release just for QtBase?

>
> Yours,
>
> Tuukka
>
> On 11/04/2017, 14.17, "Development on behalf of Giuseppe D'Angelo" 
>  giuseppe.dang...@kdab.com> wrote:
>
> Il 11/04/2017 12:46, Aleix Pol ha scritto:
> > What's the point of keeping 5.8 open if there's not going to be
> > another 5.8 release?
>
> Because of customer projects, Linux distributions, etc. that are
> currently on 5.8, and that want to benefit from the latest bug fixes and
> performance improvements without waiting 4-5 months for 5.9.1.
>
> Yes, they *will* skip any .0 release, and convincing customers to
> upgrade to a new minor release is definitely more complicated than
> convincing to upgrade to a new patch release (... which in this case
> translates to tracking the 5.8 branch).
>
> Cheers,
> --
> Giuseppe D'Angelo | giuseppe.dang...@kdab.com | Senior Software Engineer
> KDAB (UK) Ltd., a KDAB Group company | Tel: UK +44-1625-809908
> KDAB - Qt, C++ and OpenGL Experts
>
> ___
> Development mailing list
> Development@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development

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

Re: [Development] Focusing bug fixes to 5.9 branch and patch releases during H1/17

[Konstantin Tokarev]

11.04.2017, 11:56, "Ville Voutilainen" :
> On 11 April 2017 at 11:47, Tuukka Turunen  wrote:
>>  Hi Marc,
>>
>>  I can understand your viewpoint, but unfortunately keeping 5.8 open does 
>> cause additional load to the systems as well as people. It would be great if 
>> you would rather focus into improving Qt 5.9 and making it good for our 
>> users than pushing stuff into a branch that has no further releases planned 
>> from it.
>>
>>  Can you explain why you can not push your Qt Base changes to 5.9 like 
>> ~everyone else?
>
> I still hear suggestions along the lines of pushing stuff into 5.8,
> from which they "eventually get merged into 5.9 and dev". That
> merging seems to be an occasional manual process, though, so the
> overall situation is confusing indeed.

Note that you can ask lqi in #qt-labs to perform some particular merge if you 
need it.

> At any rate, I think
> it would be wise to do a 5.8->5.9 merge before even considering
> closing 5.8, lest we lose bugfixes.
> ___
> Development mailing list
> Development@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development

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

Re: [Development] What happened to the *-dbg packages in Ubuntu 17.04

[Konstantin Tokarev]

07.04.2017, 21:18, "Nathan Osman" :
> Hi,
>
> I recently switched to the second beta of Kubuntu 17.04. I attempted to 
> install the qtbase5-dbg package, only to discover that it was absent. In 
> fact, not only was this package missing but all of the *-dbg packages for Qt 
> components were missing.
>
> Is there another package that provides the debug symbols? Why were these 
> packages removed?

Hi,

Qt Project is not responsible for distro packages. Please ask your package 
maintainer.

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


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

Re: [Development] Passing QSize, QPoint, QTime and other small structs by value

[Konstantin Tokarev]

07.04.2017, 13:41, "Sergio Martins" :
> Hi,
>
> Some time ago I documented the guidelines on passing by value vs
> const-ref:
> https://wiki.qt.io/API_Design_Principles#Passing_by_const-ref_vs._Passing_by_value
> This was discussed in #qt-labs at the time and informally +2'd there.
>
> But the reality is that passing small structs by value is not very
> popular and Qt's API mostly passes them by const-ref.
>
> I think this is a good time to have a more formal conversation,
> bikeshed+popcorn, then write a QUIP and hopefully change the API for Qt
> 6.
>
> The guideline is very simple:
> - If your type has a non-trivial copy-CTOR or non-trivial DTOR then pass
> by const-ref, no matter how small it is, to avoid calling those methods.
> *[1]
> - If your type has trivial CTOR and trivial DTOR, pass by value if it's
> small, otherwise const-ref. Small meaning <= 16 bytes.

I think such rule should be enforced by tooling, e.g. something like clazy.

Btw, do you consider case when properties of type in question are changed
in future Qt version, e.g. new fields or ctors are added (in case of non-public
class/struct)?

>
> The idea is that by value allows the struct's members to be passed in
> CPU registers, see [2] for extensive research.
>
> The good news is, even if you don't care about raw performance, passing
> by value is more convenient, as you type less code, so IMO, more fun to
> use.
>
> [1] - Shared pointers should go by value though, I'll try to prove it in
> the QUIP.
> [2] -
> http://www.macieira.org/blog/2012/02/the-value-of-passing-by-value/
>
> Cheers,
> --
> Sérgio Martins | sergio.mart...@kdab.com | Senior Software Engineer
> Klarälvdalens Datakonsult AB, a KDAB Group company
> Tel: Sweden (HQ) +46-563-540090, USA +1-866-777-KDAB(5322)
> KDAB - The Qt, C++ and OpenGL Experts
> ___
> Development mailing list
> Development@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development

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

Re: [Development] Moving Qt's undo framework out of Qt Widgets

[Konstantin Tokarev]

05.04.2017, 17:46, "Oswald Buddenhagen" :
> On Wed, Apr 05, 2017 at 12:02:32PM +, Morten Sørvig wrote:
>>  On 5 Apr 2017, at 12:37, Oswald Buddenhagen  
>> wrote:
>>  > also, a plan for splitting up qtbase wouldn't be entirely off the
>>  > mark. untangling tests and examples would be the major effort here.
>>
>>  No, we should follow Google and Facebook’s lead: large monolithic
>>  repos (as large as the infrastructure can handle), which can be
>>  updated atomically.
>
> that's kinda the point: the infrastructure (and tooling) can't handle
> it, at multiple levels.
> for the atomicity, see https://bugreports.qt.io/browse/QTQAINFRA-868 .

Right now it requires a lot of time and patience to get any patch integrated 
into qt5.git.
If everything is in the same repo, the same will apply to patches for other 
modules :/

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

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

Re: [Development] Moving Qt's undo framework out of Qt Widgets

[Konstantin Tokarev]

05.04.2017, 12:24, "Mitch Curtis" :
> I'd like to remove the undo framework's dependency on widgets. There's a bug 
> report for this here:
>
> https://bugreports.qt.io/browse/QTBUG-40040
>
> My plan is mentioned in the commit message of the following change:
>
> https://codereview.qt-project.org/#/c/190704/
>
> To summarise:
>
> - Introduce QGuiUndo* classes that don't have any QAction-related API (which 
> is the only thing tying the framework to widgets)
> - Make the existing QUndo* classes derive from the respective Qt Gui classes

Out of curiosity, why does this code have to be in QtGui? Looks pretty-much 
GUI-independent.

>
> This would allow existing code that relies on the QAction API (or otherwise 
> uses widgets anyway and hence doesn't care) to remain unchanged, and for e.g. 
> Qt Quick applications to use the undo framework without relying on widgets.
>
> This is a change for Qt 6, seeing as we cannot "[for existing classes] change 
> the class hierachy in any way (add, remove, or reorder base classes)."
>
> https://community.kde.org/Policies/Binary_Compatibility_Issues_With_C%2B%2B#The_Do.27s_and_Don.27ts
>
> If people are OK with having duplicated code until Qt 6 (it's code that's 
> rarely touched anyway), we could also introduce the QGuiUndo* classes in the 
> next applicable minor version.
>
> Jake ever-so-politely chimed in with "an undo/redo stack has nothing to do 
> with graphics". While he phrased it in a pretty ridiculous (the majority of 
> applications using undo/redo are graphical user interfaces) and familiarly 
> arrogant way, I do agree that non-GUI applications could benefit from this.
>
> So, should this get its own module, and if so, can widgets depend on it?
> ___
> Development mailing list
> Development@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development

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

Re: [Development] QList

[Konstantin Tokarev]

30.03.2017, 17:33, "Matthew Woehlke" <mwoehlke.fl...@gmail.com>:
> On 2017-03-29 18:33, Konstantin Tokarev wrote:
>>  30.03.2017, 00:17, "Philippe" <philw...@gmail.com>:
>>>  And being able to use a QVector with O(1) by-value assigment, thanks to
>>>  COW, make it easy to use QVectors "as primitive types", with no
>>>  reasonning effort.
>>
>>  With move semantics you can achieve this without CoW in a more explicit way
>
> I don't think we all agree that "in a more explicit way" is a *feature*.

Go write code in JS then. It manages even more things implicitly than just 
lifetime of your
data objects, and has much less syntactic overhead.


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

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

Re: [Development] QList

[Konstantin Tokarev]

31.03.2017, 10:38, "Marc Mutz" :
> On Friday 31 March 2017 08:57:50 Simon Hausmann wrote:
>>  Hi,
>>
>>  To me this appears to be comparing the questions that new learning
>>  programmers have with questions of seasoned C++ programmers. I understand
>>  that we should cater both with Qt, but the topic at this point of the
>>  thread is the former group, not the latter.
>
> Which questions do you think are beginner's and which ones are seasoned
> developer's questions?
>
> What criteria do you use to put one in one bin and the other in the other?
>
> People that use C++ without Qt have excellent online documentation, too[1].
> And if they peruse it to find out how to fill a vector from a C array, then
> they will come across assign() and the range constructors. They start with Qt,
> and they miss these things.
>
> Everyone learning C++ with the 2011 edition of the standard will be used to
> just throwing ranged-for at every container and suddenly a fat man in a
> YouTube video tells them that doing so with Qt containers performs a deep
> copy. Sure they have questions.
>
> So, no, Qt containers are not more novice-friendly than STL containers, nor
> vice versa. They all leave something to be desired. Picking one part of the
> API and saying "this is why it's better/worse" will predicably be responded to
> by showing the other half of the picture.
>
> But one thing the STL has going for it: once you do learn it, it lets you go
> farther with what you have learned than Qt. Once you learned the find()
> algorithm, you can apply it to every C++ container in the world, incl. C
> arrays and Qt containers. Incl. QFuture, which is a Qt container that -
> surprise - doesn't have indexOf() and contains().
>
> Thanks,
> Marc
>
> [1] even better than Qt's, these days, since cppreference.com clearly shows
> what's available in which C++ version while Qt hides all but the latest
> documentation, which only describes the current state of affairs.

Each Qt release is shipped with documentation.
Also, there is \since.

>
>>  Simon
>>
>>  > On 31. Mar 2017, at 08:41, Marc Mutz  wrote:
>>  >> On Thursday 30 March 2017 22:32:35 Alejandro Exojo wrote:
>>  >>> On Wednesday 29 March 2017 20:11:58 Marc Mutz wrote:
>>  >>> I would really, really
>>  >>> like to know why QVector is easier to use? Because it has indexOf()?
>>  >>> Seriously, now?
>>  >>
>>  >> Because it has _lots_ of easy to use member functions, and another kind
>>  >> of iterator that is also easier to use for some, and good
>>  >> documentation. I'm not making this stuff up:
>>  >>
>>  >> http://stackoverflow.com/questions/571394/
>>  >
>>  > Oh, I can play this game, too:
>>  >
>>  > http://stackoverflow.com/questions/16559655/
>>  > http://stackoverflow.com/questions/38262041/
>>  > http://stackoverflow.com/questions/10153658/
>>  > http://stackoverflow.com/questions/35811053/
>>  >
>>  >> Hundreds of votes for something immensely simple, that with Qt
>>  >> containers is also immensely more readable. Ease of use has a lot more
>>  >> value than performance to many people. A thought: how many comments did
>>  >> get the blog post that you did on making QRegion iterable? And how many
>>  >> the one about the removal of the foreach macro?
>
> --
> Marc Mutz  | Senior Software Engineer
> KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company
> Tel: +49-30-521325470
> KDAB - The Qt, C++ and OpenGL Experts
> ___
> Development mailing list
> Development@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development

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

Re: [Development] QList

[Konstantin Tokarev]

30.03.2017, 00:17, "Philippe" :
>>  I would really, really like to know why QVector is easier to use?
>
> Following common methods are immediate. With std::vector, you need to
> add boilerplate code to achieve the same.
>
> QVector::insert
> QVector::remove
> QVector::value(int i, const T )
> QVector::move
> QVector::contains
> QVector::operator+=(const QVector )
>
> Not to mention the many other convenient QVector methods.
>
> And being able to use a QVector with O(1) by-value assigment, thanks to
> COW, make it easy to use QVectors "as primitive types", with no
> reasonning effort.

With move semantics you can achieve this without CoW in a more explicit way

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

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

Re: [Development] QList

[Konstantin Tokarev]

20.03.2017, 19:40, "Scott Aron Bloom" :
> Now, myself, and a few others are sitting on Qt 5.5 because of the issues 
> with the web browser change in 5.6... but that's another issue

You should upgrade to QtWebKit TP5 [1], binary builds are available for Qt 5.8 
for all supported desktop platforms

[1] https://github.com/annulen/webkit/releases/tag/qtwebkit-tp5

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

Re: [Development] QList

[Konstantin Tokarev]

18.03.2017, 11:06, "Ville Voutilainen" :
> There's been a fair amount of talk about QList's future, so I'm curious:
>
> 1) What are the problems with QList?

https://marcmutz.wordpress.com/effective-qt/containers/#containers-qlist

> 2) What do we plan to do about those problems?

This is probably accurate:
http://lists.qt-project.org/pipermail/development/2015-July/022283.html

> 3) How do we expect to migrate code that uses it?
>
> Pardons all around for not being up to date if there's some material
> on the points
> above; feel free to point me to such material.
> ___
> Development mailing list
> Development@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development

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

Re: [Development] Comparison of version numbers in qmake project files

[Konstantin Tokarev]

07.03.2017, 13:54, "Alexander Volkov" :
> Hi,
>
> Need more reviewers for https://codereview.qt-project.org/#/c/181665/
> which adds test functions for comparing version numbers:
>
> versionNumberAtLeast(VERSION, 5.10.0) {
>  ...
> }
>
> versionNumberLessThan(VERSION, 5.10.0) {
>  ...
> }

Wow, it happened!

>
> There are two questions:
>
> 1. Whether to use Number in the functions' names? (versionNumberAtLeast
> vs versionAtLeast)
>
> 2. Is it enough to add only one function (version[Number]AtLeast)?
>
> BR,
> Alexander.
> ___
> Development mailing list
> Development@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development

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

Re: [Development] There is the wrong behavior with QUdpSocket && EAGAIN on *nix?

[Konstantin Tokarev]

01.03.2017, 13:28, "Denis Shienkov" :
> Hi all,
>
> I have use Qt 5.8, and I want to send to the UDP socket many datagrams
> (e.g. 1 datagrams, each datagram have 1000 bytes size).

Totally unrelated to your main issue, but make sure you are using connected UDP
socket when sending many datagrams to same host, it should improve performance

>
> I use following code:
>
>     int busyCounter = 0;
>     for(;;) {
>     ...
>     const QNetworkDatagram datagram(data, m_remoteAddress, 
> Protocol::SlavePort);
>     if (m_dataSocket->writeDatagram(datagram) == -2) {
>     QElapsedTimer timer;
>     timer.start();
>     const bool result = m_dataSocket->waitForBytesWritten(-1);
>     ++busyCounter;
>     qDebug() << "Wait result:" << result << "nsecs:" << 
> timer.nsecsElapsed() << "busy counter:" << busyCounter;
>     } else {
>     busyCounter = 0;
>     break;
>     }
>     }
>
> As I understand, when I got the EAGAIN error (when the writeDatagram() method 
> fails
> with the error code == -2), it means, that the transmit queue is full, and I 
> need wait
> for something time, e.g. using the select() function:
>
> https://linux.die.net/man/2/sendmsg
>
> "
> When the message does not fit into the send buffer of the socket, send() 
> normally blocks, unless the socket has been placed in nonblocking I/O mode. 
> In nonblocking mode it would fail with the error EAGAIN or EWOULDBLOCK in 
> this case. The select(2) call may be used to determine when it is possible to 
> send more data.
> "
>
> and then, as I understand, I need try to send same datagram again.
>
> Instead of the select() I use the QUdpSocket::waitForBytesWritten() method,
> which uses the select/pool/epoll internally.
>
> But, seems it does not work, as described in the POSIX documentation,
> I got following debug output:
>
> "
> Wait result: false nsecs: 363 busy counter: 1
> ...
> Wait result: false nsecs: 140 busy counter: 232
> ...
> Wait result: false nsecs: 167 busy counter: 1
> ...
> Wait result: false nsecs: 139 busy counter: 238
> ...
> Wait result: false nsecs: 167 busy counter: 1
> ..
> Wait result: false nsecs: 167 busy counter: 19
> ...
> "
>
> and etc.
>
> I suspect, that the busyCounter always should be 1, but it does
> not happens, and the waitForBytesWritten() always fails!
>
> What doing wrong?
>
> BR,
> Denis
>
> ,
>
> ___
> Development mailing list
> Development@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development


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

Re: [Development] Focusing bug fixes to 5.9 branch and patch releases during H1/17

[Konstantin Tokarev]

18.02.2017, 22:13, "Thiago Macieira" :
> On sábado, 18 de fevereiro de 2017 06:36:07 PST Mat Sutcliffe wrote:
>>  Keeping 5.9.0 on schedule even while 5.8.0 blows past its planned release
>>  date would seem to be appropriate when you have the capability to
>>  concurrently maintain two minor (not patchlevel) release branches.
>
> That's exactly what Tuukka proposed we do. We keep 5.9.0 on schedule and,
> because of that, 5.8.1 becomes impossible and unnecessary.

So people who cannot upgrade to 5.8.0 because of bugs would have to wait for
5.9.0 and hope that there will be no other regressions. Great.

>
> --
> Thiago Macieira - thiago.macieira (AT) intel.com
>   Software Architect - Intel Open Source Technology Center
>
> ___
> Development mailing list
> Development@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development

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

Re: [Development] Decrease amounth of delivered src packages

[Konstantin Tokarev]

15.02.2017, 20:07, "Thiago Macieira" :
> On quarta-feira, 15 de fevereiro de 2017 09:04:12 PST Konstantin Podsvirov
> wrote:
>>  This can be not quite on this topic, but I have a suggestion and MVP
>>  implementation for QtIFW.
>>
>>  This may affect the development process, testing and create offline
>>  installers.
>
> Most Valuable Player?

Most Valuable Professional?

>
> --
> Thiago Macieira - thiago.macieira (AT) intel.com
>   Software Architect - Intel Open Source Technology Center
>
> ___
> Development mailing list
> Development@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development

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

Re: [Development] Decrease amounth of delivered src packages

[Konstantin Tokarev]

15.02.2017, 13:39, "Jani Heikkinen" :
> Hi all,
>
> As you know we need to optimize our systems to be able to keep our plans in 
> the future. In CI side we are handling at least 4 different branches at same 
> time. Releasing side we should be able to do many releases/snapshots 
> parallel, test those releases/snapshots parallel etc. And all this needs lots 
> of hw capasity (both calculating power & disc space).
>
> We are trying to analyze the places where to do optimization and one place is 
> our src package creation and delivery: At the moment we are doing, testing & 
> delivering single src packages + separate submodule src packages, all these 
> with .zip, .7z, .tar.gz & .tar.xz! Huge amount of src 
> packages/snapshot/release. And currently doing these both for enterprise and 
> lgpl! In the future (5.10?) we should be able to use unified ones meaning no 
> separate LGPL & enterprise ones.
>
> But I think we could also drop those less used ones(*) as well with quicker 
> schedule so I propose:
>
> From 5.9 -> let's start doing & delivering
>
> - One set of src packages with ẃindows line endings (.zip, both single one & 
> submodule specific, both enterprise and lgpl)
> - One set of src packages with unix line endings (.tar.gz, both single one & 
> submodule specific, both enterprise and lgpl)

Why not use most efficient compression formats instead, i.e. keep 7z and tar.xz 
only?

>
> br,
> Jani
>
> *:Download statistic:
> .7z 7%
> .tar.gz 44%
> .tar.xz 12%
> .zip 37%
>
> ___
> Development mailing list
> Development@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development

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