[Development] Qt installation prefix path issue

[bhaskar kotha]

Hi,
When I am configuring Qt with
./configure -prefix /home/bkotha/Qt5.4 -hostprefix /home/bkotha/Qt5.4
-bindir /home/bkotha/Qt5.4/bin -libdir /home/bkotha/Qt5.4/lib -headerdir
/home/bkotha/Qt5.4/include -plugindir /home/bkotha/Qt5.4/plugins -importdir
/home/bkotha/Qt5.4/imports -archdatadir /home/bkotha/Qt5.4/lib
-translationdir /home/bkotha/Qt5.4/translations -qmldir
/home/bkotha/Qt5.4/qml


My qmake is creating with full abosolute path.
When I am moving installed Qt rootfs into other user account
i.e. /home/rajesh/Qtrootfs,  then compiling my qt sample  application with
/home/rajesh/Qtrootfs path, but qmake looking includes path from
 /home/bkotha/Qt5.4/include .

How to configure Qt so that Qmake should not take absolute path.

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

Re: [Development] Future of QBS

[Jake Petroules]

> On Oct 18, 2017, at 12:48 AM, Christian Gagneraud  wrote:
> 
> The trap:
> From reading your comments, I had the feeling that you're thinking that 
> building Qt with Qbs will help having a better Qt/Qbs integration when 
> building the user's project.
> I think it's dangerous, the 3 things are orthogonal: building Qt with Qbs, 
> Qbs having a build dependency on Qt, and user using Qbs to build their 
> Qt-dependent (or not) own projects.

You're right, they are orthogonal. The Qt module files happen to be located in 
the qbs repository right now. The Qt module files, long term, should be located 
with or generated by the build of Qt itself. For the latter case, building Qt 
with Qbs implies that that will become the reality anyways, which is why I 
strongly associated the two.

Of course, we could do it *now* even when still building with qmake, but there 
would be no point doing things in that order. Just like there are CMake files 
shipped with Qt, which exist when Qt is built with qmake, and will continue to 
exist when it's built with Qbs.

So again, we already agree - it's just a matter of how it's being 
phrased/explained.

> The leak:
> Current Qt build system (qmake) leaks into Qbs via qbs-setup-qt.
> QtC suffers from that as well, I wrote an email about that, when i realised 
> that QtC was indirectly executing the cross-compiler defined in qmake's 
> mkspec and found on the PATH instead of using the one defined in the QtC kit. 
> This is rather scary.

If I didn't say so before, this is entirely temporary. It will go away.

I'm not sure about the Qt Creator case being referenced here, but if you can 
open a bug report that would be helpful.

> Thanks for explaining, maybe this means that Qt should not be a Qbs module. 
> Or it should be a "container" module that gets populated by a probe.

Possibly. This is what I was referring to by "dynamically generate modules at 
runtime". By the way, Qt is not currently one module, it's several dozen.

> The handling of a product dependency on, say, Qt.Widgets, should not be 
> different than a product dependency on boost or whatever library.
> Qbs doesn't have/need a boost module.

And right now, it isn't different. You're confusing the existence of 
qbs-setup-qt with some sort of fundamental hardcoded tie-in to Qt. It's simply 
a helper tool that fills in some module properties. In terms of the high level 
constructs available in the Qbs language, Qt is no more special than anything 
else.

And like I said before, qbs-setup-qt should probably go away eventually.

> Now I understand that Qt is more than the sum of it's libraries/modules, 
> there are moc, qdoc, qrc, uic, Qml, ... too. And this make the job harder.

Not necessarily. The non-Qt related things are in many ways more difficult than 
the Qt parts.

>> Qbs != Qt is a "problem"? I'm not sure what you mean. The decoupling
>> of Qbs and Qt is a strength, and it seems like you already agree with
>> that...
> 
> I agree that it would be a strength, if Qbs and Qt were not tightly coupled.
> 
> My understanding is that Qbs can be used on non Qt-dependent projects 
> (bare-metal or not), nice. But this doesn't make Qbs completely decoupled 
> from Qt, because as soon as I need Qt for my project, the whole "q" kitchen 
> sink get pulled in. This is not a Qbs-specific problem tho.

Indeed, Qbs can be used for non-Qt projects and this is the default case 
(unlike qmake where it must be explicitly turned OFF).

I don't understand why you think this doesn't make Qbs completely decoupled 
from Qt though. You're saying that Qbs isn't decoupled from Qt because if you 
need Qt for your project... Qt gets pulled in? That doesn't make any sense. Can 
you provide a more concrete example?

>> Hey, positive *and* negative (but constructive) feedback is always
>> welcome. :)
> 
> This was not even negative, i am not satisfied with all the build systems 
> I've tried so far, but it's OK, such is life! :)
> 
> What I like with Qbs is the flexibility and its structured yet dynamic 
> language (Qml-ish).
> But I'm having scalability and performance issues, that's another story that 
> i will report on the Qbs mailing list once i'm back on my Qbs stuff.

Anything in this area is something we want to address. So please so provide 
specific feedback for any issues you're running into.
-- 
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

Re: [Development] Dropping of MSVC 2013

[Lars Knoll]

> On 18 Oct 2017, at 07:43, Thiago Macieira  wrote:
> 
> 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
>> for compilers that suports Y" ? (to use sparingly, of course)
> 
> Yes. New features are allowed to appear ony on compilers that support certain 
> C++ features.
> 
> That's not an option for this case, since I'm trying to get rid of the 
> qrand() 
> uses and we need QRandomGenerator in QHash.

Since you need the patch to work on 5.10, I think we’ll need a workaround for 
VS2013. 

Since this is replacing qrand(), and it’s only going to get used for one minor 
release (as I believe we should drop the compiler for 5.11), I’d be ok if it 
used the implementation that we had for qrand(), or something similar.

Lars

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

Re: [Development] Dropping of MSVC 2013

[Thiago Macieira]

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
> for compilers that suports Y" ? (to use sparingly, of course)

Yes. New features are allowed to appear ony on compilers that support certain 
C++ features.

That's not an option for this case, since I'm trying to get rid of the qrand() 
uses and we need QRandomGenerator in QHash.

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

Re: [Development] Dropping of MSVC 2013

