Re: [Development] Future of QBS

On 10/17/2017 08:12 AM, André Somers wrote: Well, in the case of QBS, would it not be reasonable to terminate the evaluation of any property binding if it takes more than a amount of time? The language may be Turing-complete, but that does not mean the code in control of executing it has to

Re: [Development] Future of QBS

> On Oct 17, 2017, at 9:21 AM, Christian Gagneraud wrote: > > On 17/10/2017 7:52 pm, "Jake Petroules" wrote: > > > On Oct 16, 2017, at 3:34 PM, jeandet wrote: > > > > I have the feeling that a Qt build system will always

Re: [Development] Clazy results for Qt codebase

Hi, interesting - would it it be possible to provide it as a Creator task file (simple tab-separated file to be loaded into Creator's issue pane,  see http://doc.qt.io/qtcreator/creator-task-lists.html  )? That would it make it easy to click through and fix. Thanks, Friedemann --

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

+1 I am a member of the Qt documentation team, and I am often included as a reviewer for code changes that also include changes to qdoc comments. I always assume I am meant to review only the documentation, so if the documentation is ok, I give the change a +1 and add a comment that I only

Re: [Development] Qt6 and QCA

Resend from the right address On 16 October 2017 at 18:38, Richard Moore wrote: > I need to polish up my code showing how to add in additional openssl > features. This can be used to extend it's support without bloating > qtnetwork or qtbase. > > On 13 Oct 2017 8:44 am,

Re: [Development] Future of QBS

> On Oct 16, 2017, at 3:34 PM, jeandet wrote: > > I have the feeling that a Qt build system will always force the users > to choose between another tool they know but where the Qt support might > not be the best and a Qt focused tool with a good Qt support but

Re: [Development] Future of QBS

On 17/10/2017 7:52 pm, "Jake Petroules" wrote: > On Oct 16, 2017, at 3:34 PM, jeandet wrote: > > I have the feeling that a Qt build system will always force the users > to choose between another tool they know but where the Qt support might

Re: [Development] Future of QBS

> On Oct 17, 2017, at 12:17 PM, Christian Gagneraud wrote: > > With all due respect may I suggest that building qt with qbs is actually a > trap, please don't rely on that to solve your user's problems. > Qt is your toolkit, not mine. You should not leak. (No offense. I'm

Re: [Development] Future of QBS

17.10.2017, 05:20, "Kevin Kofler" : > PS: Oh, and I forgot: > > Konstantin Tokarev wrote: >>  [Meson] is written in scripting language > > In addition to what I already wrote, this also implies that the scripting > language (Python in this case) interpreter is required to

Re: [Development] Future of QBS

17.10.2017, 12:49, "Konstantin Tokarev" : > 17.10.2017, 05:06, "Kevin Kofler" : >>>   * Its language has native support for properties, with syntax that really >>>   looks like properties in another languages >> >>  That is what the GET_*_PROPERTY and

Re: [Development] Future of QBS

On 17/10/2017 9:30 pm, "Jake Petroules" wrote: > On Oct 17, 2017, at 9:21 AM, Christian Gagneraud wrote: > > On 17/10/2017 7:52 pm, "Jake Petroules" wrote: > > > On Oct 16, 2017, at 3:34 PM, jeandet

Re: [Development] Future of QBS

17.10.2017, 04:01, "Kevin Kofler" : > Konstantin Tokarev wrote: >>  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

Re: [Development] Future of QBS

17.10.2017, 05:06, "Kevin Kofler" : > Konstantin Tokarev wrote: >>  I have no real experience with Meson, but at least it has following >>  advantages: >> >>  * Its language is typed(!), > > CMake also has a concept of types. In particular, the cache variables (i.e., >

Re: [Development] Review for new widget module [your advices are needed]

> On 14 Oct 2017, at 09:33, iman ahmadvand wrote: > > Hi everyone. > > Before I send some code base on codereview and decide whether my > implementation meets the requirements, I just want to know your thoughts > about design decision for the new module I’m trying to

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

> -Original Message- > From: Development [mailto:development-bounces+kai.koehne=qt.io@qt- > project.org] On Behalf Of Martin Smith > [...] > I am a member of the Qt documentation team, and I am often included as a > reviewer for code changes that also include changes to qdoc comments. I >

Re: [Development] Future of QBS

On 2017-10-17 05:49, Konstantin Tokarev wrote: > 17.10.2017, 05:06, "Kevin Kofler" wrote: >> Konstantin Tokarev wrote: >>>  * 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 >> >>

[Development] Small clarification

Hi, I'd just like to point out that my -2 on: https://codereview.qt-project.org/#/c/204736/ is just a temporary measure whilst I investigate some alternative options. It is in no way meant to be obstructionist and has nothing to do with the recent abandoning of KDAB patches on gerrit. It's

Re: [Development] Future of QBS

On 2017-10-16 22:05, Kevin Kofler wrote: > Konstantin Tokarev wrote: >> I have no real experience with Meson, but at least it has following >> advantages: >> >> * Its language is typed(!), > > CMake also has a concept of types. In particular, the cache variables (i.e., > the variables you can set

Re: [Development] Future of QBS

17.10.2017, 17:26, "Matthew Woehlke" : > On 2017-10-16 22:05, Kevin Kofler wrote: >>  Konstantin Tokarev wrote: >>>  I have no real experience with Meson, but at least it has following >>>  advantages: >>> >>>  * Its language is typed(!), >> >>  CMake also has a concept

Re: [Development] Review for new widget module [your advices are needed]

Hi Shawn. There are 2 things here: 1.In MaterialWidgets we're not going to have lots of animations (like the QML) 2.As i ran many tests under a regular PC, animations were smooth enough and frame rate was pretty good BTW easing curves are there and will help us a lot! And about the styles, i'm

Re: [Development] Review for new widget module [your advices are needed]

17.10.2017, 15:05, "Shawn Rutledge" : >>  On 14 Oct 2017, at 09:33, iman ahmadvand wrote: >> >>  Hi everyone. >> >>  Before I send some code base on codereview and decide whether my >> implementation meets the requirements, I just want to know your

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

17.10.2017, 16:10, "Kai Koehne" : >>  -Original Message- >>  From: Development [mailto:development-bounces+kai.koehne=qt.io@qt- >>  project.org] On Behalf Of Martin Smith >>  [...] >>  I am a member of the Qt documentation team, and I am often included as a >>  reviewer

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

17.10.2017, 10:17, "Martin Smith" : > +1 > > I am a member of the Qt documentation team, and I am often included as a > reviewer for code changes that also include changes to qdoc comments. I > always assume I am meant to review only the documentation, so if the >

Re: [Development] Future of QBS

On domingo, 15 de octubre de 2017 10:23:57 -03 Jake Petroules wrote: [snip] > > We've already decided internally that we want to push Qbs as the new build > tool, and I have no doubt that the community will agree. I would need to be sure it bootstraps itself (ie, it doesn't needs Qt in order

Re: [Development] Future of QBS

On Tue, Oct 17, 2017 at 9:34 AM, Joerg Bornemann wrote: > On 10/17/2017 08:12 AM, André Somers wrote: > >> Well, in the case of QBS, would it not be reasonable to terminate the >> evaluation of any property binding if it takes more than a >> amount of time? The language

Re: [Development] Future of QBS

>> Exactly. The halting problem can be worked around pragmatically. > > ... at the price of getting different build results based on CPU speed ... > > Your fast desktop CPU crunches through the JS and you get a working > built, while my sucky laptop CPU does not and the build fails for me. A

Re: [Development] Future of QBS

On Tue, 17 Oct 2017 17:23:17 +0200 Ulf Hermann wrote: > >> Exactly. The halting problem can be worked around pragmatically. > > > > ... at the price of getting different build results based on CPU speed ... > > > > Your fast desktop CPU crunches through the JS and you get

Re: [Development] Future of QBS

On Tue, Oct 17, 2017 at 05:23:17PM +0200, Ulf Hermann wrote: > >> Exactly. The halting problem can be worked around pragmatically. > > > > ... at the price of getting different build results based on CPU speed ... > > > > Your fast desktop CPU crunches through the JS and you get a working > >

Re: [Development] QtCS 2017 QtCore sessions

On 2017-10-10 14:49, Thiago Macieira wrote: == QStringView == * NEVER return QStringView (but QRegularExpression wants to) ** Consequence of "never return a reference" (but containers do) ** Lifetime issues auto s = lineedit.text().left(n); s valid? * We can be flexible on having

Re: [Development] Future of QBS

I'm just going to ignore the bikeshedding on implementation details, and go back to the main point of the thread, which was right here: Il 13/10/2017 16:56, Sergio Martins ha scritto: Please make something we can easily detach from the qt-project in 10 years and have it's own ecosystem. The

Re: [Development] QtCS 2017 QtCore sessions

On terça-feira, 17 de outubro de 2017 08:28:54 PDT Marc Mutz wrote: > On 2017-10-10 14:49, Thiago Macieira wrote: > > == QStringView == > > * NEVER return QStringView (but QRegularExpression wants to) > > ** Consequence of "never return a reference" (but containers do) > > ** Lifetime issues > >

Re: [Development] Future of QBS

Op 17/10/2017 om 03:01 schreef Kevin Kofler: > Konstantin Tokarev wrote: >> 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 >>

Re: [Development] Future of QBS

Op 17/10/2017 om 17:31 schreef Oswald Buddenhagen: > On Tue, Oct 17, 2017 at 05:23:17PM +0200, Ulf Hermann wrote: Exactly. The halting problem can be worked around pragmatically. >>> ... at the price of getting different build results based on CPU speed ... >>> >>> Your fast desktop CPU

Re: [Development] Future of QBS

On 17/10/2017 11:27 PM, Jake Petroules wrote: We both want to solve the same problems, but I'm not sure exactly what you mean here about how building Qt with Qbs is a trap and that we should not "leak". The trap: From reading your comments, I had the feeling that you're thinking that building

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

Am 13.10.2017 um 14:07 schrieb Jedrzej Nowacki: > On piątek, 13 października 2017 13:04:46 CEST Viktor Engelmann wrote: >> 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

Re: [Development] Future of QBS

A few points: * Unless you are worried about building software with possibly infinite dependencies, infinite build products, then a non-Turing complete language that just lacks general recursion will be sufficiently expressive to meet your needs. In particular, this means those vaguely

Re: [Development] Dropping of MSVC 2013

On 18 October 2017 at 07:51, Thiago Macieira wrote: > This came up again in QtCS and we decided that dropping it soon is probably a > good idea, especially after Qt 5.9 became LTS. > > Did we decide on 5.10 or 5.11? > > Because one of my changes for 5.10 is currently

[Development] Dropping of MSVC 2013

This came up again in QtCS and we decided that dropping it soon is probably a good idea, especially after Qt 5.9 became LTS. Did we decide on 5.10 or 5.11? Because one of my changes for 5.10 is currently failing on MSVC 2013 as designed. I need to refactor it for it to compile there. Do I

Re: [Development] Dropping of MSVC 2013

On Tuesday, 17 October 2017 21:54:40 PDT Ville Voutilainen wrote: > On 18 October 2017 at 07:51, Thiago Macieira wrote: > > This came up again in QtCS and we decided that dropping it soon is > > probably a good idea, especially after Qt 5.9 became LTS. > > > > Did we

Re: [Development] Dropping of MSVC 2013

> We were. I'm asking for a quicker decision now, to decide whether I need to > invest time making QRandomGenerator deterministic mode work on MSVC 2013. Did you consider having a policy such as "Feature X is only available for compilers that suports Y" ? (to use sparingly, of course) Philippe

Re: [Development] Dropping of MSVC 2013

Hi, We discussed about this last spring and then the decision was that 5.10 is too early but 5.11 might be possible. br, Jani > -Original Message- > From: Development [mailto:development- > bounces+jani.heikkinen=qt...@qt-project.org] On Behalf Of Thiago Macieira > Sent: keskiviikko

Re: [Development] Dropping of MSVC 2013

On Tuesday, 17 October 2017 22:25:34 PDT Philippe wrote: > > We were. I'm asking for a quicker decision now, to decide whether I need > > to > > invest time making QRandomGenerator deterministic mode work on MSVC 2013. > > Did you consider having a policy such as "Feature X is only available >