Re: [Development] Qt 5.5.1 'rc' available

[Robert Iakobashvili]

Thank you.

Regards,
Robert


On Thu, Sep 24, 2015 at 11:26 AM, Heikkinen Jani
 wrote:
> Src packages now in http://download.qt.io/snapshots/qt/5.5/5.5.1/latest_src/
>
> Br,
> Jani
>
>>>-Original Message-
>>>From: development-bounces+jani.heikkinen=theqtcompany.com@qt-
>>>project.org [mailto:development-
>>>bounces+jani.heikkinen=theqtcompany@qt-project.org] On Behalf Of
>>>Thiago Macieira
>>>Sent: 23. syyskuuta 2015 22:50
>>>To: development@qt-project.org
>>>Subject: Re: [Development] Qt 5.5.1 'rc' available
>>>
>>>On Wednesday 23 September 2015 08:37:54 Heikkinen Jani wrote:
 Hi all,


 We have finally new Qt 5.5.1 snapshot
 available


 Windows: http://download.qt.io/snapshots/qt/5.5/5.5.1/153/

 Linux: http://download.qt.io/snapshots/qt/5.5/5.5.1/190/

 Mac: http://download.qt.io/snapshots/qt/5.5/5.5.1/142/
>>>
>>>Source is missing. Can't test.
>>>
 We are targeting to release Qt 5.5.1 as soon as possible, most probably
 during next week. These packages are almost final ones, only two changes
 are still coming in (https://codereview.qt-project.org/#/c/126113/ &
 https://codereview.qt-project.org/#/c/126204/)
>>>
>>>Those two changes do not affect the binaries. One is a changelog and the 
>>>other
>>>affects only ICC on Windows. Neither change should affect our regular 
>>>testing.
>>>
 so please test these
 packages carefully and inform me immediately if you find something which
 should block the release. And remember, we aren't updating the packages
 because of any nice-to-have issue anymore...
>>>
>>>--
>>>Thiago Macieira - thiago.macieira (AT) intel.com
>>>  Software Architect - Intel Open Source Technology Center
>>>
>>>___
>>>Development mailing list
>>>Development@qt-project.org
>>>http://lists.qt-project.org/mailman/listinfo/development
> ___
> Development mailing list
> Development@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Qt 5.5.1 'rc' available

[Heikkinen Jani]

Src packages now in http://download.qt.io/snapshots/qt/5.5/5.5.1/latest_src/ 

Br,
Jani

>>-Original Message-
>>From: development-bounces+jani.heikkinen=theqtcompany.com@qt-
>>project.org [mailto:development-
>>bounces+jani.heikkinen=theqtcompany@qt-project.org] On Behalf Of
>>Thiago Macieira
>>Sent: 23. syyskuuta 2015 22:50
>>To: development@qt-project.org
>>Subject: Re: [Development] Qt 5.5.1 'rc' available
>>
>>On Wednesday 23 September 2015 08:37:54 Heikkinen Jani wrote:
>>> Hi all,
>>>
>>>
>>> We have finally new Qt 5.5.1 snapshot
>>> available
>>>
>>>
>>> Windows: http://download.qt.io/snapshots/qt/5.5/5.5.1/153/
>>>
>>> Linux: http://download.qt.io/snapshots/qt/5.5/5.5.1/190/
>>>
>>> Mac: http://download.qt.io/snapshots/qt/5.5/5.5.1/142/
>>
>>Source is missing. Can't test.
>>
>>> We are targeting to release Qt 5.5.1 as soon as possible, most probably
>>> during next week. These packages are almost final ones, only two changes
>>> are still coming in (https://codereview.qt-project.org/#/c/126113/ &
>>> https://codereview.qt-project.org/#/c/126204/)
>>
>>Those two changes do not affect the binaries. One is a changelog and the other
>>affects only ICC on Windows. Neither change should affect our regular testing.
>>
>>> so please test these
>>> packages carefully and inform me immediately if you find something which
>>> should block the release. And remember, we aren't updating the packages
>>> because of any nice-to-have issue anymore...
>>
>>--
>>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] 5.5.1 ChangeLog contains important information, please make sure it's in the announcement

[Tomasz Siekierda]

On 23 September 2015 at 21:47, Thiago Macieira
 wrote:
> On Wednesday 23 September 2015 08:42:55 Tomasz Siekierda wrote:
>> * Fixed a minor source-incompatibility between Qt 5.4 and 5.5.0
>> involving sets of functions overloaded on QTime and some integer or
>> QDate and some integer."
>>
>> Sorry, what? This could use some rephrasing
>
> Lack of parentheses in the language...
>
> sets of functions overloaded on (QTime and some integer) or
> (QDate and some integer)
>
> commit eda79a467ee7e45f3de63973b633e2a790b613eb
> Author: Marc Mutz 
> Date:   Thu Jun 25 22:34:58 2015 +0200
>
> QDate/QTime: fix SiC introduced by adding new non-explicit ctors
>
> The new constructors were added in c94d41d9 to help
> constexpr'ify QDate and QTime. Even though private,
> they participate in overload resolution and break
> function pairs overloaded on QDate and int or
> QTime and int.
>
> Mark them explicit.
>
> [ChangeLog][QtCore][QDate/QTime] Fixed a minor source-incompatibility
> between Qt 5.4 and 5.5.0 involving sets of functions overloaded on
> QTime and some integer or QDate and some integer.
>
> Change-Id: I65a09aaca2b083cda90255c24cc72ef51119d3b1
> Reviewed-by: Olivier Goffart (Woboq GmbH) 
>
> diff --git a/src/corelib/tools/qdatetime.h b/src/corelib/tools/qdatetime.h
> index 78ec2b1..6651efd 100644
> --- a/src/corelib/tools/qdatetime.h
> +++ b/src/corelib/tools/qdatetime.h
> @@ -59,7 +59,7 @@ public:
>  StandaloneFormat
>  };
>  private:
> -Q_DECL_CONSTEXPR QDate(qint64 julianDay) : jd(julianDay) {}
> +explicit Q_DECL_CONSTEXPR QDate(qint64 julianDay) : jd(julianDay) {}
>  public:
>  Q_DECL_CONSTEXPR QDate() : jd(nullJd()) {}
>  QDate(int y, int m, int d);
> @@ -138,7 +138,7 @@ Q_DECLARE_TYPEINFO(QDate, Q_MOVABLE_TYPE);
>
>  class Q_CORE_EXPORT QTime
>  {
> -Q_DECL_CONSTEXPR QTime(int ms) : mds(ms)
> +explicit Q_DECL_CONSTEXPR QTime(int ms) : mds(ms)
>  #if defined(Q_OS_WINCE)
>  , startTick(NullTime)
>  #endif

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

Re: [Development] QTBUG-46552 : QUdpsocket bug always present on 5.5.1 RC on Mac

[m...@rpzdesign.com]

Can you provide a sample project to reproduce this?



On 9/24/2015 5:37 PM, qt next wrote:
> Hi,
>
> I have tryed the RC1 for the 5.5.1 and it seems that I can always
> reproduce the bug 46552, at least on mac platform.
>
>
>
>
> ___
> Development mailing list
> Development@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development
>

-- 
No spell checkers were harmed during the creation of this message.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] QML import versions