[Jani Heikkinen]

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 18. lokakuuta 2017 7.51
> To: development@qt-project.org
> Subject: [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 need to implement it? Or shall we drop that compiler?
> --
> 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

Re: [Development] Dropping of MSVC 2013

[Philippe]

> 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

On Tue, 17 Oct 2017 22:13:19 -0700
Thiago Macieira  wrote:

> 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 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 need to implement it? Or shall we drop that compiler?
> > 
> > Weren't we planning to look at the download stats first?
> 
> 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.
> 
> -- 
> 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

Re: [Development] Dropping of MSVC 2013

[Thiago Macieira]

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 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 need to implement it? Or shall we drop that compiler?
> 
> Weren't we planning to look at the download stats first?

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.

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

Re: [Development] Dropping of MSVC 2013

[Ville Voutilainen]

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 failing on MSVC 2013 as
> designed. I need to refactor it for it to compile there.
>
> Do I need to implement it? Or shall we drop that compiler?

Weren't we planning to look at the download stats first?
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

[Development] Dropping of MSVC 2013

[Thiago Macieira]

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 need to implement it? Or shall we drop that compiler?
-- 
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

Re: [Development] Future of QBS

[Christian Gagneraud]

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 Qt with Qbs will help having a better Qt/Qbs integration when 
building the user's project.
I think it's dangerous, the 3 things are orthogonal: building Qt with 
Qbs, Qbs having a build dependency on Qt, and user using Qbs to build 
their Qt-dependent (or not) own projects.


The leak:
Current Qt build system (qmake) leaks into Qbs via qbs-setup-qt.
QtC suffers from that as well, I wrote an email about that, when i 
realised that QtC was indirectly executing the cross-compiler defined in 
qmake's mkspec and found on the PATH instead of using the one defined in 
the QtC kit. This is rather scary.




My point was that the Qbs module files to describe the various Qt
libraries must come from somewhere - either as a probe-based module
within Qbs, an installation of Qt itself, or a combination. If we
rely solely on probe-based modules within Qbs, then we need a way to
dynamically generate modules at runtime (since we can't know about Qt
modules which don't yet exist), which is currently not possible. This
could end up being useful in the general case too, or maybe it isn't,
but like any major architectural decision, it needs time and
thought.


Thanks for explaining, maybe this means that Qt should not be a Qbs 
module. Or it should be a "container" module that gets populated by a probe.
The handling of a product dependency on, say, Qt.Widgets, should not be 
different than a product dependency on boost or whatever library.

Qbs doesn't have/need a boost module.

Now I understand that Qt is more than the sum of it's libraries/modules, 
there are moc, qdoc, qrc, uic, Qml, ... too. And this make the job harder.





We (at work) all want this, the only problem with qbs are: -
stability (not blaming qbs, I knew I picked up an on going effort) 
- Qbs != Qt


Qbs != Qt is a "problem"? I'm not sure what you mean. The decoupling
of Qbs and Qt is a strength, and it seems like you already agree with
that...


I agree that it would be a strength, if Qbs and Qt were not tightly coupled.

My understanding is that Qbs can be used on non Qt-dependent projects 
(bare-metal or not), nice. But this doesn't make Qbs completely 
decoupled from Qt, because as soon as I need Qt for my project, the 
whole "q" kitchen sink get pulled in. This is not a Qbs-specific problem 
tho.





- CI: can qbs solve Windows PC, Linux pc and arbitratly SoC tuned
embedded Linux builds w/o relying on qmake?

I have hope, of all the cross-build systems I have used in the past
15 years, none have been satisfactory, could qbs make a break
through?


Hey, positive *and* negative (but constructive) feedback is always
welcome. :)


This was not even negative, i am not satisfied with all the build 
systems I've tried so far, but it's OK, such is life! :)


What I like with Qbs is the flexibility and its structured yet dynamic 
language (Qml-ish).
But I'm having scalability and performance issues, that's another story 
that i will report on the Qbs mailing list once i'm back on my Qbs stuff.



Chris

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

[Robert Löhning]

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 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
>>
>>  1. Allow approving your own commits under certain circumstances. examples:
>>  1. when you only changed minor things like a variable name (except
>> in public API), a string, a comment or qdoc entry
>>  2. 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 )
>>  3. 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.
>>  4. or more general: when you only made an autotest harder to pass -
>> like adding a Q_VERIFY, Q_COMPARE, etc.
>>  5. when the change is something auto-generated - like you just
>> updated plugins.qmltypes using qmlplugindump
>>  6. when you only changed something in accordance to the guidelines
>> - like Q_DECL_OVERRIDE -> override
>>  7. when you have a certain count of +1's from people who have
>> approver rights
> That doesn't solve the problem, no brainers are getting review quite quickly. 
> Some more detailed comments below:
>  - In 2, you would need to amend the commit message too.
>  - 3 is  at best controversial, do not increase timeouts, rewrite the test 
> instead.
>  - I'm not convinced with 4, it may happen that one is enforcing wrong or 
> invalid behaviour.
>  - I'm afraid that as a result of 7 people will not give +1s anymore :-)
> Review as a process is good, it may be annoying but it is proven to increase 
> quality of the code.
> 
>>  2. 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!
> I like how you believe in CI, I share it, but check our test coverage, we are 
> far from perfect.
> 
>>  3. 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.
> The sentence suggests that we have code review process to cut CI expenses, 
> that is simply not true. Anyway, it is not that easy as you wrote there are 
> limits of scalability.

First of all I'd like to thank Viktor for figuring out ways to improve
our review process and getting the discussion going.

While it seems that mostly everything has been said about the other
bullet points, I'd like to comment on points 2 and 3. I get the
impression that these encourage people to trust in CI far too much. My
understanding is that the developers writing code should make sure that
everything they wrote does what they expect. If anything is unclear, the
issue should be discussed with others who know more about the affected
code or its influences. At the time someone stages a change at least
this person and the person giving +2 should be completely convinced that
the patch is free of mistakes. They should act as if no CI ever existed.

Of course, as human beings, we all make mistakes and no matter how
convinced someone is of their work results, they might turn out to be
wrong. To address this, we have the CI, we have RTA, we have manual
tests. These are there to find the remaining errors which slip through.
At least this how I see them. Using them as the judge whether a patch is
good or not, is way beyond what they are intended for. Please correct me
if I'm mistaken.

