No, I don't need empty files ;) I didn't check the git log, just checked which
ones are missing
Br,
Jani
>>-Original Message-
>>From: Alan Alpert [mailto:4163654...@gmail.com]
>>Sent: 10. kesäkuuta 2015 0:08
>>To: Heikkinen Jani
>>Cc: development@qt-project.org; releas...@qt-project.org
Hi Alan. Hi Simon.
On 6/10/15, 4:23 PM, "Alan Alpert" <4163654...@gmail.com> wrote:
>On Wed, Jun 10, 2015 at 6:52 AM, Simon Hausmann
> wrote:
>> On Tuesday, June 09, 2015 01:23:29 PM Alan Alpert wrote:
>>> A brief overview of planned features:
>>> -QML API
>>> -Protocol Layer Adapters
>>> -Invest
On Wed, Jun 10, 2015 at 2:19 PM, Alan Alpert <4163654...@gmail.com> wrote:
> On Wed, Jun 10, 2015 at 1:04 AM, Alan Alpert <4163654...@gmail.com> wrote:
>> I have run qmlRevCheck between the 5.4 and 5.5.0 branches, for the
>> imports in qtdeclarative/src/imports. Results are attached. Results
>> com
On 11 June 2015 at 00:59, Alan Alpert <4163654...@gmail.com> wrote:
> On Wed, Jun 10, 2015 at 8:14 AM, Hausmann Simon
> wrote:
>> Hi,
>>
>> I think renaming the getter to lastError is nice! I however do like error as
>> signal name and it looks good in qml as onError:...
>
> I disagree that it lo
On Tue, Jun 9, 2015 at 11:45 PM, Blasche Alexander
wrote:
>
>> I just went through the git log to confirm. There is nothing of
>> interest to put in the changelog for QtQuick1 or QtScript (I'd be
>> surprised if I found otherwise). Do you really need an empty file
>> there?
>
> I'd say yes. It is
On Wed, Jun 10, 2015 at 1:04 AM, Alan Alpert <4163654...@gmail.com> wrote:
> I have run qmlRevCheck between the 5.4 and 5.5.0 branches, for the
> imports in qtdeclarative/src/imports. Results are attached. Results
> come from generating and parsing new qmltypes files from each branch,
> and compari
Hi,
Ok :) let's try with reduced qmake syntax (just variables, no functions). We
can still fall back to json if it's too clumsy.
I certainly prefer qmake syntax from an editing POV because I don't need to
quote everything like crazy :)
Simon
Original Message
From: Thiago Macieira
Sent: Wed
On Wed, Jun 10, 2015 at 6:52 AM, Simon Hausmann
wrote:
> On Tuesday, June 09, 2015 01:23:29 PM Alan Alpert wrote:
>> There was late-scheduled session on QtRemoteObjects at QtCS on
>> Saturday. QtRemoteObjects is a playground module for object remoting
>> of QObjects, and can be found at
>> http://
On Wednesday 10 June 2015 19:33:37 Hausmann Simon wrote:
> Any particular reason against json, btw? Qmake can read it out of the box,
> as opposed to .ini. So the only other option I can think of is a very very
> limited qmake subset (variable.subvar = value per line and # comment).
Didn't know th
Hi,
Yeah, we used that when we tried to pin reverse dependencies, something we're
not doing anymore.
Any particular reason against json, btw? Qmake can read it out of the box, as
opposed to .ini. So the only other option I can think of is a very very limited
qmake subset (variable.subvar = val
On Wednesday 10 June 2015 18:47:49 Hausmann Simon wrote:
> Hi,
>
> Why do we need to pin anything beyond the regular git submodules handling of
> qt5.git (where the information is in the tree object)?
We used to. Whether we still need to do that in the new CI, you tell me.
> In think we should h
On Wednesday 10 June 2015 21:09:15 Stephen Kelly wrote:
> Is installation of unprefixed headers a release blocker?
Yes. Because the buildsystem will add -I$QTINCDIR/Qt3D, so #include
will find it, possibly clobbering other includes with the name.
So this is a release blocker.
--
Thiago Maciei
Stephen Kelly wrote:
> Sean Harmer wrote:
>
>>> 1) The include/Qt3DCore/Window file doesn't have a Q prefix.
>>>
>>> as every other header does. Should probably be Qt3DWindow.
>>
>> Right, this actually needs removing and something temporary putting in
>> place in the examples for now.
>
>> I'
Stephen Kelly wrote:
> Sean Harmer wrote:
>
>>> 1) The include/Qt3DCore/Window file doesn't have a Q prefix.
>>>
>>> as every other header does. Should probably be Qt3DWindow.
>>
>> Right, this actually needs removing and something temporary putting in
>> place in the examples for now.
>
>> I'
Sean Harmer wrote:
>> 1) The include/Qt3DCore/Window file doesn't have a Q prefix.
>>
>> as every other header does. Should probably be Qt3DWindow.
>
> Right, this actually needs removing and something temporary putting in
> place in the examples for now.
> I'll try to tidy up and move the exi
Hi,
Why do we need to pin anything beyond the regular git submodules handling of
qt5.git (where the information is in the tree object)?
In think we should have a configuration file in each module listing required
and optional dependencies. Qt.pro can interpret that file and so can the CI
syste
On 2015-06-10 10:20, Koehne Kai wrote:
> Hi,
>
> I'm currently converting a codebase from old-style connects to new-style
> ones. Thanks to Qt Creator's refactoring support this is actually quite easy
> ... it gets ugly though when either the signal or slot method name is
> overloaded, and you
On Wed, Jun 10, 2015 at 8:14 AM, Hausmann Simon
wrote:
> Hi,
>
> I think renaming the getter to lastError is nice! I however do like error as
> signal name and it looks good in qml as onError:...
I disagree that it looks good in QML as onError, almost all other
signal handlers are past tense so
On Wednesday 10 June 2015 18:30:34 Frederik Gladhorn wrote:
> 4) qt5.git
> in qt.pro we list all modules again, with deps:
> addModule(qtdeclarative, qtbase, qtsvg qtxmlpatterns)
> (amusingly this is not even correct, qtsvg is not a dependency of
> qtdeclarative any more)
That's an optional depen
On Wednesday 10 June 2015 15:14:07 Hausmann Simon wrote:
> Hi,
>
> I think renaming the getter to lastError is nice! I however do like error as
> signal name and it looks good in qml as onError:...
"onError" screams of Basic to me...
ON ERROR GO SUB foo
or worse
ON ERROR RESUME
I
Hi all,
when talking about how we manage dependencies in the CI system, an interesting
pain point came up during the contributors' summit:
We have several redundant overlapping, not very clear ways of specifying a
module's dependencies. Optional deps make it harder.
I'll list the 5 options I k
Hi,
I think renaming the getter to lastError is nice! I however do like error as
signal name and it looks good in qml as onError:...
Simon
Original Message
From: Thiago Macieira
Sent: Wednesday, June 10, 2015 16:35
To: development@qt-project.org
Subject: Re: [Development] Avoid overloading o
On 10 juin 2015, at 16:20, Koehne Kai wrote:
> Hi,
>
> I'm currently converting a codebase from old-style connects to new-style
> ones. Thanks to Qt Creator's refactoring support this is actually quite easy
> ... it gets ugly though when either the signal or slot method name is
> overloaded,
On Wednesday 10 June 2015 14:20:51 Koehne Kai wrote:
> Hi,
>
> I'm currently converting a codebase from old-style connects to new-style
> ones. Thanks to Qt Creator's refactoring support this is actually quite
> easy ... it gets ugly though when either the signal or slot method name is
> overloade
Hi,
I'm currently converting a codebase from old-style connects to new-style ones.
Thanks to Qt Creator's refactoring support this is actually quite easy ... it
gets ugly though when either the signal or slot method name is overloaded, and
you have to write nice code like
connect(&proc
On Wednesday, June 10, 2015 12:42:32 PM Lorn Potter wrote:
> On 09/06/15 21:59, Simon Hausmann wrote:
> > Hi,
>
> [snip]
>
> Is there a url to see the test results of various platforms/modules?
All the logs of the builds are uploaded to
http://testresults.qt.io/ci/
That has been the case f
On Tuesday 09 Jun 2015 13:09:50 Stephen Kelly wrote:
> On Tue, Jun 9, 2015 at 11:01 AM, Sean Harmer wrote:
> > On Monday 08 Jun 2015 14:18:33 Sean Harmer wrote:
> >> On Monday 08 Jun 2015 01:11:23 Stephen Kelly wrote:
> >> > 2) A private header is included in a public header:
> >> > include/Qt3DC
On Tuesday, June 09, 2015 01:23:29 PM Alan Alpert wrote:
> There was late-scheduled session on QtRemoteObjects at QtCS on
> Saturday. QtRemoteObjects is a playground module for object remoting
> of QObjects, and can be found at
> http://code.qt.io/cgit/playground/qtremoteobjects.git/ .
>
> A brief
Kindly reminder:
All new modules for 5.6 release must be in dev branch before end of june, see
http://lists.qt-project.org/pipermail/releasing/2015-May/001941.html
And please start adding new stuff here as well:
https://wiki.qt.io/New_Features_in_Qt_5.6
br,
Jani
___
I have run qmlRevCheck between the 5.4 and 5.5.0 branches, for the
imports in qtdeclarative/src/imports. Results are attached. Results
come from generating and parsing new qmltypes files from each branch,
and comparing them with the qmlRevCheck tool
(https://codereview.qt-project.org/#/c/114038/ is
30 matches
Mail list logo