[Alan Alpert]

On Thu, Sep 24, 2015 at 9:04 AM, Attila Csipa  wrote:
> On 9/21/2015 10:51 PM, Alan Alpert wrote:
>>
>> I found part of the previous discussion, see my essay from 2012 which
>> explains the versioning system:http://alan.imagin-itis.net/?p=322
>
>
> Not a new discussion, indeed :)
>>
>> Now in the next minor version of Qt, say we add a QQmlFlange class to
>> QtQml. A application built against the current version of Qt, but
>> linking to system libraries, will continue to work fine. The name
>> resolution happened at the linker stage and so a new symbol in the
>> shared library doesn't affect the behavior of the compiled binary.
>> "flange" will still be an instance of the local QQmlFlange and you
>> won't hit the name conflict until you try to compile against the new
>> Qt version.
>>
>> Contrast to the example I gave Robin, where the QML name resolution
>> happens at runtime, and you can see why #include is so much
>> safer than import QtQml.
>
>
> This is a red herring - given MOC and QObject properties, there is no
> guarantee (other a statistical "we add less properites to C++ classes than
> to QML, so there is less change of namespace overlap"). At best, this would
> indicate differences of defaults, but not versioning enforcement.
>
> Here's an example:
>
> QScreen* scr = qApp->screens().at(0);
>
> qDebug() << scr->property("devicePixelRatio");
> qDebug() << scr->setProperty("devicePixelRatio", 100);
> qDebug() << scr->property("devicePixelRatio");
>
> On Qt5.3, this gives
>
> //QVariant(Invalid)
> //false
> //QVariant(int, 100)
>
> On Qt5.5, this gives
>
> //QVariant(double, 1)
> //false
> //QVariant(double, 1)
>
> It's clear that there will be no compile time difference, but given the
> different *runtime* outcomes, the app behavior can be altered completely
> transparently to the developer. That's why it feels that the QML versioning
> *enforcement* is pretty arbitrary, as both C++ and QML can be written in
> both static and dynamic manners. Even if we say that "well Qt on the C++
> side doesn't use properties that often", it doesn't take into account 3rd
> party code, or how much it (doesn't) rely on either QML or C++ properties in
> it's own classes.

The point of versioning isn't to prevent different runtime outcomes,
that's not possible as you have showed. But there's an implicit
compile step when you run a QML file at program startup, and the
versioning system prevents that from failing.

Getting different values is a problem, yes. But those lines still ran,
and you could theoretically use runtime error handling code. If there
suddenly appears a type conflict in a QML file, the compilation stage
*fails* and the QML code never reaches its own "runtime" to experience
the different outcomes (we are in the runtime of the C++ application,
but bailed on compilation of the QML files).

If QML was untyped you could probably let it slide, as different
values at runtime is a much harder problem to solve. But when you can
change the type of a variable in a binding and then the file will
simply fail to compile, that's guaranteed application breaking.

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