Cheers,
Robert

> 
>>  4. I don't think we need to be as paranoid towards contributions from
>> our own employees as we need to be towards external contributions.
> I do not agree. An employer name does not matter.
> 
>>  5. 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, s

Re: [Development] Future of QBS

[Adam Treat]

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 
worrying about "sufficiently complex" build systems can rest assured. If 
a strongly normalizing language can suffice as the internal language to 
build a new foundation for ZFC set theory, then I think it'd be 
sufficient to express a deterministic build system.


* Of course you can work around the halting problem so that Qt Creator 
(or some other IDE) doesn't hang should a build never halt. The point of 
non-Turing complete language is that you could ensure this by design.


That said, I think the Turing-completeness question and halting problem 
should be low on the list of priorities for qbs.


Cheers,
Adam

On 10/17/2017 01:16 PM, André Somers 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
built, while my sucky laptop CPU does not and the build fails for me.

A simple timeout may be a bit too pragmatic, but you could count the
JS instructions executed.


you guys are discussing the locks of a house without walls. when any
type of reasonable limiter needs to kick in, the your build system is
*broken*. that's a fatal error, not just a "different result", and you
need to rethink what you're doing.

Could you clear up what you mean *exactly* here?
Do you mean 1) that any system that provides some kind of timeout (in
terms of wall time or another measure) for evaluation is broken, or that
2) a build setup that runs into such a timeout is broken? That's a big
difference.

_I_ think that doing 1) is reasonable to keep a IDE like Creator
responsive. And of course, you report an error and fail the build when
that happens. A message stating where the issue occured would of course
be very helpfull.

André

___
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

Re: [Development] Future of QBS

[André Somers]

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 crunches through the JS and you get a working
>>> built, while my sucky laptop CPU does not and the build fails for me.
>> A simple timeout may be a bit too pragmatic, but you could count the
>> JS instructions executed.
>>
> you guys are discussing the locks of a house without walls. when any
> type of reasonable limiter needs to kick in, the your build system is
> *broken*. that's a fatal error, not just a "different result", and you
> need to rethink what you're doing.
Could you clear up what you mean *exactly* here?
Do you mean 1) that any system that provides some kind of timeout (in
terms of wall time or another measure) for evaluation is broken, or that
2) a build setup that runs into such a timeout is broken? That's a big
difference.

_I_ think that doing 1) is reasonable to keep a IDE like Creator
responsive. And of course, you report an error and fail the build when
that happens. A message stating where the issue occured would of course
be very helpfull.

André

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

Re: [Development] QtCS 2017 QtCore sessions

[Thiago Macieira]

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
> > 
> > auto s = lineedit.text().left(n);
> > s valid?
> > 
> > * We can be flexible on having exceptions:
> > ** The API needs to be specifically designed for dealing with
> > references
> > ** Clear naming, such as QRegularExpression::captureView()
> > 
> > Discussion not finished
> 
> I certainly hope so, because the above does not make any sense. See my
> talk at QtWS. Returning QStringView is not different from c.begin() or
> str.data(). You need to document the lifetime of the data, that's it.

Indeed, docs and proper documentation naming is required. We just concluded 
something we already knew: we need to avoid surprises. So when there's no 
benefit to returning QStringView, return QString.

> In fact, I'm slowly moving to the conclusion that APIs should, in
> general, not be formulated in terms of owning containers, except, maybe,
> in areas where data is typically shared between classes, but even then
> only in addition, as an extension. In Sean Parent's terms: "Goal: no raw
> containers". Classes should accept and return views, and use whatever
> data structure is most efficient for them, internally. A prime example
> of the cleanup this provides is QRegion::begin/end(). Before you had to
> call .rects(), forcing a memory allocation for the common case where the
> region is just one rectangle. Not only is begin()/end() more efficient,
> it's also easier to use:

I don't doubt it. But, again, case-by-case basis. The performance improvement 
would be very nice to have, but that needs to be coupled with the API 
complexity and the not painting ourselves into a corner should we later decide 
to change internals.

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

Re: [Development] Future of QBS

