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/
> 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
> 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 conside
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
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
> 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 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?
> >
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
> desi
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
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
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
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
worryi
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 crun
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
> >
>
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
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 exceptio
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
> > bui
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,
>> 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 sim
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, bu
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
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 pr
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
>
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
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, t
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
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 pu
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 t
> -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
> a
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 t
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
> 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.
> 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 ex
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 c
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.
>>
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
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,
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 o
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:
>
>>
> 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
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
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
+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 revi
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
44 matches
Mail list logo