[Giuseppe D'Angelo]

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 qt-project isn't in the business of maintaining JavaScript engines
or build systems, this model works now because TQC has manpower, but if
something bad happens in 10 years, then it will be a maintenance burden
and rot.

So IMHO, no updating QtScript with newer JavaScriptCore and no adapting
the QML/V4 engine, go straight for pure JavaScriptCore/JerryScript and
no linking to Qt.


This means, amongst other things:

* Get a proper website for qbs under qbs.io (the domain already exist, 
but now it just redirects to the docs)
* Host all the qbs-related resources there: mailing lists, 
documentation, blogs, forums
* For the end-user, remove all references to qbs as existing under the 
Qt umbrella (for the developer _of_ qbs, then it's perhaps acceptable to 
push patches to Qt's gerrit).


I'm firmly convinced that doing all of this is even more important than 
whatever rant you might have about using JavaScript or LUA or some other 
programming language.




(Small story: when I presented Qt Creator at CppCon last year, people's 
reactions were always these two:


1) "Oh, wait, it's a general purpose IDE? It's not just for building Qt 
applications?"

2) "Where's the download link?"

Needless to say, it's a marketing/political failure in both cases.)


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



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

Re: [Development] QtCS 2017 QtCore sessions

[Marc Mutz]

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 exceptions:
** The API needs to be specifically designed for dealing with 
references

** Clear naming, such as QRegularExpression::captureView()

Discussion not finished


I certainly hope so, because the above does not make any sense. See my 
talk at QtWS. Returning QStringView is not different from c.begin() or 
str.data(). You need to document the lifetime of the data, that's it.


In fact, I'm slowly moving to the conclusion that APIs should, in 
general, not be formulated in terms of owning containers, except, maybe, 
in areas where data is typically shared between classes, but even then 
only in addition, as an extension. In Sean Parent's terms: "Goal: no raw 
containers". Classes should accept and return views, and use whatever 
data structure is most efficient for them, internally. A prime example 
of the cleanup this provides is QRegion::begin/end(). Before you had to 
call .rects(), forcing a memory allocation for the common case where the 
region is just one rectangle. Not only is begin()/end() more efficient, 
it's also easier to use:


for (auto rect : region) { ... }

vs.

for (auto rect : region.rects()) { ... } // oops, detach

const auto rects = region.rects();
for (auto rect : rects) { ... } // OK

we even had code that did

if (region.rectCount() == 1)
   doSomethingWith(region.boundingRect()):
else
   Q_FOREACH(QRect r : region.rects())
  doSomethingWith(r);

presumably because the memory allocation made itself heard there.

When this is done throughout the code base, Qt will become easier to 
use, and more efficient, and the pattern will be as imbued into 
developer's brains as is being()/end() now.


And there's always static checkers for the odd error.

Thanks,
Marc

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

Re: [Development] Future of QBS

[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 crunches through the JS and you get a working
> > built, while my sucky laptop CPU does not and the build fails for me.
> 
> A simple timeout may be a bit too pragmatic, but you could count the
> JS instructions executed.
>
you guys are discussing the locks of a house without walls. when any
type of reasonable limiter needs to kick in, the your build system is
*broken*. that's a fatal error, not just a "different result", and you
need to rethink what you're doing.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Future of QBS

[Christian Kandeler]

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 a working
> > built, while my sucky laptop CPU does not and the build fails for me.  
> 
> A simple timeout may be a bit too pragmatic, but you could count the JS 
> instructions executed.

Whatever happened to pressing "Cancel"?


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

Re: [Development] Future of QBS

[Ulf Hermann]

>> 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 simple timeout may be a bit too pragmatic, but you could count the JS 
instructions executed.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Future of QBS

[Tobias Hunger]

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 may be Turing-complete, but that does not
>> mean the code in control of executing it has to let it run indefinitely.
>
>
> 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.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Future of QBS

[Lisandro Damián Nicanor Pérez Meyer]

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 
to build qbs) to accept it. Else it would be a nightmare to maintain.

Much like qmake actually does if I understand correctly.


-- 
"If I have been able to see farther, it was only because I stood on the
shoulders of giants"
 Sir Isaac Newton

Lisandro Damián Nicanor Pérez Meyer
http://perezmeyer.com.ar/
http://perezmeyer.blogspot.com/


signature.asc
Description: This is a digitally signed message part.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

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

[iman ahmadvand]

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 pretty sure it isn't possible with existing
widgets style ! as we should have some new widgets (e.g SnackBar)
But i will think twice for minimal API changes.

Regards.
Iman.

On Tue, Oct 17, 2017 at 3:35 PM, Shawn Rutledge 
wrote:

>
> > 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 add to Qt Play
> ground.
> >
> > So as you probably guessed my plan is to developing a new widget module
> (which I’m going to name it MaterialWidgets) for Qt, a modern collection of
> widgets that should have the same look and feel on all platforms. All the
> GUI parameters and styles are taken from material style guide line(
> https://material.io/guidelines). You can think of MaterialWidgets as the
> MaterialStyle in QML design but in pure C++.
> >
> > Here is a few things to clarify:
> > 1.Why someone need to use material styled widgets in Qt?
> > There are a bunch of app out there that need this to be available on
> widgets so they can easily take the benefit of newly added widget set.
> >
> > 2.Why a new widget set? why just no to use already built-in styles?
> > Material widgets are going to be a special set of controls which has
> animations by default,
>
> Animations need to be done on the GPU, IMO, and the scene graph is a fine
> vehicle for that.  If you are thinking of doing animations on the CPU with
> QPainter, I think that is a waste of CPU cycles, and you might have trouble
> making it smooth enough anyway.
>
> And that is one reason (among others) I think it’s a good idea to
> stabilize the scene graph API with the goal of eventually making it public:
> we could try to build a widget style which uses the scene graph for
> rendering.  (Disclaimer: I haven’t tried, and probably widgets would need a
> lot of re-architecting to standardize that way of styling.  But wouldn’t it
> be nice?)
>
> > and GUI parameters are differs from built-in QtWidgets. for an example
> material style has a component called ContinuousSlider which has two sub
> component Thumb and Track and two state On(value == 0) and Off(value != 0)
> and a color palette for each state, so doing this with styles can't be done
> unless we change the enumerators and maybe more!
>
> Maybe it’s still worthwhile to try though, and see just how much API
> change is really needed.
>
> QSS exposes the ability to style sub-components which aren’t otherwise
> exposed in the API, after all.  (These pages explain it a bit:
>
> http://doc.qt.io/qt-5/style-reference.html#sliders
>
> http://doc.qt.io/qt-5/stylesheet-reference.html
>
> http://doc.qt.io/qt-5/stylesheet-examples.html#customizing-qslider  )
>
> ___
> 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

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

[Thiago Macieira]

On terça-feira, 17 de outubro de 2017 06:25:48 PDT Konstantin Tokarev wrote:
> > Writing the comment is the key here. We just have -2, -1, +1, +2
> > available, so a '+1' can mean everything from 'I had barely a look' to 'I
> > just checked parts of it' to 'I think the patch is flawless, but just
> > maybe someone else wants to review it, too' .
> It's possible to configure more labels to vote for beyound Code-Review and
> Sanity-Review, see
> 
> https://codereview.qt-project.org/Documentation/config-labels.html

It is, but it gets a lot more confusing quickly, so I question the benefit of 
adding more labels. There's a reason the Sanity Review is hidden by default...

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

Re: [Development] Future of QBS

[Matthew Woehlke]

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
>>
>> CMake is a mature tool with a long history, so of course it has to be
>> backwards compatible. The fact that old projects still compile is a great
>> feature (CMake is a lot better at backwards compatibility than, e.g.,
>> autotools) and should not be held against it. CMake does support newer,
>> better ways to do things.
> 
> And makes very little effort to drop this legacy, even with major releases

Sorry, which part of "backwards compatible" did you not understand?

The same can be said of C++, and for the same reasons.

-- 
Matthew

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

Re: [Development] Future of QBS

[Konstantin Tokarev]

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 of types. In particular, the cache variables (i.e.,
>>  the variables you can set on the command line, which are also cached across
>>  invocations) have a type.
>
> That's... misleading. The only time when those "types" matter is when
> you are using cmake-gui; they influence the convenience widgets that
> cmake-gui uses to assist users in providing appropriate values.
>
> Internally, everything is a string.
>
>>>  has native support for arrays(!)
>>
>>  That is what the CMake LIST command is for.
>
> ...and yet, internally, everything is a string. "Lists" in CMake tend to
> get mucked up when you need to deal with values that contain the list
> separator token (';'). Real, first-class support for arrays would be a
> welcome improvement.
>
>>>  * 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
>>
>>  CMake is a mature tool with a long history,
>
> ...and another advantage of this is that CMake has solved many, many
> "hard" problems that don't occur to all these folks that want to write
> "new and shiny" tools.

Or problems that just cannot exist with properly designed tool, like
"generator expressions"

>
> Turing completeness is another case in point. You may *say* you don't
> want it... until you run into some problem that you just can't seem to
> solve in your build tool.

+1

>
> --
> 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] Future of QBS

[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 of types. In particular, the cache variables (i.e.,
> the variables you can set on the command line, which are also cached across
> invocations) have a type.

That's... misleading. The only time when those "types" matter is when
you are using cmake-gui; they influence the convenience widgets that
cmake-gui uses to assist users in providing appropriate values.

Internally, everything is a string.

>> has native support for arrays(!)
> 
> That is what the CMake LIST command is for.

...and yet, internally, everything is a string. "Lists" in CMake tend to
get mucked up when you need to deal with values that contain the list
separator token (';'). Real, first-class support for arrays would be a
welcome improvement.

>> * 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
> 
> CMake is a mature tool with a long history,

...and another advantage of this is that CMake has solved many, many
"hard" problems that don't occur to all these folks that want to write
"new and shiny" tools.

Turing completeness is another case in point. You may *say* you don't
want it... until you run into some problem that you just can't seem to
solve in your build tool.

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

[Development] Small clarification

[Sean Harmer]

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 purely 
technical and to prevent accidental approval based on my previous +2 as 
I since thought of some alternatives.


Kind regards,

Sean
--
Dr Sean Harmer | sean.har...@kdab.com | Managing Director UK
KDAB (UK) Ltd, a KDAB Group company
Tel. +44 (0)1625 809908; Sweden (HQ) +46-563-540090
Mobile: +44 (0)7545 140604
KDAB - Qt Experts
___
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]

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 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
>>  reviewed the documentation.
>>
>>  Is this the right way to do it? Maybe it should be formalized in the system.
>
> Yes, I think this is the right way.
>
> Writing the comment is the key here. We just have -2, -1, +1, +2 available, 
> so a '+1' can mean everything from 'I had barely a look' to 'I just checked 
> parts of it' to 'I think the patch is flawless, but just maybe someone else 
> wants to review it, too' .

It's possible to configure more labels to vote for beyound Code-Review and 
Sanity-Review, see

https://codereview.qt-project.org/Documentation/config-labels.html

>
> So, given the limited options, let's just state explicitly what you mean when 
> giving a review. While at it, consider also to mention positive things, so 
> people don't feel like they only ever get negative feedback.
>
> My 2 cents,
>
> Kai
>
> ___
> 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)

[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 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
> reviewed the documentation.
> 
> Is this the right way to do it? Maybe it should be formalized in the system.

Yes, I think this is the right way. 

Writing the comment is the key here. We just have -2, -1, +1, +2 available, so 
a '+1' can mean everything from 'I had barely a look' to 'I just checked parts 
of it' to 'I think the patch is flawless, but just maybe someone else wants to 
review it, too' .

So, given the limited options, let's just state explicitly what you mean when 
giving a review. While at it, consider also to mention positive things, so 
people don't feel like they only ever get negative feedback.

My 2 cents,

Kai

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

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 
> documentation is ok, I give the change a +1 and add a comment that I only 
> reviewed the documentation.
>
> Is this the right way to do it? Maybe it should be formalized in the system.

FWIW it's possible to teach Gerrit to require +2 from someone from doc team if 
commit message has "documentation change" tag [1], but require another +2 to 
allow submit.

[1] Enforceable with sanity bot, or maybe can even be done automatically.

>
> martin
> 
> From: Development  on 
> behalf of Viktor Engelmann 
> Sent: Friday, October 13, 2017 1:04:46 PM
> To: development@qt-project.org
> Subject: [Development] Speeding up the review process (was: PostgreSQL cross 
> compile for Pi)
>
> 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
>
>   1. 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 )
>  * 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
>   2. 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!
>   3. 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.
>   4. I don't think we need to be as paranoid towards contributions from our 
> own employees as we need to be towards external contributions.
>   5. 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://l

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

[Konstantin Tokarev]

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 thoughts 
>> about design decision for the new module I’m trying to add to Qt Play ground.
>>
>>  So as you probably guessed my plan is to developing a new widget module 
>> (which I’m going to name it MaterialWidgets) for Qt, a modern collection of 
>> widgets that should have the same look and feel on all platforms. All the 
>> GUI parameters and styles are taken from material style guide 
>> line(https://material.io/guidelines). You can think of MaterialWidgets as 
>> the MaterialStyle in QML design but in pure C++.
>>
>>  Here is a few things to clarify:
>>  1.Why someone need to use material styled widgets in Qt?
>>  There are a bunch of app out there that need this to be available on 
>> widgets so they can easily take the benefit of newly added widget set.
>>
>>  2.Why a new widget set? why just no to use already built-in styles?
>>  Material widgets are going to be a special set of controls which has 
>> animations by default,
>
> Animations need to be done on the GPU, IMO, and the scene graph is a fine 
> vehicle for that. If you are thinking of doing animations on the CPU with 
> QPainter, I think that is a waste of CPU cycles, and you might have trouble 
> making it smooth enough anyway.

BTW in Qt 4 times QPixmap was accelerated on some platforms, so it was possible 
to make such widget animations fast...

>
> And that is one reason (among others) I think it’s a good idea to stabilize 
> the scene graph API with the goal of eventually making it public: we could 
> try to build a widget style which uses the scene graph for rendering. 
> (Disclaimer: I haven’t tried, and probably widgets would need a lot of 
> re-architecting to standardize that way of styling. But wouldn’t it be nice?)
>
>>  and GUI parameters are differs from built-in QtWidgets. for an example 
>> material style has a component called ContinuousSlider which has two sub 
>> component Thumb and Track and two state On(value == 0) and Off(value != 0) 
>> and a color palette for each state, so doing this with styles can't be done 
>> unless we change the enumerators and maybe more!
>
> Maybe it’s still worthwhile to try though, and see just how much API change 
> is really needed.
>
> QSS exposes the ability to style sub-components which aren’t otherwise 
> exposed in the API, after all. (These pages explain it a bit:
>
> http://doc.qt.io/qt-5/style-reference.html#sliders
>
> http://doc.qt.io/qt-5/stylesheet-reference.html
>
> http://doc.qt.io/qt-5/stylesheet-examples.html#customizing-qslider )
>
> ___
> 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] Review for new widget module [your advices are needed]

[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 thoughts 
> about design decision for the new module I’m trying to add to Qt Play ground.
> 
> So as you probably guessed my plan is to developing a new widget module 
> (which I’m going to name it MaterialWidgets) for Qt, a modern collection of 
> widgets that should have the same look and feel on all platforms. All the GUI 
> parameters and styles are taken from material style guide 
> line(https://material.io/guidelines). You can think of MaterialWidgets as the 
> MaterialStyle in QML design but in pure C++.
> 
> Here is a few things to clarify:
> 1.Why someone need to use material styled widgets in Qt?
> There are a bunch of app out there that need this to be available on widgets 
> so they can easily take the benefit of newly added widget set.
> 
> 2.Why a new widget set? why just no to use already built-in styles?
> Material widgets are going to be a special set of controls which has 
> animations by default,

Animations need to be done on the GPU, IMO, and the scene graph is a fine 
vehicle for that.  If you are thinking of doing animations on the CPU with 
QPainter, I think that is a waste of CPU cycles, and you might have trouble 
making it smooth enough anyway.

And that is one reason (among others) I think it’s a good idea to stabilize the 
scene graph API with the goal of eventually making it public: we could try to 
build a widget style which uses the scene graph for rendering.  (Disclaimer: I 
haven’t tried, and probably widgets would need a lot of re-architecting to 
standardize that way of styling.  But wouldn’t it be nice?)

> and GUI parameters are differs from built-in QtWidgets. for an example 
> material style has a component called ContinuousSlider which has two sub 
> component Thumb and Track and two state On(value == 0) and Off(value != 0) 
> and a color palette for each state, so doing this with styles can't be done 
> unless we change the enumerators and maybe more!

Maybe it’s still worthwhile to try though, and see just how much API change is 
really needed.

QSS exposes the ability to style sub-components which aren’t otherwise exposed 
in the API, after all.  (These pages explain it a bit:

http://doc.qt.io/qt-5/style-reference.html#sliders

http://doc.qt.io/qt-5/stylesheet-reference.html

http://doc.qt.io/qt-5/stylesheet-examples.html#customizing-qslider  )

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

Re: [Development] Future of QBS

[Jake Petroules]

> 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 just 
> sharing my experience, but it seems I need to justify myself if I don't want 
> to be labelled "what are you smoking", I'm getting really pissed off about 
> that)

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

My point was that the Qbs module files to describe the various Qt libraries 
must come from somewhere - either as a probe-based module within Qbs, an 
installation of Qt itself, or a combination. If we rely solely on probe-based 
modules within Qbs, then we need a way to dynamically generate modules at 
runtime (since we can't know about Qt modules which don't yet exist), which is 
currently not possible. This could end up being useful in the general case too, 
or maybe it isn't, but like any major architectural decision, it needs time and 
thought.

> We (at work) all want this, the only problem with qbs are:
> - stability (not blaming qbs, I knew I picked up an on going effort)
> - Qbs != Qt

Qbs != Qt is a "problem"? I'm not sure what you mean. The decoupling of Qbs and 
Qt is a strength, and it seems like you already agree with that...

> - CI: can qbs solve Windows PC, Linux pc and arbitratly SoC tuned embedded 
> Linux builds w/o relying on qmake?
> 
> I have hope, of all the cross-build systems I have used in the past 15 years, 
> none have been satisfactory, could qbs make a break through?

Hey, positive *and* negative (but constructive) feedback is always welcome. :)
-- 
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

Re: [Development] Future of QBS

[Christian Gagneraud]

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 
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 they
> > will have to deal with external libs and might suffer corner cases.
>
> Indeed, which is why Qbs aims to solve both of those problems. Excellent
Qt support and excellent non-Qt support. Choose both.
>
> > As Qt user I started with qmake, I enjoyed writing projects with qmake
> > then I switched to CMake to make easier usage of non Qt libs and
> > config. Finally I switched to Meson and won't go back to CMake. I'm not
> > sure I would switch to Qbs unless it gets less Qt focused.
>
> You should watch my World Summit talk when it's available on YouTube. :)
>
> One of the key points I talked about and which is very important is that
Qbs is NOT Qt-focused. Is it meant to be a completely generic build tool
which just happens to ship with out-of-the-box Qt support. I've been
working on Qbs for 5 years and have made close to 1000 changes, and for all
of those 5 years I actually haven't worked on the Qt support very much at
all.
>
> Well, from a qbs user POV, Qt is still a privileged component (not
talking about qbs own build dependency here). And "qbs-setup-qt" is the
curlprint.
>
> I don't see why this is needed (in an ideal world). This is actually a
qmake backdoor into qbs. Or call it a high coupling hotspot if you wish.
> Can qbs be used to build a qt dependent project without a qt profile? I
don't think so.
>
> Qt should be detected the same way as any other user's project dependency
(probe link and include specifics), instead qmake is used as a proxy.
>
> In that respect cmake (or any other build system) got it right, qbs got
it wrong.
>
> On Linux, qt should be detected using qbs probe and package-config,
period.
>
> I never liked qbs profile, they are awkward to manage in CI.
>
> Once you have a toolchain and a Qt profile everything is cool, but if you
start from a virgin install (eg. generic docker image), things look bad. I
guess this is a distro integration problem. But "distro" is Linux specific.
Mac and windows are far beyond.

I never liked profiles either, and we have been moving away from them as a
hard requirement. On macOS and Linux you can now build projects without a
profile at all (there might be a bug or two with certain MSVC installations
at the moment) if you don't use Qt.

Getting rid of qbs-setup-qt will take some time, and we still need to find
a solution to the problem of having to hardcode the list of all possible Qt
modules (although when Qt itself is built with Qbs this problem may simply
go away by definition). In fact you could argue right now that Qt is NOT a
privileged component since it requires special additional setup to use it.


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 just
sharing my experience, but it seems I need to justify myself if I don't
want to be labelled "what are you smoking", I'm getting really pissed off
about that)

We have a couple of code bases, one is embedded Linux with Qt (UI/user
facing), others are auxiliary microcontroller and DSP running bare metal
c++.

Qbs could be used for all these projects, I don't see any big technical
difficulties.

All of these projects could benefit from qbs and the clang compilation
database plugin I wrote (yeah I can be egocentric too), everyone is asking
for auto SQA.

We (at work) all want this, the only problem with qbs are:
- stability (not blaming qbs, I knew I picked up an on going effort)
- Qbs != Qt
- CI: can qbs solve Windows PC, Linux pc and arbitratly SoC tuned embedded
Linux builds w/o relying on qmake?

I have hope, of all the cross-build systems I have used in the past 15
years, none have been satisfactory, could qbs make a break through?

Chris




But don't mistake this as a "fundamental design flaw", it's always been a
temporary solution. We have top men working on it right now... top men.

>
> Chris
>
>
>
> > I still miss the point of making a dedicated build system instead of
> > contributing to more general build systems like Meson or even CMake.
>
> Qbs is just as general as both of those, and in my opinion, even more so.
Please, try it out - you may be surprised!
> --
> 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

--
Jake Petroules - jake.petrou...@qt.io
The Qt Company - Silic

Re: [Development] Future of QBS

[Konstantin Tokarev]

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 SET_*_PROPERTIES CMake commands are for.
>>  The verbose syntax allows you to see immediately what type of object you are
>>  getting or setting properties of.
>
> Try doing some non-trivial operations on properties, e.g. appending value if 
> it is not
> present in the list already, or remove some value from the list, and code 
> quickly
> becomes unhealthy

Not to mention that you have to create temporary local variable every time you 
simply want
to use property.

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

Re: [Development] Future of QBS

[Konstantin Tokarev]

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 build anything
> with it, whereas a build system in C++ such as CMake just works.

Python interpreter is C program, so you don't even need C++ compiler
to build it.

Though Lua is certainly nicer in this aspect, as it's much smaller and can
be easily shipped as a part of build tool itself.

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

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 Premake's project
>>  structure, and run it with all of Premake from inside Creator's plugin, by
>>  linking liblua.
>
> Of course. Invoking the actual build system to get data out of it is also
> how the CMake support in KDevelop 5 works.
>
> That, however, does not address the Turing-completeness issue, as it will
> crash (lock up) your IDE if the code in the build system does not terminate,
> which can happen if the language is Turing-complete.

I would claim that build system script that does not terminate is invalid.
And you can always use good old timeouts to prevent pathological cases.

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

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.,
> the variables you can set on the command line, which are also cached across
> invocations) have a type.

Maybe, but when script is running, everything behaves as a string in fact.
Hell, it doesn't even distinct strings and target names.

>
>>  has native support for arrays(!)
>
> That is what the CMake LIST command is for.

Oh really? CMake lists are just concatenated strings with ";" separators inside,
and there are cases when you have to take this fact into account.

>
>>  and functions/methods have first-class return values(!)
>
> The CMake pattern of taking a result variable name (which is written to via
> indirection) does the job and also allows having more than one return value.
>
>>  * Its language has native support for properties, with syntax that really
>>  looks like properties in another languages
>
> That is what the GET_*_PROPERTY and SET_*_PROPERTIES CMake commands are for.
> The verbose syntax allows you to see immediately what type of object you are
> getting or setting properties of.

Try doing some non-trivial operations on properties, e.g. appending value if it 
 is not
present in the list already, or remove some value from the list, and code 
quickly
becomes unhealthy

>
>>  * 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
>
> CMake is a mature tool with a long history, so of course it has to be
> backwards compatible. The fact that old projects still compile is a great
> feature (CMake is a lot better at backwards compatibility than, e.g.,
> autotools) and should not be held against it. CMake does support newer,
> better ways to do things.

And makes very little effort to drop this legacy, even with major releases

>
> What will happen to Meson in a few years? Will it break compatibility with
> all the existing projects using it? Or will it be just as burdened by legacy
> functionality as CMake? It is one or the other.
>
>>  * It is written in scripting language, so it's easier to add
>>  (and possibly distribute) new functionality without getting it through
>>  upstream hands first.
>
> Meson actually makes it a point that you should not do that and that being
> implemented in Python is an implementation detail:
> http://mesonbuild.com/FAQ.html#why-is-meson-not-just-a-python-module-so-i-could-code-my-build-setup-in-python
>
> Being written in a scripting language also means that it is slower than if
> it were written in C++ as CMake is. Even in their own benchmarks:
> http://mesonbuild.com/Simple-comparison.html
> Meson itself takes longer to run than CMake (for Ninja output, which is what
> Meson also outputs). (That said, the produced Ninja output is marginally
> faster, enough to compensate the longer runtime of Meson. But that is
> unrelated to the implementation language.)

It's doesn't make much sense to optimize such tools hard: generator runs only
when build system files are modified, and rest of the time incremental builds 
just
execute ninja.

Fact that cmake is implemented in C++ just makes it less extensible, and make 
it's
ugly internal architecture even more rigid.

>
> 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] Qt6 and QCA

[Richard Moore]

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, "Lars Knoll"  wrote:
>
>> Hi,
>>
>> QCA is being developed outside of qt-project, so we can't easily add it
>> to Qt. Better crypto support would IMO be great to have, but I currently
>> don't think there's any active work ongoing in this area.
>>
>> Cheers,
>> Lars
>>
>> PS: Just as a side note: Adding better crypto support is something we
>> could do without problems in the 5.x series, no need to think about Qt 6
>> because of that :)
>>
>>
>> > On 12 Oct 2017, at 10:58, Tomaz Canabrava  wrote:
>> >
>> > Hello,
>> >
>> > After reading thiago's tougths about the QRandomGenerator I wonder
>> about the status of the Qt Cryptographic Architecture. From what I know
>> it's not a Qt project but it's whidely used for applications that depend on
>> cryptography and ssl, but not activelly maintained.
>> >
>> > There are plans to actually integrate the QCA into Qt as a module - or
>> something similar?
>> >
>> > Best,
>> > Tomaz
>> >
>> >
>> > ___
>> > 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

Re: [Development] Future of QBS

[Jake Petroules]

> 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 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 they
> > will have to deal with external libs and might suffer corner cases.
> 
> Indeed, which is why Qbs aims to solve both of those problems. Excellent Qt 
> support and excellent non-Qt support. Choose both.
> 
> > As Qt user I started with qmake, I enjoyed writing projects with qmake
> > then I switched to CMake to make easier usage of non Qt libs and
> > config. Finally I switched to Meson and won't go back to CMake. I'm not
> > sure I would switch to Qbs unless it gets less Qt focused.
> 
> You should watch my World Summit talk when it's available on YouTube. :)
> 
> One of the key points I talked about and which is very important is that Qbs 
> is NOT Qt-focused. Is it meant to be a completely generic build tool which 
> just happens to ship with out-of-the-box Qt support. I've been working on Qbs 
> for 5 years and have made close to 1000 changes, and for all of those 5 years 
> I actually haven't worked on the Qt support very much at all.
> 
> Well, from a qbs user POV, Qt is still a privileged component (not talking 
> about qbs own build dependency here). And "qbs-setup-qt" is the curlprint.
> 
> I don't see why this is needed (in an ideal world). This is actually a qmake 
> backdoor into qbs. Or call it a high coupling hotspot if you wish.
> Can qbs be used to build a qt dependent project without a qt profile? I don't 
> think so.
> 
> Qt should be detected the same way as any other user's project dependency 
> (probe link and include specifics), instead qmake is used as a proxy.
> 
> In that respect cmake (or any other build system) got it right, qbs got it 
> wrong.
> 
> On Linux, qt should be detected using qbs probe and package-config, period.
> 
> I never liked qbs profile, they are awkward to manage in CI.
> 
> Once you have a toolchain and a Qt profile everything is cool, but if you 
> start from a virgin install (eg. generic docker image), things look bad. I 
> guess this is a distro integration problem. But "distro" is Linux specific. 
> Mac and windows are far beyond.

I never liked profiles either, and we have been moving away from them as a hard 
requirement. On macOS and Linux you can now build projects without a profile at 
all (there might be a bug or two with certain MSVC installations at the moment) 
if you don't use Qt.

Getting rid of qbs-setup-qt will take some time, and we still need to find a 
solution to the problem of having to hardcode the list of all possible Qt 
modules (although when Qt itself is built with Qbs this problem may simply go 
away by definition). In fact you could argue right now that Qt is NOT a 
privileged component since it requires special additional setup to use it.

But don't mistake this as a "fundamental design flaw", it's always been a 
temporary solution. We have top men working on it right now... top men.

> 
> Chris
> 
> 
> 
> > I still miss the point of making a dedicated build system instead of
> > contributing to more general build systems like Meson or even CMake.
> 
> Qbs is just as general as both of those, and in my opinion, even more so. 
> Please, try it out - you may be surprised!
> --
> 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

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

Re: [Development] Future of QBS

[Joerg Bornemann]

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 let it run indefinitely.


Exactly. The halting problem can be worked around pragmatically.


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

Re: [Development] Future of QBS

[Christian Gagneraud]

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
> not be the best and a Qt focused tool with a good Qt support but they
> will have to deal with external libs and might suffer corner cases.

Indeed, which is why Qbs aims to solve both of those problems. Excellent Qt
support and excellent non-Qt support. Choose both.

> As Qt user I started with qmake, I enjoyed writing projects with qmake
> then I switched to CMake to make easier usage of non Qt libs and
> config. Finally I switched to Meson and won't go back to CMake. I'm not
> sure I would switch to Qbs unless it gets less Qt focused.

You should watch my World Summit talk when it's available on YouTube. :)

One of the key points I talked about and which is very important is that
Qbs is NOT Qt-focused. Is it meant to be a completely generic build tool
which just happens to ship with out-of-the-box Qt support. I've been
working on Qbs for 5 years and have made close to 1000 changes, and for all
of those 5 years I actually haven't worked on the Qt support very much at
all.


Well, from a qbs user POV, Qt is still a privileged component (not talking
about qbs own build dependency here). And "qbs-setup-qt" is the curlprint.

I don't see why this is needed (in an ideal world). This is actually a
qmake backdoor into qbs. Or call it a high coupling hotspot if you wish.
Can qbs be used to build a qt dependent project without a qt profile? I
don't think so.

Qt should be detected the same way as any other user's project dependency
(probe link and include specifics), instead qmake is used as a proxy.

In that respect cmake (or any other build system) got it right, qbs got it
wrong.

On Linux, qt should be detected using qbs probe and package-config, period.

I never liked qbs profile, they are awkward to manage in CI.

Once you have a toolchain and a Qt profile everything is cool, but if you
start from a virgin install (eg. generic docker image), things look bad. I
guess this is a distro integration problem. But "distro" is Linux specific.
Mac and windows are far beyond.

Chris



> I still miss the point of making a dedicated build system instead of
> contributing to more general build systems like Meson or even CMake.

Qbs is just as general as both of those, and in my opinion, even more so.
Please, try it out - you may be surprised!
--
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
___
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)

[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 documentation is 
ok, I give the change a +1 and add a comment that I only reviewed the 
documentation.

Is this the right way to do it? Maybe it should be formalized in the system.

martin

From: Development  on 
behalf of Viktor Engelmann 
Sent: Friday, October 13, 2017 1:04:46 PM
To: development@qt-project.org
Subject: [Development] Speeding up the review process (was: PostgreSQL cross 
compile for Pi)

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

  1.  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 )
 *   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
  2.  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!
  3.  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.
  4.  I don't think we need to be as paranoid towards contributions from our 
own employees as we need to be towards external contributions.
  5.  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

Re: [Development] Clazy results for Qt codebase

[Friedemann Kleint]

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

--
Friedemann Kleint
The Qt Company GmbH

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